An intuitive interface for GIS application development

An intuitive interface for GIS application development

Dave Matson
GIS Coordinator
City of Palo Alto, P.O. BOX 10250
Palo Alto, CA, 94303, USA
dave_matson@city.palo-alto.ca.us

Chip Eitzel
Partner, Geodesy
8 California St, Suite 400
San Francisco, CA, 94111
geodesy @earth link.net

Overview
Palo Alto, home of Stanford University and numerous spin-off research companies, is located at the “head” of California’s Silicon Valley. The city’s upper-income, highly educated citizens demand responsive city services. Fortunately, the city’s early decision to own its utilities has provided an income stream to meet the demands of its citizens.

Nearly $25 million is budgeted annually for utility infrastructure replacement including lining sewer pipes, replacing water lines, undergrounding overhead electric lines, installing fiber optic cables, improving natural gas lines, and extending the storm drainage system. On top of this, city leaders have seen the wisdom to taking a true ll~ecycle approach to maintaining other infrastructure assets such as streets, public buildings, public safety facilities and parks. This means a high priority (and additional budget dollars) will be allocated to the infrastructure - making GIS’s function as a tool for infrastructure management all the more attractive. Palo Alto has created a high-accuracy map base to manage its utilities and to maintain its streets and storm drains. The geographic information system (GIS) data base has been constructed from many sources to serve a growing and diverse set of user applications Ten years ago the foundation for this project was formed through needs assessments, feasibility studies, acquisition of initial hardware (Digital Equipment VAX workstations) and software (Graphic Design Systems GIS software and Oracle RDBMS). Following a prototype mapping project, detailed specifications for citywide mapping were developed together with an extensive data model. The city was then well prepared to embark on a contract to map its entire 25 square miles and all its myriad features.

Two years ago the city was at a crossroads, facing decisions that would have far reaching implications for acceptance and utilization of this high profile system. To maximize the utilization of the very large investment in GIS the application environment needed to present the users with an intuitive interface. What environment should be chosen so that users would be comfortable and yet was powerful enough for managing the sometimes complex elements of the infrastructure? The answer was not at all obvious and required considerable analysis and debate. This paper documents the decision criteria and key issues leading to the application development approach.

Application development issues
Three approaches were considered for application development given that the city’s spatial data was stored in CDS and the attribute data in an RDBMS. The first approach would use the proprietary GDS development language GEL (Graphic Extension Language). GEL is a Motif based GUI development environment which runs from within GDS on VMS based workstations.

36.The second approach would be to develop client/server software which would enable GDS to serve spatial data to PC based clients. This would require the creation of server software to control GDS and PC client software to provide a programmatic interface for common PC development environments like Visual Basic, Delphi, Power Builder and C++.

The third approach considered was to export the data and use existing desktop software such as Arc View or MapInfo as an end-user tool. This approach was ruled out early as the desktop software would not meet the City’s specific needs without additional custom application work and there was no framework for the management of replicated data.

We asked the following questions to surface issues and compare the two remaining approaches:

Graphic manipzdation: how easily does the development tool programmatically manipulate spatial data?
Deve/oper resource pool: how plentiful are developers with skills in the use of the development tool?
Language robustness: how easy is the development environment to use? How complete is its functionality? How well documented?
Development cost: how quickly can results be produced using the development environment? What is the cost of the development software and requisite hardware?
Integration with tabular data stores: how easy is it to access data stored in workstation and PC based tabular databases such as Oracle and Microsoft Access?
Development risk: what are the chances of a complete or partial application failure? A complete failure is the inability to deploy applications. A partial failure is to not meet all the end-users’ critical requirements.
User learning curve: how easily can GIS users learn and use the finished application? For purposes of this analysis, users were divided into two categories: production users and casual users. Production users generally have substantial skill working directly with the RDBMS and/or the spatial database. The city has about 12 production users. Casual users generally have basic computer skills with PC-based word processors and spreadsheets. Casual users typically have no GIS experience. The city has about 600 potential casual users.
Integration with desktop applications: how well do the GIS applications cooperate with Windows PC applications (such as Word Perfect, Lotus, Word, Excel and PowerPoint) are widely used by City staff? For example, how difficult is it to copy a map into a report?
Third party add-ens: what is the suitability and quantity of third party software in the form of components and complete applications? Components such as business charts and graphs may be used within the development environment. The utility of complete applications such as permit tracking may be enhanced through cooperation with the GIS.
Code re-use: how easy is it to organize application source code to facilitate re-use, particularly between developers?
Code portability: how portable is the application code between different RDBMS and spatial databases? The issue of cross-platform hardware portability such as moving code from PCs to Macintoshes was not considered
Suitabiii~for hardware platjorms: how suitable are the applications for VMS workstations and PCs with the MS Windows interface? Does the platform support the applications natively or is middleware required?
Database vendor culture: what is the degree to which the development environment permeates the database software vendor’s culture? The vendor &tablishes the vocabula~ with which users communicate with the vendor and each other. Being the only C++ shop in the vendor’s user community limits the opportunities for sharing.

