The second presentation is a presentation by Richard Greenwood. It's using MapServer to integrate local government spatial data.

...organizers of the conference for their hard work and for inviting us to this beautiful country. I'm going to be presenting a very basic introduction to MapServer and I'm going to...

I should say the University of Minnesota MapServer and I'm going to present it in the context of a local government project that I've been working on for a few years. In the United States, local government is responsible for three aspects of managing

and regulating privately owned land. That's property tax assessment, building and development, permitting and regulation, and property ownership registration. That includes recording of legal documents that affect real property ownership and making those documents available for public review.

Over the course of the last couple of decades, database management systems have come into quite widespread use within these departments. Unfortunately, there's very little integration between the databases. In other words, despite managing the same piece of property,

the databases have little or no correlation. This has led to what many people describe as vertical government in which each of the departments is operating on a separate, isolated way of doing business. Eton County, Wyoming is my home and the subject of this presentation.

The three departments that manage these aspects employ five different database management systems. I'm pounding the problem of relating the various databases is that there are three different numbering schemes that are used among the databases.

In 1994, I was contracted by Eton County to build a parcel-based GIS that would support these departments and that would also integrate the spatial components of their various databases. Initially, we anticipated a fairly small group

of users doing relatively sophisticated GIS tasks. The opposite proved to be true. We found we had a lot more users than we wanted and that their application of it was quite basic.

They were using it to do basic queries and view maps and so on. Initially, we had developed the system in MapInfo which is a proprietary desktop GIS and we were having difficulty, budgetary difficulty in keeping

up with the licenses necessary for the increased number of users that we had which naturally led us to look at a web-based GIS. The web-based GIS really offered us a few options or advantages I should say. Obviously, our initial goal is to cut software costs.

It also has a potential to reduce load on the information technology staff for supporting and maintaining the system. We also believe that it could shorten the user's learning curve by focusing the user interface strictly on tasks that were necessary or appropriate for the local government user and stripping off user interface components

that weren't relevant to those users. And last but most interesting to me was that I really felt the web-based environment provided better integration or options for integrating the various attribute data.

When I say better options for integrating the attribute data, when we work with a desktop GIS, we're usually relatively limited in the number of database management systems that we can connect to.

Generally, these are not the legacy systems that we need to access in local government and we're also fairly limited in presenting that attribute data. Presenting anything but the most basic attribute data generally requires some programming. In other words, to represent a one-to-many database relationship,

you typically end up having to do a fair amount of programming in the desktop GIS programming environment, which is a little bit restrictive. On the other hand, there are a number of web-based or HTML-based tools that provide wonderful access to virtually any database that's out there

and a tremendous amount of flexibility for presenting that attribute data. Now, more recently, with the advent of web-based GIS, we can also present the spatial data quite nicely. I did a quick review of various web GIS servers that are available

and Map Server distinguished itself quickly, partly on speed, definitely on flexibility. It's got a number of interfaces and I'm going to talk just about one of them this morning. Obviously, as free software, it fit within government budgets

and also my own personal philosophy. Map Server can operate in two fundamentally different modes. There's a CGI mode. CGI is Common Gateway Interface, which is a fairly standard API of the web or in a scripted mode.

In the CGI mode, Map Server basically does pretty much all the work on the server side. In other words, it receives and parses requests from the client browser. It processes that request. It renders maps as necessary

and it generates the final page, which is passed back to the client. In scripted mode, it's a little bit different. Some server-side scripting language receives the request, parses it, and presents the final page to the client.

Along the way, it'll call Map Server as necessary to render images or possibly execute a query or something like that. After evaluating the two interfaces, I found the CGI mode worked well for me. My goal was to emulate kind of a desktop GIS. This is a screenshot of it.

I wanted to give the user feedback as to what mode they're in. In other words, here I'm in a zoom mode. Here I'm in a query mode. I've got these little help things up there to facilitate the learning of the thing. As you can see, that really needs to be done on the client side.

We don't want to go back and forth to the server to do that sort of thing. I opted for the CGI interface, and I'm going to kind of give you a quick introduction to it. I guess I should back up just for a moment. The scripted interface is available in various server-side scripting languages.

