Bridging GIS: Developing system independent applications

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.

Third party relationships
The open concept must be considered from the first phase of the project cycle. How will this openness be achived? Do current developers know the accepted standards or is additional training required? Perhaps, most important, what tools and third-party resources will be used to complete the task?

Developer knowledge is becoming increasing more and more diverse. Once upon a time, the better a person knew syntax, the better a developer that person was. Where a developer once focused most of his/her time learning the syntax of a language and understanding the data model, the developer of today must know much more than these. Language protocols, APIs, network basics, system security and system architecture are just some of the things today's developer must understand and apply. Because finding this complete skillset in any one individual is unlikely, corporations and individuals have developed formal and informal partnerships. It is only through these "virtual teams" that success can be achieved in creating open applications.

By utilizing third party resources, the developer can concentrate on core and custom functionality, while still achieving openness. For example, rather than developing code specifically to read an Oracle database, it can be developed to be SQL compliant and use ODBC drivers. The developer concentrates on writing standard SQL statements and does not worry about whether the user's database will be Oracle, SQL Server, Sybase or anything else. As a fhrther step to openness the developer can allow for customization by performing queries that are stored in the database, not in the code. This allows the user to change the query without need of code changes and recompiles.

Another example of working in a virtual team is by use of development tools that conform to open standards. Take, for example, a developer who would like to give the user the ability to view and manipulate engineering drawings. It would take far too much time to develop interface and translation routines for each engineering or graphics package on the market today. Instead the developer will rely on a company that specializes in engineering and image processing to provide him/her with a tool to use. This tool maybe a dynamic link library (DLL), an Active-X control, binary library, etc. In either case it will provide the developer with a single standard interface to access any of the recognized formats.

In his/her code, the developer does not have to worry about how to translate the individual image or engineering formats. All s/he has to know is how to communicate with the third party tool.

To the developer it is completly unknown as to what type of object the user may have. It is also completely unknown how to read and translate that type of object. What the developer needs to know is how to speak with the tool; how to have the image utilize a standard metadata format that describes itself, how to ask it to read or load the image and how to have the changed image saved. In each of these cases, the developer does not need to know or care how each happens. All s/he cares about is how to make the requests.

Information sharing throughout the virtual team is essential to success. This means the developer, too, must expect to share her/his time and knowledge if sdhe expects to receive information and cooperation in return. Or as Zig Ziglar, a well-known motivational speaker says, "You can have anything in life you want, if you just help enough other people get what they want."

Open ended thinking
One could dare say that yesterday's best developer, in terms of syntax and data model understanding, would be a failure in today's world without adequately understanding partnerships and virtual teams. Conversely, the foremost partnerships and information sharing in the world will not guarantee the best, or even good, developer. In addition to partnerships and information, good development practices and standards are imperative to producing open, independent applications.

Several good development practices include logically handling diverse functionality of operating systems, coherent layering and use of building blocks, dynamically loading data, intelligent use of metadata for database tables and fields, and custom creation of objects for cross-functional applications.

