Implementation of a Web Service-Based Municipal Gis

IMPLEMENTATION OF A

WEB MAPSERVICE-BASED

MUNICIPAL GIS WEB SITE

John Crews

The University of Texas at Dallas

GIS Master’s Project

August 1, 2006

ABSTRACT

Newly developed technologies have now made it possible to create web sites which combine custom GIS data with basemap data and GIS functionality from web map services. This project will attempt to determine if it is possible to create a GIS web site of the type typically created with proprietary software (such as a municipal GIS web site) and, if so, attempt to determine if it is more advantageous to create such a web site with web map services or proprietary software. Very little peer-reviewed literature is available on the subject of web map services due to their recent availability; however, literature on state-of-the-art web GIS and GIS web site evaluation is reviewed. The project was conducted by selecting an existing proprietary software-based GIS web site, creating a web map services-based web site similar to the original site, and comparing the implementation effort and performance of the two. The results of the comparison are reported and evaluated. Finally, conclusions are drawn as to which method is preferable.

INTRODUCTION

Google Maps, Yahoo! Maps and Microsoft’s Virtual Earthare considered second generation web map services. All areaccessed via an internet browserand feature very user-friendly interfaces and rapid display of both raster data and vector data. Because the application programming interface (API) has been released for each of these services, it is possible to create a custom web site incorporating geographic information and functionality from the service. This project will demonstrate a method of implementing and deploying an internet-based geographic information system that will add custom layer display and analysis capability to a web map service in a new web site. The new site will be patterned after and compared to a typical proprietary software-based web site, such as a municipal GIS web site.

Many internet sites provide geographic information based on such products as Autodesk MapGuide, ESRI ArcIMS, Intergraph GeoMedia Web Map, MapInfo ProServer and Map Xtream, and ER Mapper Image Web Server (Chang, 2006). This project will attempt to replicate some or all of the functionality provided on a typical ArcIMS-based web mapping site, such as a municipal GIS web site, yet be based on a free web map service.

RESEARCH QUESTION

This project is an attempt to answer the following: Is it possible to create a public municipal geographic information web site based on a free web map service? If so, is it more advantageous to create a public municipal geographic information web site based on a web map service than to create it based on proprietary software?

In answering these questions, additional more specific questions will be addressed. For example, can required GIS functionality be included? Required GIS functionality includes: display of custom map layers; retrieval and display of attribute information of geospatial features; search and display of geospatial features by attribute(s); implementation of common GIS interface tools(layer visibility, navigation, measure, etc.);and geocoding. Finally, will performance be different?

LITERATURE REVIEW

At this writing, very little peer-reviewed literature is available on customizable web map services, primarily because of their recent releases. However, one work on web map services is Boulos’ description of the implementation of a simple interactive map using three different web map services: Google Maps, Google Earth, and Microsoft’s Virtual Earth (Boulos, 2005). The remainder of the literature review was concentrated on state-of-the-art web GIS implementation and how to evaluate GIS web sites.

The evolution of web mapping can be described as generational in context. The first generation delivered maps one browser page at a time. Second generation web mapping sites move much of the processing to the client, making real time panning and zooming possible. Third generation web sites move into completely new representations of geography with three-dimensional representation and oblique aerial photography (Fairhurst, 2005). Qiu and Thakkar proposed a framework of geoprocessing web services using industry standard technologies such as XML, SOAP, WSDL, and UDDI (Qiu, 2004). ). Similarly, additional performance and functionality can be applied to web mapping sites through dynamic integration of Internet GIS components by applying XML, SOA, GML, SVG, etc. (Chang, 2006).Additional performance enhancements include using a pyramid hash index and dynamic data management (Yang, 2005) and asynchronous and coarse-grained services (Tu, 2004).

Baptista and de Paiva discuss optimization techniques for web GIS sites. However, they evaluated GIS performance was based on only one objective measurement: time to initially load the map (Baptista, 2005). Alternatively, Campagna and Deplano suggest a method of evaluating municipal GIS web sites based on categorization of their content and technologies implemented (Campagna, 2004).Another method of evaluating web sites is to determine interface efficiency by evaluating five psychometric scales: Perceived ease of use, perceived usefulness, disorientation, flow, and aesthetics (van Schaik, 2005).

METHODS

The methodology employed was to (1) Select a typical proprietary software-based GIS web site,(2) create a web map service-based GIS web site similar in functionality to the baseline web site, and (3) compare the functionality and performance of the two web sites.