Figure 1 shows a comparison between the two approaches. The criterion was rated as low, medium or high where low does not meet the city’s needs, medium is acceptable but not attractive, and high is a desirable condition.

Figure 1 Development method comparison

Issue	GIS Proprietary Language	PC Development Environment
Graphic manipulation	High - this is the primary purpose of the language	Medium - most functions are available. some must be custom built
Developer resource pool	Very low -200 world wide	Very high - millions world wide
Language robustness	High for graphics, low elsewhere (e.g. RDBMS)	medium for graphics. high elsewhere
Development cost	Low - slow language to learn and use; workstation based	High - fast language to learn and use; PC based
Integration with tabular data stores	Medium for workstation based data, very low for PC based data	High for both workstation and PC based data
Development risk	Low initially, high over time due to limited portability	High initially due to technical hurdles, low over time due to ease of portability ,
Production user learning	Low– familiar environment	Low - familiar environment
Casual user learning	Medium – unfamiliar environment	Low - familiar environment
Integration w/desktop apps	Very low	High
Third party add-ons. applets	Very low	High - a plethora of development goodies
Code re-use	Low- few code management tools and standards	High - module. components. OLE, many code management tools and standards
Code portability	Very low – complete re-write	Medium. only graphic portions (I0% to 25% typ.) of the apps need be replaced
Workstation platform	High	Low - requires middleware
PC platform	Medium – requires an X-Window server	High

Application development approach
For the application whose primary focus is the maintenance of spatial data, GEL was chosen. This application, named Feature Editor (FE), is used by the production staff and is highly graphic in nature. As the city evolves away from GDS, this application will need to be completely replaced. If there are no applicable data maintenance applications available for the replacement system, then FE will be re-developed.

Most other applications are either focused on data dissemination or specialized data maintenance coupled with light analysis. For example, an application to manage the storm water collection system must maintain data for infrastructure components (e.g. manholes, pipes, .), maintenance records, and citizen complaints. For these applications. the client/server approach was chosen. The development environment selected was Microsoft’s Visual Basic because of its maturity, ubiquity, and compatibility with the city’s Windows 3. I and NT PC clients.

Development path for client/server
The first development activity in implementing this approach was to create the client/server software. The server software, hosted on the VMS Alpha platform, had to recognize a request for a connection to the GIS software and then manage the connection once established. The client software needed to provide a programmatic interface on the PC for common development languages. This client/server step contained the majority of the development risk.

The TCP/IP protocol was chosen as the communication transport. This provided for operation over the City’s existing network and left the door open for Internet extensions.

Figure 2 The Customer Service application

The next step was to develop a simple application to provide rudimentary spatial data viewing capabilities. This application, dubbed “Customer Service”, was intended for use by city staff in support of the public at the Utilities, Planning and Public Works department’s front counters. Tools to define the contents of the map window, to pan and zoom around the map window, and to zoom to a parcel by address or APN were built for this application..Figure 2 The Customer Service application Once the Customer Service application was thoroughly tested and put into use, the code for the tools such as pan and zoom was centralized and made generic. This set of generic functions and tools will be used in most of the subsequent applications. The graphic manipulation functions, which were specific to GDS, were consolidated and named in a way that would make them easy to remove or replace at a later date.

As each new application was developed, the central tool set was expanded. Capabilities, such as panning and zooming the map window using a key map, and tools, such as measure and query, were added to the central library after being developed for a specific application. The library was designed in a way that permitted easy inclusion of these new tools into existing applications.

The final step in the evolution of the client software was to turn some of the most commonly used tools into components. A component is a self-contained application building block that may be added to a VB application through the development environment’s interface. Components often take the form of controls such as a list box or the open file dialog form. Priority for component creation was given to functionality that will be useful beyond the remaining life of GDS.

Successful results

