An intuitive interface for GIS application development

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