The mapping web site of the City of Allen, Texas was chosen as the model proprietary software site because (a) it is a typical municipal web site and (b) the author had ready access to the web site resources. See Figure 1.

Google Maps API, Yahoo! Maps API and Microsoft’s Virtual Earth were considered as the customizable web map service upon which the web site would be based. Google Maps API was selected as the web map service because it is the most mature APIand is supported by considerable resources (online documentation, user groups, and literature). The Google Maps API is accessed programmatically using JavaScript.

One fundamental function of the web map service-based web site is to display custom data. The Google Maps API can display custom points and polylines as graphic items called overlays.Each feature is represented by one overlay. The data used for this project were obtained from the City of Allen, Texas web site ( The data layers representing public schools, parks, parcels, voting precincts and polling places were downloaded as shapefiles.

Overlays are positioned using unprojected longitude-latitude coordinates. Therefore, the shapefiles were first converted from their native projection (North Central Texas state plane coordinates, North American Datum 1983, in feet) to unprojected longitude-latitude coordinates.

The Google Maps API cannot display shapefiles in their native format. Therefore it was necessary to convert the shapefile data to formats accessible via Google Maps API. Small data sets (less than 1,000 features) were converted to Extensible Markup Language (XML) format files. The Google Maps API contains several functions for reading data from XML files. A short program was written using Visual Basic for Applications and run in ArcGIS Desktop to convert the data. One XML file containing geospatial and non-spatial attributes was created for each small dataset layer.

Large data sets are not suitable for display as overlays because the addition of a large number of overlays(greater than 1,000) adversely affects web site performance. The parcels layer contains 25,861 polygons and is therefore not appropriate for display via overlays. However, the Google Maps API provides for displaying custom raster files. The image files must cover the same area of the Earth and be the same size (256 pixels by 256 pixels) as the Google Maps tiles to display properly. A second VBA program was written and run in ArcGIS Desktop to create image files representing the parcels layer. This created a total of 2,512 files to display the parcels at five different zoom levels.

An image layer cannot be joined with feature attributes. In order to display or query by attributes, the attribute information must be stored in a database. MySQL was chosen as the database because it is freely distributed (for non-commercial applications), is widely used, can interact with common server-side programming languages, and can be spatially enabled. Some processing was required to load the parcel attribute into a MySQL database. For the parcels layer, the longitude and latitude coordinates corresponding to a point within each parcel feature were calculated and stored in new fields. XML files must not have ampersand (&) characters, so all ampersands were removed from the parcel attributes. Shapefile attributes can easily be saved as text files with commas (,) delimiting the values in each field. Commas were removed from the attributes in order to avoid corrupting the output text file. The attribute table was exported as a field comma-delimited file. A new parcels table was created in a MySQL database. The table was loaded with the parcel attributes using the text file as input. A new point geometry field was created in the table. It was populated by creating point objects using the values from the longitude and latitude fields.

A new web site was created which provided access to the functions to be evaluated. The new web site is not intended to duplicate every aspect of the model web site, but rather to provide a platform for a proof-of-concept prototype. See Figure 2.

Attribute queries are handled in one of two ways, depending on the layer involved. In the case of a layer with a relatively small number of features (parks, schools, etc.), the features are held in memory as objects with their respective attribute values. Queries are done by examining the appropriate attributes of each feature and reporting the result.

In the case of a layer with a relatively large number of features (parcels), a JavaScript program on the client submits the query as a parameter to a program on the server. PHP: Hypertext Preprocessor (PHP) was selected as the server side programming language because it is easily integrated with MySQL, is widely used, and is freely distributed. The PHP program formulates the query in appropriate SQL syntax and submits the query to the MySQL database. The program then examines the results and writes the results to an XML format file. A JavaScript program on the client then reads the XML file, creates an object for each feature returned, and displays the objects as point overlays. When the query is spatially oriented, as when an identity is requested, the longitude and latitude coordinates of the point are passed to the same PHP program as a parameter. The PHP program creates a minimum bounding rectangle around the point and submits the spatial query to the MySQL database. The program then handles the results as above.

Geocoding is accomplished using the Google Maps geocoder which is available through the Google Maps API. The geocoder returns a JSON (JavaScript Object Notation) object containing the location point(s) and the proper address formatted as xAL (eXtensible Address Language), an international standard for address formatting. An overlay representing the location point is created and then added to the map.

Common GIS interface toolsare included to provide an interface more familiar to the GIS professional. A location map and a graphic scale are added to the interface using controls provided by the Google Maps API. Additional tools were created with custom JavaScript code. Datasets are organized as layers in a table of contents which displays each layer name and its symbology. Layers are made visible and invisible by means of a checkbox by the layer name. Map tools (zoom in, pan, measure, etc.) are represented by buttons on the web page. Zooming in is accomplished by click two points on the map to define a rectangle. The map is re-centered on the midpoint of the rectangle and zoomed to the nearest appropriate scale. Map coordinates are provided in longitude/latitude coordinates. A measure tool displays the great circle distance between clicks on the map.

RESULTS

The model proprietary software-based web site and the web map service-based GIS web site were evaluated on the following objective criteria:

Time to load page initially
Time to pan a full map width
Time to zoom to a different scale
Time to display a large dataset layer
Time to submit, process, and display the results of an attribute query
Time to submit, process, and display the results of a spatial query
Time to geocode an address
Geocoding distance error

Each test was performed 10 times (20 for the geocode tests) for each web site under the most identical conditions as possible. Tests were done on the same computer using the same browser software. See Figures 3 and 4.

The web map service-based GIS site loaded faster and had a near instantaneous pan interval. However, the proprietary software-based web site showed better performance in zooming in to a new map extent and displaying a large data set.

CONCLUSIONS

A new web map service-based GIS web site, patterned after an existing proprietary software-based municipal GIS web site, was successfully created. All required GIS functionality was implemented successfully in the new web site. Performance tests of the two web sites did not yield overall superiority of one site over the other. Preparing the web sites probably required approximately the same amount of effort.

One clear advantage of the web map service-based GIS web site is monetary cost. Licensing proprietary software for GIS web sites can cost thousands of dollars per year, whereas Google Maps API, PHP, and MySQL are freely distributed for not-for-profit users. In addition, it was not necessary to procure and process base map data, nor was any preparation for geocoding required. Furthermore, high-resolution imagery is native to Google Maps.

Many limitations of using Google Maps as the basis for a GIS web site became apparent during this project. The primary disadvantage of a GIS web site based on a web map service is the requirement to pre-process custom GIS data prior to its use on the site. Data stored as shapefiles, a popular open-source GIS format, can not be used in their native format. Data are displayed in Mercator projection which gives increasingly distorted areas as one moves poleward from the equator (Gibson, 2006). Google Maps does not support Scalable Vector Graphics (SVG). Polygon overlays are not supported. Metadata for the image and map tiles provided by Google Maps are not available. Google Maps data is provided as small image files and major transportation features are in most cases labeled on every tile. When a map window is large enough to display several tiles simultaneously, some features may be labeled excessively for the given map scale and size as seen in Figure. 5. In addition, the Google Maps API is under constant development and a new update is released almost every week.

This project has shown that it is possible to create a web map service-based GIS web site that is at least approximately equal in overall performance to a similar proprietary software-based web site. Areas of future research include evaluating and comparing scalability of both kinds of GIS web sites; enhancing web site performance; streamlining the implementation process; and exploring the spatial capabilities of future versions of MySQL.

REFERENCES

Allen, Texas, City of,

Baptista, C.d.S., and de Paiva, A.C., 2005. On performance evaluation of web GIS applications. Proceedings of the 16th International Workshop on Database and Expert Systems Applications (DEXA’05).

Boulos, M.N.K., 2005. Web GIS in practice III: creating a simple interactive map of England's Strategic Health Authorities using Google Maps API, Google Earth KML, and MSN Virtual Earth Map Control. International Journal of Health Geographics 4, 22.

Campagna, M. and Deplano, G., 2004. Evaluating geographic information provision within public administration websites. Environment and Planning B: Planning and Design 31, 21-37.

Chang, Y-S and Park, H-D, 2006. XML Web Service-based development model for Internet GIS applications. International Journal of Geographical Information Science 20 (4) April 2006, 371-399.

Fairhusrt, R., 2005. Next-generation webmapping. The Bulletin of the Society of Cartographers 39 (1-2) 57-61.

Gibson, R., Erle, S., 2006. Google Maps Hacks. O’Reilly Media, Sebastopol, CA.

Qiu, F. and Thakkar, P. 2004. Online Geo-referencing of satellite imagery using GIS web services, IGARSS 2004: IEEE International Geoscience and Remote Sensing Symposium Proceedings 1-7, 4783-4786.