Common Development Tool The selection of a development tool that is as widely used as Visual Basic has proven invaluable. The most significant benefits have been derived through three venues: ( 1) the availability of third party software components and applications, (2) the wealth of reference materials which focus on VB, and (3) the fluidity with which the development environment eases coding tasks.

The availability of third party components such as data base grid and image controls has supported the addition of significant capabilities to our applications for very little cost. A GEL based database grid interface would cost about $15,000 to develop. In contrast, any one of the half a dozen VB grid controls currently on the market cost around $200. The real kicker is that the VB grid controls are much more capable than the custom built GEL grid. Reference materials in the form of trade journals, books and Web-sites provide a wealth of tips, techniques and sample code which rapidly extend a VB programmer’s capabilities. The books and journals are often available in digital form, providing for easy topical searches and cross-references.

The ease-of-use of the development environment expedites program coding significantly. Subtleties, such as jumping to a called procedure with a single mouse click, provide for easy navigation through the source code. Simple capabilities such as cut and paste compatibility with programs that support word processing and Help authoring are not just a boon to productivity; they increase overall application quality.

Component-Based Development
The use of third party and custom-built components such as data base grids, report writers, and the key map control have both shortened the development cycle and provided for more robust capabilities than the city could have developed with its limited resources. The programmatic interface for components is something that most PC platform developers understand. This enables developers who are not familiar with GIS concepts to contribute to the application development effort. The stormwater management application shown in figure 3 includes several components – both custom and commercial.

Figure 3 Flo – a storm water management application

Link to Centralized Data and Meta-Data
All of the city’s map graphics are stored and maintained centrally on the VMS Alpha system. Tabular data is located in an Oracle RDBMS and in shared Microsoft Access database files. Mets-data, such as descriptions, 40.storage locations, and allowed attributes for feature classes (such as manholes or main pipes), are maintained in an RDBMS-based data dictionary. By de-coupling the applications from the data using these centralized data stores and meta-data, the porting liability for the applications is lowered.

Iterative Development Style
A formal software development methodology is broken down into many steps, each building on the previous step’s product. Each step is well documented, reviewed, and discussed. Subsequent steps are typically not started until there is substantial agreement from the reviewers. The process is very thorough, very defensible, very well documented, very ISO 9000, but also very time consuming and very expensive.

The approach taken for most of the city’s GIS applications was to define the requirements (just as the formal methodology does) and then move immediately into prototyping. Prototypical forms were constructed and then reviewed by the end-users. The portions of the application, such as the map window, which are based on the central library, were operational as soon as they were added to the prototype. This provides the end-users with a partially functional prototype that greatly enhances their comprehension of what the application will do and how they will interact with it.

The iterative development style has been successful partially because the feature-centric data model is well defined, so extensions to it do not involve significant database extensions or redesigns. Another significant factor in the iterative success is that the applications are not large. Initial development time ranges between 40 and 200 hours with subsequent iterations ranging from 2 to 80 hours each. End-users get a crack at the application between iterations, so infelicities are surfaced quickly and priorities for enhancement are easily set.

Minimal Vendor Specific Development
A significant reason for going the client/server route for applications was the expectation that GDS’S proprietary development language, GEL, would be replaced by a next generation product, and further that the core GDS software itself would be substantially rewritten in the near future. To lower the porting liability for the city’s applications, reliance on GDS functions was minimized. For example, instead of using the GIS’S internal SQL capabilities, connections from the applications to the RDBMSS were made and managed directly using technologies such as ODBC (Open Database Connectivity - Microsotl’s strategic database interface). Mandatory GDS functions were grouped together and a naming convention was employed which simplified the location and replacement of the GDS-specific functions.

For example, in the Pavement Management application, 90% of the development time was spent on the management of segment attribute data, maintenance records, condition rating analysis, and priority assignments. All the database and some spatial analysis functions were developed without using GDS functionality. The small amount of new code required for GIS interaction was isolated from the bulk of the application code so only 10°/0of the application code need be reviewed and replaced when the application is ported to a new platform.

The same philosophy has been applied to the RDBMS portion of the applications. ANSI SQL is used as much as possible. Product specific stored procedures are avoided.

Issues and answers

Central Management of Applications One issue that became apparent early in the project has to do with the nature of client/server systems such as has been created by the city. That issue was how to maintain consistent configurations on the multiple clients using the GIS applications. As discussed previously, the city’s style of implementation involved frequent, sometimes weekly, modifications to some of the application software components that affected some or all of the applications. Ideally, any modifications to applications with multiple users should be duplicated on all users’ computers as close to the same time as possible. Unfortunately, the resources to assure such consistent updating were not always available, leading to situations where somewhat different configurations and versions of the applications were present throughout the organization.

