Moving From the Desktop to the Web:

A Strategy for Application Development

 

Pierce County GIS for a few years now has used a desktop application called QuickView to support Planning and Land Services permit counter personnel. QuickView has been successful in allowing counter personnel to quickly look at pertinent information at or near a particular site (parcel). Other departments within the county have noticed the functionality of QuickView and its potential usefulness for their own departmental functions and have requested their own version of this application. Current plans are for QuickView to be used by four different departments, each with separate data needs, and for additional use by other cities within Pierce County. To make deployment of QuickView easier and less costly it was decided that a web version of QuickView would be developed. This paper will discuss the process of converting a desktop application to a web application and the how the application is designed to make it easier to customize for each unique department without having to rewrite the application each time.

 

The QuickView homepage

 

As a desktop application QuickView first proved its usefulness at the Planning and Land Services (PALS) permit counter. Counter personnel could retrieve needed permit information, i.e. city located in, school and fire districts, along with natural and environmental hazards areas on or near the site among others, in a much more timely manner than previously possible. QuickView as a desktop application was a PowerBuilder application, the Pierce County standard at the time for desktop development, with embedded MapObjects. The drawbacks to this desktop approach was the cost of the MapObjects licenses for each user, the difficulty to maintain updates and changes to the software – at times having to visit each user’s machine to implement changes, the need for a fast network connection due to the thick client nature of desktop applications, and the dependence on the user’s machine hardware specifications to run the application efficiently. As the demand for more installations of QuickView grew, within PALS and other Pierce County departments the need for different type of solution became apparent..

 

QuickView as a desktop application

It was at this point that an Intranet application seemed to be the most viable option for distributing the QuickView application throughout Pierce County. QuickView being a MapObjects application MOIMS was chosen as the Intranet Map Server. We were hoping for a quick and easy transition from the desktop to the web, but that was not the case. The web interface tools of MOIMS were limited at best, and a steep learning curve was encountered to move from a straight PowerBuilder graphical user interface to a mixture of HTML, Javascript, and ColdFusion. The web interface was to look and feel similar to the interface already in use on the desktop. The idea was to be able to switch to the new product without having to retrain any clients.

 

ColdFusion was used to gain database access from the web interface, leaving the PowerBuilder/MapObjects application to create and serve the maps through MOIMS. An ActiveX control was used to display the maps. The ActiveX control allowed for map interaction within the web browser, thus dynamic pan and zooms could be performed along with measurements of line length and area on the map. These functions had all been part of the original desktop interface and were needed to make a smooth transition from the desktop to the web. The ActiveX control proved to be a problem in itself as custom browser settings and specific dll’s had to be uniform across the client’s machines. This would mean once again having to visit client machines during the installation process, something we were hoping to avoid with a web based application. A solution was found by using a Novell product ZenWorks to push the proper dll’s out to the client machine and cause the custom browser parameters to be set from a remote site.

 

 

QuickView as a MOIMS web application

 

 

A second specification of the web version of QuickView involved ease of maintenance and quick implementation of similar applications used for other departments. As QuickView was developed for other departments the differences occurred in the data presented not in the interface itself. A database was designed then to maintain access to the data needed for each application. A query of this database could be used to load the data required for each department’s QuickView application. It would seem then that only one MOIMS application would need to be running while the data would change depending upon the user requesting the application. This did not work out in practice however as the MOIMS application was found to be somewhat unstable and once that service did go down it had to be manually restarted, requiring constant monitoring of the service. Therefore as each new application was added a new MOIMS service was created so that when if one application went down the others would remain running. Maintenance under this system was high, monitoring and keeping the five applications running, but it meant happier clients in the end.

 

A database of the QuickView data

 

Another problem with the MOIMS/PowerBuilder solution is the fact that PowerBuilder appeared to have a memory leak. The memory leak caused a need for the QuickView applications to be restarted at least every other day, as the size memory usage grows, the longer the application runs. This again increases maintenance for an already overworked support staff. Also only one programmer among the GIS staff had PowerBuilder experience, so there was no backup support for the application was minimal. As Pierce County GIS began to build some other applications with ArcIMS we could see usefulness of it as a replacement for MOIMS in QuickView.

 

