Using MapServer to Integrate Local Government Spatial Data

Transcription

1 Proceedings of the Open source GIS - GRASS users conference Trento, Italy, September 2002 Using MapServer to Integrate Local Government Spatial Data Richard W. Greenwood Greenwood Mapping, Inc., P.O. Box 461, Wilson, WY, 83014, USA, tel rich@greenwoodmap.com, web 1 Introduction Local government in the United States has responsibility for managing and regulating three aspects of privately owned land: 1. Property ownership registration, and the recording of related legal documents for public access and review. 2. Property tax assessment. 3. Land use zoning, development regulation, and the issuance of building and construction permits. These tasks are usually handled by different departments within the local governmental body. Over the course of the last two decades, computerized database management systems (DBMS) have come into wide spread use by these departments. However, the DBMS are frequently isolated from each other, despite managing various aspects of the same pieces of property. The various systems are frequently unable to relate data common to a single parcel of land. This data isolation leads to a vertical government, in which each department has its own separate (vertical) system for conducting its business [1]. Teton County, Wyoming, USA, the primary governmental body discussed in this paper, employs no less than five different DBMS in the three departments that manage privately owned parcels of land. The challenge of relating the various DBMS is exacerbated by the fact that three different numbering systems are used for the same parcels of land. In 1994 I was contracted by Teton County to build a parcel based GIS that would serve the three departments dealing with land parcels, and interface to the spatial components of their respective DBMS. The system was initially implemented on MapInfo, a proprietary, desktop GIS. The system quickly grew in popularity, both within the county government departments, and with non-governmental users. We soon had far more users than we anticipated, and the cost of software and training was increasing rapidly. Although we had more users than we had anticipated, most of the system users were performing relatively basic queries, look-ups, and map viewing. The majority of the users needed easy access to large data stores, but did not need sophisticated spatial analysis capabilities.

2 2 Using Mapserver to Integrate Local Government Spatial Data 2 Web-based GIS A wed-based GIS could meet the requirements of the majority of our users and bring several distinct advantages over desktop GIS software: cut software costs reduce the load on IT staff for software installation, support and maintenance shorten the user s learning curve provide a superior environment for DBMS integration and presentation Desktop GIS programs are generally weak at presenting complex attribute data such as one-to-many relationships. Displaying anything but the most basic attribute data usually requires programming or scripting in the GIS vendor s proprietary language. Desktop GIS programs are limited in the DBMS to which they are able to connect, and rarely can support all of the legacy systems that exist in even a moderate sized body such as a county government. However, there are a wealth of powerful web based tools for presenting attribute data from virtually any DBMS. With the advent of web-based GIS, it is possible to integrate spatial GIS data with the already excellent array of HTML database presentation and manipulation tools. Additionally, the developer can use open, standards based tools, rather than being restricted to the proprietary set of tools provided by a given desktop GIS vendor. Before starting development of the Teton County web-based GIS, I did an informal evaluation of three web map servers: MapXtreme (MapInfo Corp.), ArcIMS (ESRI) and MapServer. MapXtreme is fast and has some nice features, but its power unit pricing put it outside of Teton County s budget. ArcIMS s Java servlet based approach proved to be exceedingly complex for our needs. MapServer distinguished itself on many fronts, particularly its speed and flexibility. And as free, open source software, it fit within our budget, and also within my personal philosophy. 3 MapServer MapServer supports two different modes of operation: CGI and MapScript. In CGI mode, the MapServer executable is called directly, and renders the entire HTML page based on parameters passed in the query string, and static configuration files stored on the web server. Using MapScript, MapServer is called by a server-side scripting language. The server-side script parses the query string, renders the final page and calls MapServer functions as necessary. PHP is the best documented, and probably most widely used MapScript interface, but there are also Perl, Python, and Java MapScript interfaces. While the MapScript interface allows for greater flexibility with server-side control of program logic and data processing, the CGI interface is very mature and feature rich. My application emulates a simple desktop GIS interface, which requires more client-side scripting than server-side scripting. MapServer s CGI mode is more than adequate for supporting most aspects of my application, with the only exceptions having to do with database issues. The MapServer CGI interface relies on two files stored on the web server: a Map file and a Template file. The Map file is an ASCII file containing configuration information and object definitions. Configuration information includes items such as the path to the data files and the map s units and projection. The Map file also defines the graphic objects (the main map, reference map, scale bar, and legend) and the look and characteristics of