Handling Diverse Functionality of Operating Svstems
When developing application code the developer must understand the strengths and weaknesses of different operating systems. S/He must realize that seemingly simple things like directory and file names can become difficult when developing code that is to be used across operating system platforms. The way in which the file system is handled in NT, Unix and VMS is not necessarily the same. Unix, for example, uses the forward slash ("/") character to reference the system root directory; VMS has no universal root (the top directory for any device is denotted as "000000" as in "gis: [000000];"2 NT uses the backward slash ('l") with a drive designation as in "C:\V'.

Developers will typically handle situations that arise in which code must differ because of operating system differences with "if' logic. For example: strOS = system.os_name
if strOS = "window" then
... do this
elseif strOS = "vms" then
... do this
elseif strOS = "solaris"
.... do this
else
... do this
endif Other methods that are also available for handling differences between systems include directives and environment variables. Directives are used to direct the compiler or system to take certain actions based on other information. One such situation may be in which multiple dynamic link libraries (DLLs) are used to read information. Only one DLL is used by the application at any given time and each reads information from a separate distinct source, perhaps each supporting their own proprietary format. Information can be gathered during application initialization to determine which formats are being used, then directives can be given as to which .DLL to use. Environment variables are good for gathering limited information without utilizing configuration files, which requires disk 1/0.

Using Building Blocks
Using multiple DLLs through use of directives is a good example of application building blocks. Each DLL contains a complete set of functionality that is needed by the overall application. The concept is that the application is broken down into smaller blocks of functionality that can provide a standard interface to the main application, while communicating in a custom or specific way to other sources. This figure to the right gives an overview of how the application developer would, in the common interface, make a standard request, such as a SQL call. Each object in this middle layer is responsible for interpreting this request, passing it to the database and returning the information to the common interface.

This second figure offers a similar diagram for the discussion and pseudocode given in the preceding section titled, "Third Party Relationships". In this discussion, the developer gives the end user the ability to view and manipulate various types of images and drawings. In the common user interface block the developer makes fi.mction calls similar to szFilename = Img.LoadFile(type), which are sent to the lower .DLL. In this example, the .DLL will, in turn, access one of its own DLLs to open, read and translate the drawing. For the developer, it doesn't matter how the middle blocks communicate or translate the files only that 1) they do, 2) they return the required information to the common user interface and 3) there is a published standard for how the image.dll communicates with the common user interface.

A common example of this approach is through use of Active-X controls in Visual Basic (VB). The VB developer uses a third party control, which is usually a DLL or OCX file, in her/his application. This developer then accesses this DLL or OCX through methods made public by its programmer. What actually occurs inside the DLL or OCX need not be the concern of the developer, so long as it yields correct data.

Loading Data Dynamicallv
Another good practice for developing open applications is loading data that is available at the time the user is running the program. This practice must go much further than the conventional reading of values from a database and loading them on the fly, though that should remain part of it. It should be taken to mean loading anything and everything possible on the fly. The more information loaded at run-time from external sources the more open and customizable the application will be.

Current GIS systems offer endless possibilities for dynamically loading data. For example, rather than implementing standard queries in the code or relying on the user to select multiple records, why not populate a combo box, list box or similar widget with a list of stored queries as read from the external database. Let the user select the query of choice and then request the matching records from the database for display. This way the user will not have to select records one by one and if a different set of records is needed in the future, the user can simply add a new stored query to the database; no code need change.

Or how about making a determination at runtime whether to create and load a toolbar/statusbar interface for NT or a menu buttons and labels for Unix. This way the application will have the same look and feel with which the user is comfortable.

Or consider a user that wants to know about information contained inside an area. Think about the possibilities: the developer could dynamically populate a list with all the objects that are types of areas, then based on that selection populate another list with all the objects of that type, from which the user would choose; s/he could allow the user to draw a box or area on a map and use that as the area for collecting the information; or the user could be allowed to simply choose an area object on the map by clicking it with the mouse. In all cases, the developer has no idea what types of areas may exist in the user's environment, but her/his application will work for any of them.

Using Metadata Intelligently
Metadata is information that describes data. It is another mechanism a developer can use to make sure the application is open. When working with the initial assumption that the developer can know nothing about the end user's environment, it becomes clear how metadata can be used. The developer will not know in advance what tables or objects the user may have. However, in GIS s/he can know that the user will be working with objects that are some types or points, lines or polygons. S/He can know that these points, lines and polygons will have some type of interaction with one another. And s/he can know that all this information will be available to her/him through metadata.

Examples of metadata include being able to retrieve a list of tables available in the system; being able to ask the table for each of its fields (without knowing their names); and having the ability to determine if the field is mandatory or not and if it expects to hold numerics, alpha or dates. Use of metadata is crucial to developing independent applications because it allows the application developer to know and comply with metadata standards without needing to know in advance how the user's data model will look. It will also open the application to work unchanged across multiple user environments.

Creating Custom Objects
Sometimes, even the best developers, using the right tools, with the help of a virtual team, will find it necessary to create custom pieces of code. In fact, that is the sole reason why some of the best developers and some very successful companies are in business: to create these "building blocks" to fill in the gaps.

Part of a good development practice is knowing when to create new blocks for custom functionality, when to work with the virtual team to have new functionality added to existing blocks and when to make sacrifices in what the application will offer.

Consider developing an application for which a map is desired. Several companies offer Active- X controls that allow you to read their respective data formats. But if the intent is to develop an open application, meaning there is no way to know for sure what geographic format the user will be using, using any one company's control will not work. What is needed is that middle block that offers a standard interface to the developer no matter what GIS is used on the back-end. A block that understands how to take each program call from the developer and translate it into a command to send to whatever GIS system the user has, and then return the information to the application so it may be displayed to the user.

Since this block doesn't already exist, the developer will have to decide to 1) create it her/himself, 2) work with another virtual team member to have it created or 3) use an existing control from one of the GIS vendors, thereby locking her/himself into one system.

Assuming option three is not acceptable, steps must be taken to ensure the application is independent and open. Though methods for doing this will vary, the following is provided as a simple overview for how this may be achieved.

The developer will determine the methods or fictions that will be supported and develop a standard for handling them; Pan(x,y), Zoom_In(degree), Zoom_Out(degree), GoTo(area), Refresho, etc.
DLLs or binary libraries will be developed specific for each GIS that support the standard interface and translate the method call to that specific GIS.
An Active-X control is created for the developer that allows her/him to create a map object in the application. This map object will have a property (attribute, member, slot, etc.) that can be configured at runtime based on the user's GIS. It, too, will support the published interface.
During run-time the application developer's code will determine what GIS is in use, either through an environment variable, by reading a configuration file, by querying the user, etc. Then, based on that information, load the appropriate DLL or binary file.
As the user continues to use the application, the developer's code will be making standard method calls such as Pan, Zoom_In, etc. to one of the DLLs. But the developer will not know which one. Since each of the DLLs supporting a specific GIS understand the same standard interface, it doesn't matter to the developer what GIS the user has.

During application start up and initialization pseudocode for the developer may look as follows: GISsys = get environment variable (GISsystem)
if GISsys = "smallworld" then
declare pan function in sw.dll
declare zoom_in function in sw.dll
declare zoom_out function in sw.dll
...
elseif GISsys = "esri" then
declare pan fimction in esri.dll
declare zoom_in function in esri.dll
declare zoom_out function in esri.dll
...
elseif GISsys = "integraph"
declare pan function in intgr.dll
declare zoom_in fimction in intgr.dll
declare zoom_out function in intgr.dll
...
else
return an error
endif Again, since all DLLs support the same interface standard, once the appropriate .DLL is loaded, the developer will simply make the standard calls: pan, zoom_in, zoom_out, etc. Map.pan(x,y) for example, will work for all the .DLLs.

Room for customization
No matter how independent, how open, how flexible the application, there will almost always be that user who needs to have it customized. A good development practice is to include has much information as possible in externally configurable sources.

Environment variables have already been discussed, but are worth repeating. For simple to configure information such as language used, file location, etc, these are reliable and easy to use. Use of configuration files are also recommended. As Windows allows a user to customize their desktop, configuration files allow the developer to custom tailor an application to the user. It is a good practice to allow the configuration file to be read from within the application, as well as having a separate customization module.

Where appropriate the developer can also allow the user to customize the interface by choosing the language to use, standards to follow, fonts to display, etc. In each of the cases, it will be up to the developer to ensure the appropriate nationalization files, interfaces and fonts are available.

Conclusion
As the GIS vendors continue to expand and open their architectures, the roadblocks to developing system independent applications are removed. It becomes the task and responsibility of the system developers to understand how to apply the numerous technologies, tools and methods that are available to achieve this goal. Sharing of information through virtual teams and adhering to standards of industry organizations will be the first steps toward the goal. Thinking openly and beginning with the assumption that one can know nothing about the end user environment will be key traits in ensuring each application is open and independent of any specific operating or geographic system.

References

Zig Ziglar, 1998: See You at the Top.
Smallworld June 1994: GIS 2 Magik, Advanced Topics, pg. 42-44.