PHP is the most widely used one, and I think it's the most mature. It was developed by DM Solutions. I should point out that Daniel Morissette is here at the conference. Daniel and his group have been very active contributors to the development of Map Server in general

and the PHP interface in particular. So I say thanks. There are also scripted interfaces on the server side in Perl. There's some development in Python and Java

and possibly some other languages that I'm not up to speed with. At any rate, I'm not going to talk about the scripted interface. This is part of the CGI interface. The CGI interface is based on two files that control Map Server's behavior,

the two files being on the server. Two files are what's called the map file, which is basically a configuration file, and then template files, which are HTML documents. This is a simple example of a map file. In other words, a configuration file. It does a few things.

Here you can see that we're defining various things. This is basically like a location in grass. In other words, this is the spatial expense of the units. Here you can see we've got a definition for a projection. It also has got various paths that are used by Map Server, kind of like information that's stored in the dot files of grass.

Additionally, the configuration file defines various spatial components of the map. This is a definition for a vicinity map. This is a definition for legend. Needless to say, I'm not going to go into the specifics of these definitions. They're quite well documented on the University of Minnesota's website.

Lastly, in the map configuration file, we define our layers. Here I have two very simple layer examples. This is a raster layer. It's tiled. Map Server supports tiling of both raster and vector data.

Tiling is a real important boost to performance. The other thing you can see that I'm doing here, and I'm not really recommending this necessarily as a good practice, but Map Server does support on-the-fly reprojection through the Proj4 library.

I say it's maybe not a good practice because there is a noticeable performance hit for on-the-fly reprojection. I use it just for some of the really remote outlying areas so that I can provide the user with seamless coverage, but I'd recommend that you project everything into your base projection prior to serving it up on the web if performance is an issue.

And then lastly, this is a simple example of a vector layer. This is a polygon coverage, and these classes define the stylistic components of the layer, in other words, the hatch pattern and the color and so on.

So at any rate, the map file is kind of a configuration file. The second important file or class of files, I should say, that control Map Server's behavior is the HTML template file. The template file is a simple HTML document that Map Server passes back out via the web server to the client

with some substitution applied to it. This is a simple HTML document, but here we have the square brackets, which are an indicator to Map Server to do some form of substitution. This is a simple example here.

The keyword scale directs Map Server to calculate the current map scale substituted into the HTML document, and it would display something like this in the user's browser. That's rather a simple example. In some cases, the substitution requires a significant amount of processing.

This is an HTML image script, and what we're doing here is directing Map Server to render a map image for the user. This requires, of course, that the Map Server visit the configuration file and extract the necessary information from it, and it also depends on parameters that have been passed down from the client

as to what areas should be displayed, what layers should be displayed, and so on. So in this case, Map Server, based on parameters that have been passed from the client and configuration information, will render a new map, and that's an image file that's saved onto the Web Server's hard disk. It can be in a PNG, a GIF format, JPEG.

I believe PostScript or PDF, but I have not worked with that. At any rate, the Map Server generates this image, saves it onto the Web Server, and then passes up the HTML document with this type of substitution.

In other words, the name of the newly generated image and the path in which it's stored, the user's browser then inserts this image into the HTML page, and it might work something like that, look something like that. So basically we have these two classes of files that are stored on the server.

The third component to directing Map Server, controlling it, is the URI, the Uniform Resource Identifier. Again, I won't go into the specifics of it, but this is very much like passing instructions to grass on the command tail.

In other words, this is a simple dissected URI. This is the name or path to the server. This is the executable. And then this is the URI format for parameters that are passed. Basically what we're doing here is we're instructing Map Server to zoom in by a factor of two around the user's mouse click.

I mentioned a moment ago one of the things that really attracted me to moving our GIS onto a web-based platform is the ability to do a better job of integrating the attribute data

and also do a better job of presenting it. Map Server provides a couple of tools or techniques. I should say Map Server, again, we're just talking about it in the CGI mode because the scripted mode has a whole different set of tools. But the CGI interface provides different techniques

for presenting attribute data. The first one is for data that's internal. In other words, it's stored with the spatial data. In other words, either in the DBF associated with the shapefile or in a post-GIS relational database. It depends on a substitution scheme very similar to the keyword substitution