3 Richard W. Greenwood 3 each of these objects. Finally, the Map files define the layers, including the layer s thematic characteristics (style, color), labeling, and display scale range. The Template file is an HTML file with specially tagged replaceable parameters designated with square brackets: []. The Template file is the HTML page that the users sees in their browser after MapServer has filled in appropriate values for the replaceable parameters. For example, a Template file line such as: <P> Map Scale 1:[scale] </P> might display in the user s web browser as: Map Scale 1: This, however, is a deceptively simple example. In many cases MapServer has to do considerable processing for each replaceable parameter, such as in the case of rendering a map image. In this case MapServer creates a raster image file of the requested map. The image file is assigned a random name and is saved on the web server s local drive. The parameter inserted into the template file is the path and image file name. For example, the Template file line: <IM G src= '[im g]'> would cause MapServer to render the map and output the original line as <IMG src= '/tmp/tc png' > (the path and name of the newly created map image file have replace the [img] tag). MapServer reads the Template file and creates map objects for the HTML page when it encounters square brackets. The data for the map objects and their style are defined in the Map file. But how do we tell MapServer what part of the map we want to see, or which layers to display? This is where the query string comes into play. The query string is that part of the Universal Resource Identifier (URI) which follows the question mark. Each element of the query string is in the form of parameter=value, and elements are separated with an &. A simple URI with comments follows: The server s Internet address /cgi-bin/mapserv The MapServer executable program? Indicates the start of the query string map=tc.map Map file (described above) &imgext= Real world extents of current map &mode=browse Zoom or Pan mode &zoomdir=1 Zoom direction (we are zooming in) &zoomsize=2 Zoom factor (2x) &img.x=192&img.y=146 User s mouse click location on image (this will become the new map center) &layers= Roads+ow nership Layers to display The above URI tells MapServer that we want to zoom in 2x centered around the mouse click, and also tells MapServer what layers we want to have displayed. Given the current map extents and the user s mouse click location, MapServer has the information necessary to calculate and render a new map image. The preceding example illustrates zooming in a fixed amount around a single mouse click. GRASS and most desktop GIS allow the user to specify a rectangular zoom window by defining diagonally opposite corners of the rectangle either with different mouse keys, or by dragging the mouse (holding down the left mouse button while moving the mouse). Unfortunately, standard web form controls do not support either multiple button mice, or mouse dragging. There are two different techniques that can provide mouse dragging behavior in a web browser: Dynamic HTML (DHTML) or Java applets. Neither technique is universally supported on all web browsers. Like many

4 4 Using Mapserver to Integrate Local Government Spatial Data MapServer application developers, I chose to provide both a Java enabled, and a non-java version of my application. Figure 1. Zoom window rectangle using Java applet 4 Presenting Attribute Data Providing easy access to complex attribute data was one of the primary design objectives of my project. MapServer provides a couple of mechanisms for presenting attribute data after the user has selected one or more spatial objects. Displaying a layer s internal attribute data can be handled well within MapServer using a parameter substitution scheme similar to the one described in the preceding section. For each class within a layer, an HTML Template file is defined. When MapServer is in query mode, it reads the Template file, passing it to the web server with appropriate values substituted for the field names within square brackets []. A portion of the HTML attribute display Template file might look like this: <li>n am e1 : [NAM E1]</li> <li>n am e2 : [NAM E2]</li> <li>m ailing Address : [AD DRESS]</li> <li>m ailing Address : [CITY], [ST ATE] [ZIP]</li> And if the user were to query my property, the code above would be displayed in the user s browser as follows: Name1 : GREENWOOD, RICHARD W. & Name2 : WIENEK E, C ONSTANCE B. Mailing Address : P.O. BOX 461 Mailing Address : WILSON, WY The attribute values for the selected spatial object have been substituted in for the bracketed field names. Attribute data for either a single object, or multiple objects in the same layer may be displayed in this manner. In order to allow the user to select multiple objects, I use the same Java applet that is used for defining the zoom window rectangle, and that was described above. (See figure 1). An important alternative to the Template File is the Template URI. Rather than MapServer processing a Template file, the web browser is re-directed to a new location.

