Bridging GIS: Developing system independent applications
Rodney J. Fazenbaker
Marshall Consulting, Inc
1910 South Boulevard, Suite 200
Charlotte, NC 28203
Introduction
Perhaps the best place to start looking for input concerning open applications is from the
viewpoint of the application or system developer. This is the person who must identify how the
application will work (internally), what methodologies will be used and how to develop it to
meet the criteria of system independence and openness.
To properly develop this type of application the developer must first identify the main objectives
of the application and then ask, "Assuming I know nothing about the end user's environment,
how can I make this application work?"
In the past, a developer would ask questions like, "What database are you using or planning to
use with this application";" What operating system platform do you run: DOS, Unix or
Windows";" What printers do you support"; or "In what format are your graphics?' This would
help them decide what technologies to use and how to write the code.
In today's environment of system independence and openness, the developer will begin
developing with the assumption that s/he can't know the answer to any of these questions in
advance. Perhaps the final application will be reading data from an Oracle database, perhaps
Ingres, perhaps SQL Server. Maybe the spatial data will come from shape files, maybe from
Smallworld datastores, maybe from ARCINFO coverages. Possibly the end user's company uses
Unix, maybe NT, possibly some of both. The developer just doesn't know and, therefore, must
find a way of developing the application such that it will work in any given scenerio.
Prerequisites
The impossibility of developing an application that will work in any environment, at any time,
with any data, will quickly become evident. The developer, therefore, may be tempted to take
shortcuts or sell-out to one technology over the other. Remember, for each shortcut there is the
potential penality of a missed sale or a lost client. If the application can grow and change as the
customer grows and changes, the customer is likely to keep using it. But if the application
requires rework when the customer grows or changes, the customer may view that situation as an
opportunity to reevaluate use of the application and current processes, which may ultimately lead
to them using another product.
There is an answer to this impossibility: Industry Standards. Rather than trying to make the
decisions on what platforms, databases or products to support, the developer can rely on
organizations for setting standards which industry leaders agree to follow. This, then, will allow
the developer to change from the assumption of knowing nothing about the end users'
environment, to knowing the end users will be using components that comply with industry
standards: SQL compliant databases, OGIS compliant GIS products, data structures with
available meta-data, etc.
Armed with the knowledge that s/he is complying with industry standards organizations, the
developer can require certain prerequisites of the end user and their systems, without violating
basic principals of system independence and openness. This will allow the programmer to
tighten the scope of her/his development and skills.