I described earlier, but in this case what we're doing is the substitution is on field names in the database. So in other words, again, the square brackets are indicating that some substitution is required, but what we're doing is we're substituting in the attribute data associated with the field

and it would display in a browser, the user's browser, something like this, had they selected my piece of property. The other method that Map Server provides is redirection. This you would use in a case where you did not have a one-to-one relationship

with your spatial objects or where you wanted to fetch data out of a different database management system that was possibly not supported by Map Server or that you could not access. I've got two simple examples here. This is a very simple one in which case you have an HTML page

that has a unique HTML page for each spatial object on a map layer. In this case it's similar to the URI. What we're doing is a redirection to a server-side scripted page and instead of specifying a page, we're passing up the primary key

of that spatial object to the server-side scripted page. I'm kind of short on time. I'll go through this rather quickly. I ended up using a combination of both of those techniques. Initially when the user selected one or more parcels, I presented the data that had the one-to-one relationship with the property

and I used Map Server to do that and stored it natively within the shapefile database. Then on that page I provided a link to a server-side scripted page which presented the data that had a one-to-many relationship.

This is kind of boring stuff, but it's very important for people that are involved in land records and so on. These are the various documents that are associated with this property, in other words having a one-to-many relationship, and as the user selects different documents on this side, somewhat more detail is available on the right side of the screen,

again having a one-to-many relationship with an individual document. And then lastly, the user can click on the index number and get the scanned document. So what we've got is a situation where with two or three clicks of the mouse, a user can go from a simple graphical map

through a description of the attribute data to the actual scanned image. As with that, I guess the only closing remark I did want to make was we had some discussion of free data, and I'm personally not much of a developer.

I don't contribute a lot to the open source or free software community, but I am a data developer. And those of us that don't develop codes certainly do develop data, and we're in a wonderful position to be advocates for free data, and from personal experience we have some leverage in that.

I know that's off topic. Thank you very much. Are there any questions?

Raduban, I have a question regarding the... Okay, I have a more specific question regarding the... How do you provide those services? I mean, web server is running at one computer,

and the geographic database, geographic data, such as rasters or aerial images, they are on physically another computer? No, generally it's easiest if you keep your data and map server

all on the same box for security purposes. And the one that I've demonstrated here, the database management system, is all of the data that's relevant to map server, that map server has access to is on the same box, on the same server. The only thing that's not on it is the database management system,

which is called remotely. If you can keep it all on the same server, it's probably a slightly better practice from a security perspective. So if it's located at another machine, what protocol do you use to transfer the data, or how are those machines connected together?

In the case of the database, it uses the database management systems interface, in other words, the local client on that server. If you're simply copying files locally, obviously you can use TCP IP.

The third thing that I should have really talked about, actually map server is a very broad topic, and 20 minutes really doesn't do it justice, but there is open web... What am I trying to say? The Open GIS Consortium's web server interface is available, both as a client and a server. So if we had spatial data, for example,

that was on another maybe possibly remote server, we can, through an internet connection, integrate that in also. Does that answer your question? It's a very short question.

Your front end... I'm Paul McClutt. Your front end shows us the jungle of different databases, but what I didn't understand is how it is easier for the foresters, for the maintainers of these databases to do their job.

Are there some databases... Is the structure of some databases changing? Or is there a unifying of some databases?

Because the main work, I think, is to put the data into the different formats into... And if you see that there are different similar developments, perhaps it is...

I think it is easy to change the databases if there is such a development. I'm not sure I totally understand your question, but what we're doing is presenting data or allowing for query of data.

The system is one way. In other words, it was not designed for user input. That's still done in the respective separate databases. What we have done to ease the access to these various unrelated data sets

is to bring them all together in the GIS context. In other words, frequently departments are proprietary of their own data, and we're using GIS as kind of an enabling technology to bring them all together into a single environment so that for a single piece of property, for a single spatial object,

we can fetch in attribute data from various databases. We know I cannot change the structure of the databases because of turf battles or proprietary concerns. Does that answer your question? We can maybe talk offline if...

Thank you very much.