5 Richard W. Greenwood 5 The simplest scenario would be that each object in the layer had a corresponding HTML page. The Template URI definition might look like: MapServer would substitute in the object s ID for the page name and redirect to the new location. A very powerful option is to use the URI to point to a scripted page, which can then provide dynamic content beyond the capabilities of MapServer. The scripted page could be used to present one-to-many relationships, connect to DBMS not supported by MapServer, or perform additional processing and analysis. For example: server.com/query_handler.php?id=[id] Again, MapServer substitutes the object s ID into the URI before redirecting, but in this case the ID is a part of the query string, and is processed by a server-side script. The redirection approach has one notable limitation; since you can only redirect the browser to one URI at time at any given time, you can not use redirection to display attribute data when more than one object could be selected. I wanted to allow the user to select multiple objects for attribute display, but I also wanted to employ some server-side scripting to present attribute data from several tables having one-to-many relationships. I ended up letting MapServer do parameter substitution in a Template file to present some basic data having a one-to-one relationship with the spatial object. On the initial one-to-one attribute page I then provided a link to a scripted page for displaying the attribute data represented in one-to-many relationships. (See Figure 2) The attribute data that I am working with has to do with land parcel information. The one-to-one data included things such as the current property owner, physical address, and legal description. This data comes from six tables stored in three DBMS maintained by the Tax Assessor s Office, the Planning and Development Department, and a municipality. The data is stored internally (within the shape file or PostGIS layer). Most of the data is updated bi-weekly by an automated process. The data having a one-to-many relationship with each parcel are the land records, which are maintained within a separate DBMS. The land records include property transfer deeds (chain of title) as well as legal documents affecting real property such as easements, liens, and financing agreements. The documents are scanned and indexed by the County Clerk s Office for public access. By combining the Template file and some server-side scripting, a user can navigate from an interactive map to a scanned legal document in just four steps (four mouse clicks). First the user would select the parcel(s) of interest on the map and the basic one-to-one data would be displayed in a new web page, as shown in Figure 2.

6 6 Using Mapserver to Integrate Local Government Spatial Data Figure 2. Attribute data displayed by M apserver using a Tem plate File The complex land records data, which has a one-to-many relationship with the parcel, is accessed from the Pidn link (Parcel ID Number). This directs the user s web browser to a server-side scripted page showing a chronological abstract of documents associated with the selected property as shown in Figure 3. Figure 3. Attribute data having a one-to-many relationship, presented through server-side scripting

7 Richard W. Greenwood 7 The left side frame lists the recorded documents associated with the selected parcel. Clicking on a document number in the left frame displays details of that document in the right side frame. The right side detail frame includes three additional one-to-many relationships associated with the document: multiple grantors, multiple grantees, and multiple parcels. Initially these are displayed in drop-down list boxes to prevent frame scrolling. Clicking the document number in the right frame displays the scanned document as shown in Figure 4. figure 4. Scanned image of a recorded document 5 Conclusions A well designed GIS can, and should, bring disparate datasets together, rather than adding yet another isolated vertical data structure in a local government setting. The wide range of web-based tools for accessing DBMS, when combined with MapServer, can be used to produce a GIS with unparalleled database capabilities. References [1] Hoch, Robert, GEOWorld, Technology Tangled Web, Internet Mapping Lures Local Governments, Volume 13, No. 8, 2000