Transactions In Gis

8/13/2019 Transactions In Gis

1/20

Transactions in GIS, 2003, 7(4): 447466

2003 Blackwell Publishing Ltd, 9600 Garsington Road, Oxford OX4 2DQ, UK and350 Main Street, Malden MA 02148, USA.

Research Article

Building Web-Based Spatial InformationSolutions around Open Specificationsand Open Source Software

Geoffrey Anderson

Cloudshadow Consulting, IncBoulder, Colorado

Rafael Moreno-Sanchez

Department of Geography

University of Colorado at Denver

Abstract

Geographic Information Systems (GIS) are moving from isolated, standalone,

monolithic, proprietary systems working in a client-server architecture to smaller

web-based applications and components offering specific geo-processing functionality

and transparently exchanging data among them. Interoperability is at the core of

this new web services model. Compliance with Open Specifications (OS) enables inter-operability. Web-GIS softwares high costs, complexity and special requirements

have prevented many organizations from deploying their data and geo-processing

capabilities over the World Wide Web. There are no-cost Open Source Software (OSS)

alternatives to proprietary software for operating systems, web servers, and Relational

Database Management Systems. We tested the potential of the combined use of OS

and OSS to create web-based spatial information solutions. We present in detail the

steps taken in creating a prototype system to support land use planning in Mexico with

web-based geo-processing capabilities currently not present in commercial web-GIS

products. We show that the process is straightforward and accessible to a broad audience

of geographic information scientists and developers. We conclude that OS and OSSallow the development of web-based spatial information solutions that are low-cost,

simple to implement, compatible with existing information technology infrastructure,

and have the potential of interoperating with other systems and applications in the future.

1 Introduction