There areseveral approaches that canaddress this problem. Themost straightforward, though least flexible, is to simply limit the frequency of updates to the applications. Planning for a quarterly or semi-annual cycle of updates allows for a rigorous methodology in which consistency between versions and configurations are assured. A better approach may be achieved through the use of clients that are as “thin” as possible so that upgrades can be distributed from the server level. The use of a three-tier client/server environment with departmental servers for specific applications is another approach to reconciling this problem. Palo Alto favors the “thin” application client approach to maintaining version consistency and will be developing tools and procedures to make frequent updates possible and easy to implement.

Server Upgrade Decision Delays Application Rollout
In late 1997. the DEC VAX 3300-3400 server tandem at the core of Palo Alto’s GIS was the same system purchased with the original system in 1989. Needless to say, the performance of this equipment was far from the level expected of contemporary information systems. There was no question that the servers needed to be upgraded, and the funds were available. The problem was to find the best system to serve our current needs and carry us into the uncertain future. While it was clear that the future with our current software, GDS, was finite (as detailed in the next section) it was also clear that we would continue to use GDS for at least another two years. This led to a basic requirement that the server run Open VMS, making the DEC AlphaServer the only real choice. The CADD workstations used by the city’s design technicians were also outdated even though they had been upgraded since the original purchase. The highest performance replacements for these were also Alpha-based. Thus an all Alpha processor based system was the apparent best choice.

However, it was also clear that our future GIS system would ~be VMS based but rather would very likely be built on the Windows NT platform. Not all vendors of GIS software have ported their products to Alpha-based hardware.

Their NT-based products will operate on the Alpha-based hardware although in many cases an Xwindows emulation environment is required which results in a nearly 50°/0reduction in processing performance. Consequently, the performance of the current system had to be weighed against the possible impacts on some undefined future system. Because this was a significant expenditure for the city, considerable debate occurred before a purchase decision was made. In the meantime, new users who were anxious to connect their PCs to the GIS via the city’s network were put on hold since they could not be supported with the old hardware. Ultimately, the decision was made to maximize the performance of the current software with the Alpha-based systems and leave the future compatibility issues to the future. Given the Iifecycle of workstations, a replacement in three years would not be inappropriate and the server can no doubt find numerous uses as a file or data server.

GIS Software Vendor Pulls Plug on GDS
In January, 1997, the parent company of Palo Alto’s CADD/GIS software announced its decision to curtail future investments in research and development and new products for its GDS affiliate. For current users of its software, the company stated it would fulfill the requirements of all current GDS contracts and continue to provide existing license holders with support, system maintenance, bug fixes and operating system and database upgrades for a minimum of three years.

Consequently, the city formulated a strategy to free itself of GDS dependence by the end of 1999, when software support could no longer be assured (see figure 4). The key element of this plan involved the translation of GIS spatial data from GDS’ proprietary file format to a spatially enabled relational database management system (RDBMS). The capability of RDBMSs to store such data types is a relatively new feature and lies at the heart of the Open GIS Consortium’s (OGC) initiative to allow applications from different vendors or developers to share a common geospatial database. Because such a data translation had never been done, the city entered into an agreement with Oracle Corp in December, 1997, to develop the tools and procedures necessary to enable Palo Alto to export its GDS-based GIS data into an Oracle database with the Spatial Data Option (SDO).

Figure 4 Platform migration plan

With this GDS to Oracle tool in place, the city plans to replicate its data on a regular basis to create a RDBMS that . . serves all Misapplications except fortheactual creation ofandediting ofgraph-ic features. GDSwill continue to be used for CADD and graphics-related tasks until such time as it becomes functionally obsolete or the lack of support makes the product unusable. At that point, the CADD/GIS software will be replaced with a product that is capable of directly reading and writing data stored in the RDBMS eliminating the need for the replication process.

Storage of the city’s GIS data in an OGC compliant format will allow the use ofa number of new GIS application software products. Products like Intergraph’s GeoMedia, Autodesk’s World, and Bentley’s Geographic’s have all been created to conform to OGC standards and leverage the user’s abilty to create and use applications based on data from numerous sources. Existing applications developed by Geodesy that link to GDS data will be modified to redirect their links from GDS to Oracle thus extending the value of the city’s investment.