ArcIMS, we could see, would solve some of the problems we were having with MOIMS, however we soon found other issues with using ArcIMS. ArcIMS’s underlying structure is much different than that of MOIMS; there is no need for another application to be running as the map server. We were hoping then we could eliminate the PowerBuilder application from QuickView. ArcIMS is its own map server, so there was no need for the PowerBuilder application to perform that service anymore. Since one ArcIMS application could call multiple map services, we could then create separate map services for each department’s needs and also do away with the data layer database we needed with MOIMS. ArcIMS also proved to be a much more stable product and could restart itself when it did go down, thus relieving our need to “baby sit” the multiple QuickView applications. Also many of the functions that were written as custom code in the MOIMS QuickView came as part of the “out of the box” functionality of ArcIMS, meaning we didn’t have to rewrite those parts i.e. the identify function, the zoom and pan functions and the measurement function. It also allowed us to access our data through SDE, which allowed for direct queries of the GIS layers themselves not requiring the use of ColdFusion and outside databases to perform the queries demanded of the GIS data.

 

QuickView using ArcIMS

 

ArcIMS was not without its own set of problems. We were hoping to use the Java interface with its direct map interaction, much as the ActiveX control allowed us to do in MOIMS. This proved to be even more difficult a task than the ActiveX control to allow for download to the client machine. Since the Java viewer required the download of the Java plugin and JRE, finding the correct version of these download was essential to successfully running the application. This was not always easy or in the case of some machines, Windows 2000 machines in particular, even possible. We eventually gave up entirely on using the Java viewer as the download problems overwhelmed us.

 

The HTML viewer in ArcIMS can do the dynamic pan and zoom functions required in QuickView and can even do some distance measuring, though the process is quite a bit slower than users are accustomed to. However the greatest drawback to ArcIMS is the lack of standard GIS tools. Even if one could efficiently define the coordinates of an irregularly shaped polygon there is no way to return the area of that polygon, nor could one find the distance to an object, nearest or otherwise. The only true spatial analysis tool available in Arc XML is the buffer function, but it would take many, many instructions to find a distance, rounded to the nearest foot, between two features. The solution we arrived at for this problem is one that Esri advertised at last year’s conference, i.e., using MOIMS to do those functions that ArcIMS cannot do1. In the older MOIMS application dbf tables were being generated with the detailed information for each site (parcel). These dbf tables were then stored on the server and reused if needed or new ones generated when requested. The detailed information included name of city, school district, fire district, zoning code, etc and also proximity information such as nearest road, wetland, sewer line, etc. and the distance to those features (see the examples above). The new QuickView using ArcIMS calls the MOIMS application, now a single stripped down instance of the old QuickView application, to generate the tables and then queries and displays those tables through ColdFusion.

 

Another obstacle encountered when using ArcIMS was in attempting to customize parts of a standard type application required wading through a maze of Javascript code. We found little or no documentation on how to best approach this task. Only hours of studying and hacking away at the code produced any usable results. It was found that attempting to delete any of the frames upon which ArcIMS is built can cause hours of extra coding. Finally we decided it was better to keep the frames and hide them then to delete them and track down all the associated code. Two helpful examples from last year’s conference proceedings of an advanced ArcIMS technical seminar provides the only clear documentation we could find on how to best navigate through the maze.

 

 

From Proceedings of 21st Annual Esri User Conference; Technical Papers;

Working With the HTML Viewer; Tim Bricker & Mark Ho

 

The resulting application is now a hybrid of ArcIMS and MOIMS. This solution gives us most of the end product we intended. However, since there is yet a PowerBuilder/MOIMS piece that maintenance still requires some “baby sitting” and we lost the ability to measure areas on the map. We are hoping later versions of ArcIMS will include more of these functions.

 

Successful application development requires that user specifications are clearly defined. Beyond those specifications are the capabilities of the software tools to be used, which in many cases limit the ways user specifications can be met. QuickView with its generic interface and data driven departmental usefulness provides a means of meeting most specifications with little or no changes to the user interface. However as we have seen moving from the tightly integrated software of the desktop to the less well structured software for the web requires making due with tools not yet as fully matured as their desktop counterparts.

 

 

References:

Proceedings of 21st Annual Esri User Conference; Technical Papers;

Using MapObjects and ArcView Effectively With ArcIMS ; Slide #35