With a few exceptions (e.g. the Geographic Resources Analysis Support System GRASS;

http://www.cecer.army.mil/grass/GRASS.main.html), geographic information technology

Address for correspondence: Rafael Moreno-Sanchez, Department of Geography, University ofColorado at Denver, Campus Box 172, P.O. Box 173364, Denver, CO 80217-3364, USA. E-mail:[email protected]
http://www.cecer.army.mil/grass/GRASS.main.htmlhttp://www.cecer.army.mil/grass/GRASS.main.html


2/20

448

G Anderson and R Moreno-Sanchez

Blackwell Publishing Ltd. 2003

has developed as isolated, standalone, monolithic, proprietary systems. This is rapidly

changing as geo-processing principles and functionality are moving out of a tightly

defined niche into the information technology (IT) mainstream. Isolated, standalone

systems are being replaced by integrated components, and large applications are being

replaced by smaller, more versatile applications that work together transparently acrossnetworks. Of these, the World Wide Web (WWW or the web) is becoming the core

medium for distributed computing in IT generally and in the geo-processing domain

specifically (Hecht 2002b). In other words, Geographic Information Systems (GIS), once

focused on data and tools implemented with client-server architecture, now are evolving

to a web services model (Dangermond 2002). In this new architecture the web is used for

delivering not just data, but geo-processing functionality that can be wrapped in inter-

operable software components called web services. These components can be plugged

together to build larger, more comprehensive services and/or applications (Hecht 2002c).

Interoperability between heterogeneous environments, systems and data is fundamental

for the implementation of this web services model.

With respect to their IT infrastructure, organizations aim to: (1) maximize productivity

and efficiency; (2) protect critical information infrastructure; and (3) overcome prob-

lems related to data sharing, security and data maintenance, as well as software special

requirements and steep learning curves. The WWW offers the potential benefits of

flexibility, ubiquity, and reduced costs and risks of obsolescence and isolation. However,

when organizations try to use the web as a platform to deliver geographic data and provide

geo-processing functionality to their end users, they commonly find that commercial

web-GIS software raises the following issues: (1) it does not currently offer out of the

box geo-processing functionality to perform many of the analyses demanded by their

end users; (2) it is expensive; (3) it has a steep learning curve; (4) it requires that some

of their IT personnel become specialists in the software operation and maintenance; and

(5) it is difficult to integrate with existing IT infrastructure (personnel skills, software

and applications).

The use of OS and Open Source Software (OSS) offer the potential to overcome the

abovementioned issues and facilitate the deployment of geographic data and geo-processing

functionality on the WWW. There is a growing interest in the use of OS. For example,

the British Ordnance Survey is using the Geographic Markup Language (GML) OS to

deliver the Digital National Framework on the web and to mobile devices (Holland 2001;

http://www.ordinancesurvey.co.uk/dnf/home.htm). According to Lowe (2002), there is

a growing market for OSS products fed by small organizations and regional government

agencies that cannot afford proprietary softwares (web-GIS, DBMS and web servers)

costs, complexity, steep learning curves, training costs, and special requirements. There

are already several successful examples of the use of OSS to create basic web-mapping

functionality (see cases described by Lowe 2002 and Ramsey 2002).

In spite of this growing interest, little has been published about the combined use

of OS and OSS for the creation of web-based geo-processing applications. Even less is

found in the form of detailed explanations of how they can interact and complement

each other to create these applications. This article aims to contribute to the knowledge

base about OS and OSS, and how they can be used to create web-based spatial informa-

tion solutions. We demonstrate the process through a case study in which we created

a prototype system to support land use planning in central Mexico. The system imple-ments geo-processing functionality currently not available out of the box in commercial

web-GIS software. The article is organized as follows: section 2 defines OS, OSS and
http://www.ordinancesurvey.co.uk/dnf/home.htmhttp://www.ordinancesurvey.co.uk/dnf/home.htm


3/20

Web-Based Spatial Information Solutions

449


interoperability, and provides the necessary background regarding the organizations and

efforts to create OS; section 3 defines and provides a brief background of the specific OS

and OSS technologies used to create the web-based spatial information system described

in this paper; section 4 presents a brief background about the need for the system and

a detailed explanation of the process followed to create a prototype web-based spatialinformation system with querying and Boolean-intersect overlay geo-processing capab-

ilities to support land use planning in central Mexico; section 5 presents a discussion

of the implications and difficulties in applying these technologies; and finally, section 6

presents conclusions and suggestions for future research and implementations.

2 Defining Open Specifications (OS), Interoperability, and Open SourceSoftware (OSS)

Open Specifications provide software engineers and developers information about a given

specification as well as specific programming rules and advice for implementing the

interfaces and/or protocols that enable interoperability between systems. The OpenGIS

Consortium Inc. (OGC) (http://www.opengis.org)defines interoperability as the ability

for a system or components of a system to provide information portability and inter-

application cooperative process control. In the context of the OGC specifications this

means software components operating reciprocally (working with each other) to overcome

tedious batch conversion tasks, import/export obstacles, and distributed resource access

barriers imposed by heterogeneous processing environments and heterogeneous data.

Herring (1999) and Kottman (1999) present an in-depth discussion of the OpenGIS

Data Model and the OGC process for the creation of OS respectively. Software products

can be submitted for testing their interfaces for compliance with OGC OpenGIS Imple-

mentation Specifications (see http://www.opengis.org/techno/implementation.htm for

the most recent approved and in process specifications). Initially, the only OpenGIS

Specifications that products could conform to were the OpenGIS Simple Features

Specifications for CORBA, OLE/COM and SQL (McKee 1998), but there are now 11

different specifications. Within computer environments there are many different aspects

of interoperability (Vckovski 1998): (1) independent applications running on the same

machine and operating system, i.e. interoperability through a common hardware

interface; (2) application A reading data written by another application B, i.e. inter-

operability through a common data format; and (3) application A communicating with

application B by means of interprocess communication or network infrastructure,

i.e. interoperability through a common communication protocol. Besides technical issues,

there are also interoperability topics at higher levels of abstraction such as semantic

barriers (Harvey 1999, Seth 1999). A system based on the OS described in a later section

of this article would be able to achieve a level of interoperability of the second above-

mentioned type.

According to Hecht (2002b) interoperability is desirable for the following reasons:

(1) it allows for communication between information providers and end users without

requiring that both have the same geo-processing or viewer software; (2) no single

Geographic Information System (GIS), mapping tool, imaging solution or database answers

every need; (3) there are large numbers of database records with a description of loca-tion that have the potential to become spatial data, and also, advances in several tech-

nologies (e.g. GPS integrated into mobile devices) are increasing the number of database
http://www.opengis.org/http://www.opengis.org/techno/implementation.htmhttp://www.opengis.org/techno/implementation.htmhttp://www.opengis.org/


4/20

450



records with location information; (4) the number of software companies offering

components to deal with geographic information is growing; (5) it is more efficient to

collect data once and maintain them in one place (this is particularly cost effective if

communities of users can find, access and use the information online, so they do not

need to access, retrieve and maintain whole files and databases of information for whichothers are responsible); (6) the ability to seamlessly combine accurate, up-to-date data

from multiple sources opens new possibilities for improved decision making and makes

data more valuable; and (7) the ability for multiple users, including non-GIS experts, to

use a particular set of data (perhaps at different levels with different permissions) also

makes the data more valuable. Gardels (1997) discusses how compliance with OGCs

OpenGIS specifications and the resulting interoperability can contribute to integrating

distributed heterogeneous environments into on-line environmental information systems

(EIS). He points to three technical strategies (federation, catalogs and data mining) for

the integration of these systems, and how they are heavily dependent on interoperability

among diverse data sources, formats and models. He concludes that properly designed

geodata access and analysis tools, combined with open environmental information systems,

can provide sophisticated decision support to the users of geographic information.

Two organizations have been coordinating the development of the open specificat-

ions used in this paper: the OpenGIS Consortium Inc. (OGC) (http://www.opengis.org)

and the World Wide Web Consortium (W3C) (http://www.w3.org). The W3C has created

more than forty technical specifications (http://www.w3.org/TR/) and as of January

2002, the OGC has adopted nine OpenGIS Implementation Specifications and 11 candidate

specifications are in the works (Hecht 2002a; a roadmap to the specifications work is

presented at http://www.opengis.org/roadmap/index.htm).

Briefly, Open Source Software (OSS) are programs whose licenses give users the free-

dom to run the program for any purpose, to modify the program, and to freely redistribute

either the original or modified program without further limitations or royalty payments

(http://www.opensource.org/docs/definition.php). Among the most well known OSS

projects are the Linux operating system and Apache web server. Sometimes the term

Open Technologies is used to refer to these projects and others such as XML, HTML,

TCP/IP, and Java technology. A comprehensive list of GIS-related OSS can be found at

http://opensourcegis.org/. According to Wheeler (2002), OSS reliability, performance,

scalability, security and total cost of ownership are at least as good or better than its pro-

prietary competition, and under certain circumstances, they are a superior alternative to

their proprietary counterparts.

3 Background on the Specific OS and OSS Used to Create a Web-based SpatialInformation System

This section provides background information about the origin and relationships among

the OS and OSS we used. We also point to their relevance for the creation of web-based

geo-processing functionality.

The Extensible Markup Language (XML) is a subset of the Standard Generalized

Markup Language (SGML) [ISO 8879] (http://www.w3.org/TR/1998/). XML uses

pairs of text-based tags, enclosed in parentheses, to describe the data. These tags makethe information passed across the Internet self describing (Waters 1999). Part of its

success comes from: (1) the fact that it can be read and written by humans (in contrast
http://www.opengis.org/http://www.w3.org/http://www.w3.org/TR/http://www.opengis.org/roadmap/index.htmhttp://opensourcegis.org/http://www.w3.org/TR/1998/http://www.w3.org/TR/1998/http://opensourcegis.org/http://www.opengis.org/roadmap/index.htmhttp://www.w3.org/TR/http://www.w3.org/http://www.opengis.org/


5/20


451


with binary formats) and thus provides a single way of representing structure regardless

of whether the information is intended for human or machine consumption; and (2) its

similarity to the widely used Hyper Text Markup Language (HTML). XML satisfies

two compelling requirements, firstly it separates data from presentation, and secondly, it

transmits data between applications. XML is a metalanguage, i.e. a language thatdescribes other languages (Boumphrey et al

.

1998; http://www.xml.com). These languages

are called XML schemas (for a detailed definition of what constitutes a schema, and

how new schemas can be created see Ducket et al. 2001). There are schemas for over

40 different areas of expertise (http://www.xml.org/xml/registry.jsppresents a registry of

XML schemas). In the web-based geo-processing arena, XML is being used to exchange

metadata and control information between computers, and between them and humans.

According to Aloisio et al

.

(1999), XML will play a major role in enabling computers

to communicate universally with other computers, and to create a new generation of

web services designed to interact with other services. They also reaffirm that XML is

simple and powerful and its similarity to HTML ensures universal adoption.

Scalable Vector Graphics (SVG) and the Geography Markup Language (GML) are

XML schemas. The first is a vector graphics language written in XML to describe

two-dimensional graphics. The second is an XML encoding for the transport and stor-

age of geographic information, including both the spatial and non-spatial properties of

geographic features. SVG is a W3C open specification (http://www.w3.org/TR/SVG/).

GML is an OGC open specification (http://www.opengis.net/gml/ 02-069/GML2-12.html).

In SVG the graphical elements are represented within XML tags, hence SVG offers

all the advantages of XMLs openness, transportability, and interoperability (Eisenberg

2002). SVG drawings can be dynamic and support embedded interactivity, animation,

embedded fonts, XML code, Cascading Style Sheets and scripting languages. A rich set

of event handlers such as onmouseover and onclick can be assigned to any SVG graph-

ical object. For example, we used the onmouseover event to show real-world coordinates

as the user moves the mouse over the SVG map. SVG is capable of using real world

coordinate systems in contrast to other popular vector graphics formats such as Macro-

media Flash (Neumann 2002 compares the capabilities of SVG and Flash to handle

vector graphics in web applications). All these features make SVG appealing for the

graphical representation of geographic data on the web (Gould and Ribalaygua 1999).

Puhretmair and Woss (2001) used dynamically generated SVG maps as an intuitive

interface to present tourist information contained in distributed data sources. The informa-

tion is distributed among several servers and websites and is structured in different ways.

XML is used to create query tools and integrate the data by communicating with the

different services. Then the SVG capabilities to support embedded interactivity, anima-

tion, embedded fonts, XML, Cascading Style Sheets and scripting languages are used to

create on the fly maps as response to queries. The SVGOpen Conference is an excellent

source for the growing field of SVG applications (http://www.svgopen.org).

Lake (2001a) briefly presents the organization of the GML specification. In GML

the geometries and attributes of geographic layers are represented within XML tags,

again, this brings forth all the advantages of XMLs openness, transportability and

interoperability. GML is designed to support interoperability and does so through the

provision of basic geometry tags (all systems that support GML use the same geometry tags),

a common data model (features/properties), and a mechanism for creating and sharingapplication schemas (see the GML 2.1.2 specification at http://www.opengis.net/gml/

02-069/GML2-12.html). GML conforms to the OGCs Simple Features specificiations
http://www.xml.com/http://www.xml.org/xml/registry.jsphttp://www.w3.org/TR/SVG/http://www.opengis.net/http://www.svgopen.org/http://www.opengis.net/gml/http://www.opengis.net/gml/http://www.svgopen.org/http://www.opengis.net/http://www.w3.org/TR/SVG/http://www.xml.org/xml/registry.jsphttp://www.xml.com/


6/20

452



and it is not concerned with the visualization of geographic features such as the drawing

of maps. Hence, we used SVG for the graphical representation of the data in GML

format. GML is as critical to the evolution of the geospatial infrastructure on the web

as HTML was to the development of the conventional Internet (Lake 2001b). GML

supports geospatial interoperability in various ways (Lake 2001a), firstly it provides acommon schema framework for the expression of geospatial features; secondly it pro-

vides a common set of GML geometry types, this allows authors of different schemas

to share the same mechanisms for geometry description and hence be able to interpret

the correspondence between the schemas when they are referring to the same feature in

the real world; and third, the definition and publication of GML schemas that can be

shared across communities of interest such as transportation, environmental issues,

petroleum exploration, etc. facilitates interoperability on the semantic level.

XLST (Extensible Stylesheet Language: Transformations) is one of three parts that

compose a bigger language called XSL (Extensible Stylesheet Language). XLST is a W3C

open specification (http://www.w3.org/Style/XSL/). Essentially it is an XML based

language for transforming the structure of XML documents for display on screen, on

paper, or spoken word (Kay 2001). In addition, XLST is commonly used to transform

data from one data model (e.g. text) in one application to the data model used in

another (e.g. SQL statements to create a table in a Relational Database Management

System). The XLST formatting code contained in a text file is known as a Style Sheet.

XML documents are commonly processed through parsing. Geographic data in

GML format tend to be huge text files (Sahay 2002), therefore it is critical to use the

most efficient parsing method to process them. The SAX (Simple API for XML) parsing

method has been proven to be more efficient than its alternative DOM (Document Object

Model) method for processing GML documents (Sahay 2002). The use of SAX results

in reduced memory overhead compared to DOM, which requires the retention of the

complete document as a tree in memory. In our application, we used the SAX method

to extract the geometries from the geographic layers in GML format and convert them

to a format more amenable to spatial analysis such as Java2D objects.

The Java2D Application Programming Interface (API) is part of the Java Develop-

ment Kit (JDK). It is used for manipulation of two-dimensional objects. The Java2D

API includes the Constructive Area Geometry Methods for the Boolean overlay operations

intersection, union, subtraction and exclusive-OR (http://java.sun.com/products/java-

media/2D/). The JDK is free and includes a Java2D demonstration.

PHP (acronym derived from its origin as Personal Home Page Tools) is a server-side,

HTML-embedded, cross-platform scripting language (Rasmus 2000; http://www.php.net/ ).

It borrows concepts from other common languages such as C and Perl. PHP provides a

way to put instructions into HTML files to create dynamic content. The developer can

embed PHP structured code (e.g. loops, conditionals, rich data structures) inside HTML

tags. PHP is an OSS. We used it on the server side for process control, processing of the

users input, and to invoke and pass parameters to applications.

PostgreSQL is a sophisticated Object-Relational Database Management System

(RDBMS), supporting almost all SQL constructs, including subselects, transactions,

and user-defined types and functions. It is the most advanced OSS database available

today (Stinson 2001; Stones and Matthew 2001; http://www.postgreSQL.org/).

PostGIS,

which is also an OSS, is an extension of the PostgreSQL RDBMS that adds support forgeographic objects (http://postgis.refractions.net/ ). In effect, PostGIS spatially enables

the PostgreSQL server, allowing it to be used as a backend spatial database for Geographic
http://www.w3.org/Style/XSL/http://java.sun.com/products/javamedia/2D/http://java.sun.com/products/javamedia/2D/http://www.php.net/http://www.postgresql.org/http://postgis.refractions.net/http://postgis.refractions.net/http://www.postgresql.org/http://www.php.net/http://java.sun.com/products/javamedia/2D/http://www.w3.org/Style/XSL/


7/20


453


Information Systems (GIS), much like ESRIs Spatial Database Engine (SDE) or Oracles

Spatial extension. PostGIS follows the OGC Simple Features Specification for SQL

(http://www.opengis.org/techno/implementation.htm).

MapServer is an OSS development environment for building basic web-mapping

applications (http://mapserver.gis.umn.edu/). It facilitates the display and browsing ofgeographic data in commonly used vector and raster formats. It is not designed to be a

full-featured GIS system and hence it does not offer geo-processing functions.

Linux

is a free Unix-type operating system. Specifically, we used the Red Hat

Linux distribution (http://www.redhat.com). The Apache web server is a Hyper Text

Transfer Protocol (HTTP) compliant web server. It is an OSS maintained by the Apache

HTTP Server Project (http://www.apache.org). As of August 2002, 63% of the web sites

on the Internet are run on the Apache web server (Netcraft Web Server Survey; http://

www.netcraft.com/survey/).

4 The Case Study Creating a Prototype Web-based Spatial InformationSystem to Support Land Use Planning in Central Mexico

4.1 The need for the web-based system

During the decade of the 90s, the National Institute for Forest, Agriculture and Livestock

Research (INIFAP) in Mexico started to use GIS as part of its land suitability studies.

The largest of these studies was a strategic level national land use planning project to

identify the areas with potential to grow specific crops, forage and forestry species

considered of economic relevance for the country. A spatial database of national cover-

age was created to support this study. The database is organized in the following layers:

soils (digitized from 1:50,000 scale maps with information about primary and second-

ary soil type, and presence of chemical or physical phases), a digital elevation model at

30 meters resolution (elevation and slope are derived from it) and several climate layers

(30-year monthly and annual averages for minimum and maximum temperatures, pre-

cipitation and evaporation). These layers of information can be combined to derive

other parameters that help to estimate the suitability of an area for a specific crop, such

as the evaporation/precipitation coefficient. For each agricultural, forage and forestry

species considered of strategic importance for the country, INIFAPs researchers com-

piled a list of the values of the environmental factors (soil type; slope; precipitation;

maximum, minimum temperatures; etc.) that are considered ideal for the growth of the

particular species. Together with this information they compiled what is called a tech-

nological package which is a handbook of best practices for the production of the species

in question. State and federal government agencies, researchers, land owners, seed com-

panies, entrepreneurs, and agricultural insurance companies, among others, can request

the identification of the areas that fulfill the environmental factors for the production of

the species of their interest. These areas are identified by querying the spatial database

layers for the specific range of values considered ideal for the species in question. These

query results are overlaid using a Boolean intersect operation to find the areas where all

the desired environmental parameters are present.

After the completion of the first studies, INIFAP created specialized units to pro-

vide service to users of this information. This service is peripheral to INIFAPs researchresponsibilities. However, soon after starting this service the units were overwhelmed

by requests to identify areas that meet specific environmental requirements. INIFAP is
http://www.opengis.org/techno/implementation.htmhttp://mapserver.gis.umn.edu/http://www.redhat.com/http://www.apache.org/http://www.apache.org/http://www.redhat.com/http://mapserver.gis.umn.edu/http://www.opengis.org/techno/implementation.htm


8/20

454



in need of an alternative way to fulfill these demands in a more timely, efficient and

economical way.

In the past INIFAP had considered using the web as a platform to serve their geographic

data or selected pieces of it, and to perform the previously described geo-processing

analyses. However, several factors had deterred them from further pursuing this option:(1) the required Boolean overlay geo-processing capabilities currently do not exist out

of the box in commercial web-GIS systems; (2) the high costs of web-GIS software; (3) the

special requirements of this software in terms of dedicated personnel and lengthy train-

ing; and (4) concerns about the compatibility of the web-GIS software with existing

IT infrastructure (personnel skills, software and applications). We decided to test the

viability of using OS and OSS technologies to create a web-based spatial information

system for non-expert users that will overcome these issues. The aim of the system is to

allow end users to perform queries for desired values of environmental factors and do

Boolean overlays of the results of these queries to identify the areas where all the desired

environmental factors are present. By changing the values in their queries end users can

have a quick idea of the effects of these changes on the areas selected and their intersection.

4.2 Creating the prototype system

The state of Guanajuato in central Mexico was selected as a pilot area to create a proto-

type system. INIFAP stated the following preferences regarding the design and development

strategy for the system. It would: (1) easily integrate with the remainder of its existing

IT infrastructure (personnel skills, software and applications); (2) be scalable, with initial

low costs and low total costs of ownership of the system over the long run; (3) minimize

special requirements; (4) not imply steep learning curves; and (5) eventually improve the

efficiency in the expansion, maintenance and quality control of the national database by

centralizing these functions in one place.

Next we present the step-by-step process to create a prototype web-based spatial

information system around OS and OSS that is capable of processing attribute queries

and Boolean intersection overlays. The prototype system is based on a PC computer with

average technical specifications and a fast (T1) Internet connection. It runs the Linux

(specifically Red Hat Linux) operating system and the Apache web server. For illustra-

tion purposes in this article, we have taken a subset of the data and translated the

interface prompts. This demo system and all the referenced source code and relevant

web links can be found at http://206.168.217.254/guanajuato/.The demo on this website

has detailed instructions of how to perform queries, intersect overlays and display the

results. The prototype system continues to evolve. Some improvements to the first

version will be described in the discussion section. The interface of the prototype version

that is presented in this website still contains interaction steps that eventually will be

hidden from the end users. However, at this point the exposure of these steps serve to

closely illustrate each of the processes that occur in the system when processing a query

and overlay request.

On the interface, the user is presented with a screen divided into two areas, on the

left, an area to input queries and present instructions to the users, and a map display area

on the right (see Figure 4). To input queries the user uses drop-down boxes to choose

values (or a range of values) for each of the environmental factors (e.g. soils, elevation,temperature) contained in the spatial database. After selecting the desired values for

each parameter, the user hits the submit query button. The map display window is built
http://206.168.217.254/guanajuato/http://206.168.217.254/guanajuato/


9/20


455


using MapServer (http://mapserver.gis.umn.edu/). In it the user selects which layers

he or she wants to display, including the features in each layer that were selected in the

query. The map must be refreshed every time the type or number of layers displayed is

changed. Visually it can be determined if there is an area where all the selected features

intersect. If this is the case, the next step is to write GML documents that represent theselected features for each layer. Finally, the intersection of these selected areas is calcu-

lated and the resulting area is output as an SVG file and as a GML file. The SVG file can

be displayed by itself or with other layers using the SVGeoprocessor application. The

SVGeoprocessor application takes the image generated by MapServer as background

and then overlays the intersection area in SVG format. The SVG interactivity capabilities

are used to respond to users actions as described in STEP 7. All of the following described

processing takes place on the server side of the system. The client side is only used to

present the user with input forms and graphical output resulting from his requests.

Figure 1 presents a flow diagram of the steps required to respond to a users request

for queries on the thematic layers and overlay intersect geo-processing. In the description

of the steps that follow we will explain this diagram in detail.

STEP 1:

In this step, (see Figure 1) the layers for the pilot area that were originally

in ESRIs (Environmental Research Systems Institute, Redlands, California) shapefile format

are converted to tables in the PostgreSQL RDBMS. This conversion is achieved using the

shp2pgsql utility included as part of the PostGIS extension. This utility takes a shapefile

and outputs a series of SQL statements (e.g. CREATE TABLE and INSERT) to create a

table in the PostgreSQL RDBMS (Figure 2). The resulting table contains all the attributes

of the shapefile including the coordinates that define each feature These SQL statements

are then executed in PostgreSQL to create a table that represents the shapefile (Figure 3).

The shp2pgsql utility allows for the selection of a projection for the data in the resulting

table. PostGIS contains a file with close to 1800 projection definitions to choose from.

This process was repeated for each of the layers provided (soils, elevation, and the

climate layers).

STEP 2:

In the query building interface (an HTML form; see Figure 4) the user queries

the database for the parameters of interest for each layer. When the system finishes

processing the intersect query, the area where all the requested environmental parameters

intersect is displayed on a SVG map. If the requested environmental parameters do not

intersect a message is sent to the user. The user also has the option to invoke the overlay

processor interface (Figure 5). This HTML form informs the user first about the number

of features in each layer that meet the requested parameters, and second the number of

selected features whose bounding boxes intersect the bounding boxes of the selected

features in a second layer. By analyzing these numbers, the user should be able to: (1) see

how many features satisfy the specified parameters for each layer, (2) identify which is the

most limiting environmental factor in his or her query based on the number of selected

features, and (3) identify which layers do not intersect. With this information the user can

perform sensitivity analyses by changing the requested parameters for one or more layers.

STEPS 3 and 4:

The parameters entered by the user are sent to the server using

the HTML form. In the server a PHP script converts the users input for each layer into a

SQL statement (e.g. SELECT all FROM elevation WHERE elevation

1500 AND ele-

vation

3000) that is fed to the PostgreSQL-PostGIS RDMS. PostgreSQL-PostGIS is

invoked from the PHP script to execute the SQL statement which returns a string ofcoordinates describing the features selected in the layer (together with any of its attributes

requested). This string is parsed in another PHP script to create a GML polygon and/or
http://mapserver.gis.umn.edu/http://mapserver.gis.umn.edu/


10/20

456



multipolygon entity in a GML document that now will represent the selected features and

attribute (Figure 6).

STEP 5:

The resulting GML documents corresponding to the features selected in each

layer (e.g. SoilsSelected.xml, ElevationSelected.xml, etc.), are input into a Java programthat computes the intersection of the features (one pair at the time). This program defines

a Java class (GMLoverlay.class) that uses the SAX parsing method to search each GML

Figure 1 Flow diagram of the processes taking place in the prototype web-based spatial

information system


11/20


457


document for the geometries and writes each polygon to an array of Java2D area objects.

These objects are then intersected using the area intersect function contained in theJava2D API (Figure 7). The intersection result is then output as a GML document

(intersection.xml).

Figure 2 SQL statements that are output from the shp2pgsql utility in PostGIS extension toconvert Shapefiles to tables in the PostgreSQL RDBMS

Figure 3 This SQL command SELECT displays all the records (that represent features) in

the table simpleshape (that represents a layer). For illustration purposes we are showing a

layer with a single feature


12/20

458



STEP 6:

A XSLT Style Sheet (svg.xsl; see Figure 8) was created to transform the GML

code contained in the intersection.xml file to SVG graphics for display as a map. Again,

Style Sheets are custom-made XML instructions for formatting XML files. By creating

other XSLT Style Sheets, the GML output (intersection.xml) can be potentially formatted

into any text-based format, for example, any of the existing XML schemas for over forty

different areas of expertise, HTML, delimited text, or UNGENERATE Arc/Info format.

STEP 7:

For convenience and due to the short development cycle for the prototype,

we used MapServer to provide the map layout interface (frames, legend, scale bar and

zoom levels) and for rendering the individual layers contained in the spatial database.

The graphics generated by MapServer are then used as background for the display of

the SVG map representing the intersection result. We used the SVG interactivity capab-

ilities as follows: (1) the onmouseover event is handled to report the real-world coordin-

ates of the mouse position on the SVG map, and (2) the onclick event is handled to

send a query to the PostgreSQL-PostGIS database that returns the values for each of

the layers at the point where the mouse is clicked (the equivalent of spearing through

the layers and pulling out the values for each layer). Plate 1 shows the SVG map that the

user gets as response to his query and geo-processing request.

5 Discussion

We demonstrated how spatial information in a proprietary GIS format can be converted

to tables and managed in a RDBMS environment. This simple transformation makes the

information contained in GIS layers easier to combine and process with information

contained in other DBMS applications (such as accounting and inventory systems) that

might be part of the organizations IT infrastructure. In the case of INIFAP, after this

transformation, geographic information (such as the extent of a feature of interest, ordistance between two features) can be combined and analyzed in a RDBMS environ-

ment (without having to link to external GIS systems) with information about crops

Figure 4 Sample HTML form


13/20


459


yields, rural census data, or results of fertilization experiments contained in other

RDBMS applications. Of course the existing RDBMS do not (and probably never will)

have all the spatial analytical capabilities of a GIS system. However, they are constantly

evolving and in the near future they will have enough capabilities to satisfy many simple

geo-processing requirements. For example, currently PostgreSQL-PostGIS is capable of

performing over sixty spatially related operations such as finding the extent of a feature

or group of features, distance in projected units between two features, selection of

features to the left or right of a feature, and intersection of two feature extents. There

are plans in the near future to add topological operators to the PostGIS module includ-

ing: touches, contains, overlaps, buffer, union and difference. Hence in the future theBoolean intersect overlay operation we implemented in the prototype system could be

performed directly in the PostgreSQL-PostGIS RDBMS using database records.

Figure 5 The overlay processor interface


14/20

460



We also chose to transform the geographic layers from ESRIs shapefile format to

tables in a RDBMS system in STEP 1 where SQL queries were executed to extract desired

features and attributes from each layer. Then using a PHP script, the strings of text

returned by these queries were converted to GML documents that represent the selected

spatial features and their attributes. Once the GIS layers are in GML format, they can be

passed to any system, application or geo-processing service that is able to read this Open

Specification. This is how the use of this OS enables a certain degree of interoperability

between applications. These applications or services can reside on a single machine, on

a local-area network, or on any server connected to the Internet. A packet of information(e.g. a layer or pieces of it in GML format) can be passed from application to applica-

tion (and these could be of very different nature) adding or extracting information to or

Figure 6 Example of GML code representing a single feature (see Figure 9) selected from

one of the layers in the spatial database


15/20


461


from the original packet until the desired end result is obtained. This is how interoper-

ability facilitates distributed processing. In other words, compliance with Open Specifica-

tions enables interoperability between heterogeneous environments and systems, facilitates

distributed processing and opens new possibilities for the combination and processing of

geographic data.

We also used a PHP script to convert the string returned as a result of the query forthe desired features (records) in the PostgreSQL-PostGIS RDBMS to a GML document

in STEP 4. This process worked well for small data sets; however, when we started to

Figure 7 This piece of Java code links to the Java2D API and invokes the Constructive Area

Geometry Methods contained in this API to generate the intersection, subtraction, addition,

and exclusiveOr of two Java2D area objects. We currently using only the CASE 3 for the

intersect method


16/20

462



process larger areas the processing time was unacceptable (several minutes). To minimize

the number of selected features that have to be converted to GML we used the bounding

box intersect function within PostgreSQL-PostGIS. This function returns the records

(features) from one table (layer) whose bounding boxes intersect the bounding boxes of

features in a second layer. In this way only the records that fulfill the query and whose

bounding boxes intersect with bounding boxes of features from a second layer are

returned for conversion to GML documents. This preprocessing greatly reduces the

number of records that must be converted to GML for performing the actual intersection

of features in the GMLoverlay.class program, and allowed us to process larger geo-

graphic areas. In the latest version of the prototype system we were able to significantly

improve the response times by: (1) replacing the use of PHP scripts to control the

processes flow by PERL CGI scripts; and (2) consolidating the conversion to SVG

and GML formats of the overlay result (intersect.xml) into the GMLoverlay.class Java

class. The full code for this implementation can be found at the demonstration website

(http://206.168.217.254/guanajuato/).

We then created a Java class (GMLoverlay.class) that implements the intersect func-

tion that is part of the Constructive Area Geometry Methods included in the Java2D

API in STEP 5. In the same way we could have as easily implemented any of the other

operators that are included in the Java2D API (union, subtraction, and exclusive-OR)

to provide these geo-processing capabilities in the system. As a matter of fact the Java code

in Figure 7 is invoking these methods from the Java2D API, we are just not currently

using them.In STEP 6 we demonstrated the use of XSLT Style Sheets to convert a layer in GML

format (intersection.xml) to SVG (for graphical display). If geographic data in GML

Figure 8 XSLT Style Sheet to transform the GML document (intersection.xml), which repres-

ents the area where the selected environmental parameters intersect to SVG for display on

the end users browser
http://206.168.217.254/guanajuato/http://206.168.217.254/guanajuato/


17/20


463


format gains popularity, Style Sheets could be developed to transform GML documents

to a wide array of formats (e.g. any text format, any XML schema, or GIS proprietary

formats) used by other systems and applications. In addition, through the use of XSL-

Formatting Objects (XSL-FO) these data could be converted to different printing formats

for high quality output. Eventually, libraries of Style Sheets could be posted on websites,downloaded to reside locally, or invoked directly from remote servers to perform a

transformation. This possibility would greatly increase the speed and ease with which

geographic data is made available to a broader array of IT applications.

6 Conclusions

State-of-the-art web-based geo-processing solutions can be implemented using currently

available OSS and OS. The required technology for solving spatial problems in an Internet

based computing environment is available from at least one mature OS project. We used

the OSS we consider to be the most powerful, widespread, accessible, easy to learn, and

with a good level of user support in the form of software documentation, books and

user-groups forums. Typical OSS installation involves downloading the source code for

the target Operating System (e.g. Linux, Windows XP, NT or 2000), identifying and

downloading other required software components, configuring the desired features and

compiling the application. This process is straightforward and routine for most person-

nel with general IT backgrounds, but it could be intimidating for casual users with little

programming experience. However, most mature OSS are well supported with thorough

installation instructions and any motivated GIS user should be able to install and start

using the OSS presented in this article.

Given that the purpose of the project here described was exploratory, we ended up

using a wider array of OS and OSS than would probably have been optimally required

to create the functionality present in the prototype system. For the same reason, we took

more than the strictly necessary steps to produce the desired results. For the develop-

ment of the prototype system we ended up using more than 10 Open Source technolo-

gies. Even by using the minimum required number of OSS and OS, one of the issues

faced when implementing advanced OSS web-based GIS solutions is the breadth of

technical skills required and the logistics of orchestrating the interaction of many

applications. Designing web-based GIS solutions requires a thorough understanding of

core WWW technologies (such as the configuration and management of web servers),

spatial information management expertise, and the ability to choreograph the geo-

processing steps required to solve spatial problems in a distributed environment. It is

not difficult to find these necessary skills in an IT department or in a highly motivated

power user.

In developing the prototype system, we learned: (1) the potential of SVG to develop

highly interactive mapping applications on the web; (2) PostgreSQL-PostGIS is a robust

database management system that offers a considerable, and continuously increasing,

number of geo-processing functions; (3) Java2D can be effectively used for basic 2D vector

overlay (a specifically geo-spatially oriented Java API such as the OS Java Topology

Suite (http://www.vividsolutions.com/jts/jtshome.htm) is clearly preferable for more

advanced geo-processing, but Java2D is a good starting point for performing vector analysiswith Java); and (4) MapServer proved to be an easy to use and production quality Internet

map server.
http://www.vividsolutions.com/jts/jtshome.htmhttp://www.vividsolutions.com/jts/jtshome.htm


18/20

464



From this experience, we can conclude that for organizations with scarce resources

wanting to implement the distribution of their geographic data and geo-processing ser-

vices over the WWW, the use of the OS and OSS we used offer the following advantages:

(1) no software costs; (2) software tools that were easily learned by personnel with

general IT background (UNIX, programming, databases design and management);

(3) small software footprints; (4) no need to commit to a proprietary web-GIS, DBMS

or web software with their associated costs; (5) ease of compatibility with existing IT

infrastructure (personnel with basic databases and programming skills, existing DBMS

software and DBMS applications); (6) flexibility to implement geo-processing capabil-

ities currently non-existent in commercial web-GIS software (e.g. Boolean intersect

overlays); (7) the principles to implement these technologies are straightforward and

accessible to a broad audience of geographic information scientists and developers;

and (8) the system developed has the potential to interoperate with other systems and

applications that use the same OS.

Our experience also showed that the resulting text files tend to be large when

geographic data are converted to GML format, as illustrated by the GML code (Figure 6)

that is required to represent a single small and geometrically simple polygon (Figure 9).

The size of the GML files depends on the number of features and the number of points

per feature contained in a layer (Sahay 1999 provides a formula for calculating the

storage size of a GML document based on these two parameters). As an example, a layer

in ESRIs shapefile format of size 342,708 bytes would occupy 599,473 bytes in its

corresponding GML representation. In addition, because GML up to version 2.1.2 does

not support topology, common boundaries between features must be stored twice (once

for each feature). The size of the GML files could affect secondary storage (e.g. hard

drive or tape) requirements, as well as, the time required to parse the file to extract

desired information. A large implementation would greatly benefit from file compres-sion algorithms and highly efficient parsing methods. More research is required on both

of these areas.

Figure 9 SVG graphic of a simple feature. Figure 6 shows the GML code from which this

image is generated


19/20


465


Next, we will test the scalability capacity of these technologies to create the full

implementation for INIFAPs web-based spatial information needs. In addition, we are

planning to make a full evaluation of the reliability, performance, security, and total

costs of ownership for the system. We also need to make the overlay processor interface

more user friendly and improve its capacity to explain the intersection results obtained.Finally, so far we have dealt only with geographic data in vector format, and we are

currently working on developing web-based geo-processing capabilities for raster data.

Acknowledgements

The authors would like to thank the National Institute for Forest, Agriculture and

Livestock Research (INIFAP) Central Region and especially Dr. Hilario Garcia-Nieto

for their support and cooperation in the development of this project. We would also like

to thank the anonymous reviewers for their helpful comments and suggestions for

improvement of an earlier draft of this manuscript.

References

Aloisio G, Milillo G, and Williams R D 1999 An XML architecture for high-performance web-basedanalysis of remote-sensing archives. Future Generation Computer Systems

16: 91100Boumphrey F, Direnzo O, Duckett J, Graf J, Houle P, Hollander D, Jenkins T, Jones P, Kingsley-

Hughes A, Kingsley-Hughes K, McQueen C, and Mohr S 1998 XML Applications.

Birmingham,Wrox Press

Dangermond J 2002 Web services and GIS. Geospatial Solutions

12(7): 56Ducket J, Griffin O, Mohr S, Norton F, Stokes-Rees I, Williams K, Kurt Cagle, Nikola O, and

Tennison J 2001 Professional XML Schemas

. Birmingham, Wrox PressEisenberg J D 2002 SVG Essentials

. Sebastopol, CA, OReilly & AssociatesGardels K 1997 Open GIS and on-line environmental libraries. SIGMOD Record

26: 328Gould M and Ribalaygua A 1999 A new breed of web-enabled graphics. GeoWorld 12(3):

469Harvey F 1999 Designing for interoperability: Overcoming semantic differences. In Goodchild M F,

Egenhofer M, Fegeas R and Kottman C (eds) Interoperating Geographic Information Systems

.Boston, MA, Kluwer: 8597

Hecht L 2002a Get your free interoperability roadmap. GeoWorld

15(2): 223Hecht L 2002b Insist on interoperability. GeoWorld

15(4): 223

Hecht L 2002c Web services are the future of geo-processing. GeoWorld

15(6): 234Herring J 1999 The OpenGIS data model. Photogrammetric Engineering and Remote Sensing 65:

5858Holland D 2001 Delivering the digital national framework in GML. GeoEurope 10(8): 29 30Kay M 2001 XLST Programmers Reference

(Second edition). Birmingham, Wrox PressKottman C 1999 The Open GIS Consortium and progress toward interoperability in GIS. In

Goodchild M F, Egenhofer M, Fegeas R and Kottman C (eds) Interoperating GeographicInformation Systems

. Boston, MA, Kluwer: 3954Lake R 2001a GML 2.0 enabling the geospatial web. Geospatial Solutions

11(7): 38 41Lake R 2001b GML lays the foundation for the geospatial web. GeoWorld

14(10): 425Lowe J 2002 Spatial on a shoestring: Leveraging free Open Source Software. Geospatial Solutions

12(6): 425

McKee L 1998 What does OpenGIS Specification conformance mean? GeoWorld

11(8): 38Neumann A 2002 Comparing .SWF (Shockwave Flash) and .svg (Scalable Vector Graphics) fileformat specifications. In Proceedings of the

SVG Open Developers Conference

, 1517 July 2002,Zurich Switzerland (available at http://www.carto.net/papers/svg/comparison_flash_svg.html)
http://www.carto.net/papers/svg/comparison_%EF%AC%82ash_http://www.carto.net/papers/svg/comparison_%EF%AC%82ash_


20/20

466


Bl k ll P bli hi Ltd 2003

Puhretmair F and Woss W 2001 XML-Based integration of GIS and heterogeneous tourism informa-tion. In Name (ed) Title. Berlin, Springer-Verlag Lectures Notes in Computer Science No2068: 346 58

Ramsey P 2002 Open source GIS fights the three-horned monster. GeoWorld

15(8): 23 5Rasmus L 2000 PHP Pocket Reference.

Sebastopol, CA, OReilly & Associates

SahayN 2002 GMLView: A GML Map Renderer. Unpublished M.S. Technical Paper, Departmentof Computer Engineering, University of Minnesota (available at http://www-users.cs.umn.edu/~sahay/8701/planb_1_10.htm)

Seth A P 1999 Changing focus on interoperability in information systems: From system, syntax,structure to semantics. In Goodchild M F, Egenhofer M, Fegeas R and Kottman C (eds)Interoperating Geographic Information Systems. Boston, MA, Kluwer: 530

Stinson B 2001 PostgreSQL Essential Reference. Indianapolis, IN, New RidersStones R and Matthew N 2001 Beginning Databases with PostgreSQL.Chicago, IL, Wrox PressVckovski A 1998 Interoperable and Distributed Processing in GIS. Bristol, PA, Taylor and FrancisWheeler D A 2002 Why Open Source Software/Free Software (OSS/FS)? Look at the Numbers!

WWW document, http://www.dwheeler.com/oss_fs_why.html Waters N 1999 Is XML the answer to internet-based GIS? GeoWorld 12(7): 32 3
http://www-users.cs.umn/http://www.dwheeler.com/oss_fs_why.htmlhttp://www.dwheeler.com/oss_fs_why.htmlhttp://www-users.cs.umn/

Transactions In Gis

Documents

Transcript of Transactions In Gis