Transactions in GIS

2003 7(4) 447ndash466

copy 2003 Blackwell Publishing Ltd 9600 Garsington Road Oxford OX4 2DQ UK and 350 Main Street Malden MA 02148 USA

Research Article

Building Web-Based Spatial Information Solutions around Open Specifications and Open Source Software

Geoffrey Anderson

Cloudshadow Consulting Inc Boulder Colorado

Rafael Moreno-Sanchez

Department of Geography University of Colorado at Denver

Abstract

Geographic Information Systems (GIS) are moving from isolated standalonemonolithic proprietary systems working in a client-server architecture to smallerweb-based applications and components offering specific geo-processing functionalityand transparently exchanging data among them Interoperability is at the core ofthis new web services model Compliance with Open Specifications (OS) enables inter-operability Web-GIS softwarersquos high costs complexity and special requirementshave prevented many organizations from deploying their data and geo-processingcapabilities over the World Wide Web There are no-cost Open Source Software (OSS)alternatives to proprietary software for operating systems web servers and RelationalDatabase Management Systems We tested the potential of the combined use of OSand OSS to create web-based spatial information solutions We present in detail thesteps taken in creating a prototype system to support land use planning in Mexico withweb-based geo-processing capabilities currently not present in commercial web-GISproducts We show that the process is straightforward and accessible to a broad audienceof geographic information scientists and developers We conclude that OS and OSSallow the development of web-based spatial information solutions that are low-costsimple to implement compatible with existing information technology infrastructureand have the potential of interoperating with other systems and applications in the future

1 Introduction

With a few exceptions (eg the Geographic Resources Analysis Support System GRASShttpwwwcecerarmymilgrassGRASSmainhtml) geographic information technology

Address for correspondence

Rafael Moreno-Sanchez Department of Geography University ofColorado at Denver Campus Box 172 PO Box 173364 Denver CO 80217-3364 USA E-mailrmorenocarboncudenveredu

448

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

has developed as isolated standalone monolithic proprietary systems This is rapidlychanging as geo-processing principles and functionality are moving out of a tightlydefined niche into the information technology (IT) mainstream Isolated standalonesystems are being replaced by integrated components and large applications are beingreplaced by smaller more versatile applications that work together transparently acrossnetworks Of these the World Wide Web (WWW or the web) is becoming the coremedium for distributed computing in IT generally and in the geo-processing domainspecifically (Hecht 2002b) In other words Geographic Information Systems (GIS) oncefocused on data and tools implemented with client-server architecture now are evolvingto a web services model (Dangermond 2002) In this new architecture the web is used fordelivering not just data but geo-processing functionality that can be wrapped in inter-operable software components called web services These components can be pluggedtogether to build larger more comprehensive services andor applications (Hecht 2002c)Interoperability between heterogeneous environments systems and data is fundamentalfor the implementation of this web services model

With respect to their IT infrastructure organizations aim to (1) maximize productivityand efficiency (2) protect critical information infrastructure and (3) overcome prob-lems related to data sharing security and data maintenance as well as software specialrequirements and steep learning curves The WWW offers the potential benefits offlexibility ubiquity and reduced costs and risks of obsolescence and isolation Howeverwhen organizations try to use the web as a platform to deliver geographic data and providegeo-processing functionality to their end users they commonly find that commercialweb-GIS software raises the following issues (1) it does not currently offer out of thebox geo-processing functionality to perform many of the analyses demanded by theirend users (2) it is expensive (3) it has a steep learning curve (4) it requires that someof their IT personnel become specialists in the software operation and maintenance and(5) it is difficult to integrate with existing IT infrastructure (personnel skills softwareand applications)

The use of OS and Open Source Software (OSS) offer the potential to overcome theabovementioned issues and facilitate the deployment of geographic data and geo-processingfunctionality on the WWW There is a growing interest in the use of OS For examplethe British Ordnance Survey is using the Geographic Markup Language (GML) OS todeliver the Digital National Framework on the web and to mobile devices (Holland 2001httpwwwordinancesurveycoukdnfhomehtm) According to Lowe (2002) there isa growing market for OSS products fed by small organizations and regional governmentagencies that cannot afford proprietary softwarersquos (web-GIS DBMS and web servers)costs complexity steep learning curves training costs and special requirements Thereare already several successful examples of the use of OSS to create basic web-mappingfunctionality (see cases described by Lowe 2002 and Ramsey 2002)

In spite of this growing interest little has been published about the combined useof OS and OSS for the creation of web-based geo-processing applications Even less isfound in the form of detailed explanations of how they can interact and complementeach other to create these applications This article aims to contribute to the knowledgebase 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 createda 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 commercialweb-GIS software The article is organized as follows section 2 defines OS OSS and

Web-Based Spatial Information Solutions

449

copy Blackwell Publishing Ltd 2003

interoperability and provides the necessary background regarding the organizations andefforts to create OS section 3 defines and provides a brief background of the specific OSand OSS technologies used to create the web-based spatial information system describedin this paper section 4 presents a brief background about the need for the system anda 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 discussionof the implications and difficulties in applying these technologies and finally section 6presents conclusions and suggestions for future research and implementations

2 Defining Open Specifications (OS) Interoperability and Open Source Software (OSS)

Open Specifications provide software engineers and developers information about a givenspecification as well as specific programming rules and advice for implementing theinterfaces andor protocols that enable interoperability between systems The OpenGISConsortium Inc (OGC) (httpwwwopengisorg) defines interoperability as ldquothe abilityfor a system or components of a system to provide information portability and inter-application cooperative process control In the context of the OGC specifications thismeans software components operating reciprocally (working with each other) to overcometedious batch conversion tasks importexport obstacles and distributed resource accessbarriers imposed by heterogeneous processing environments and heterogeneous datardquo

Herring (1999) and Kottman (1999) present an in-depth discussion of the OpenGISData Model and the OGC process for the creation of OS respectively Software productscan be submitted for testing their interfaces for compliance with OGC OpenGIS Imple-mentation Specifications (see httpwwwopengisorgtechnoimplementationhtm forthe most recent approved and in process specifications) Initially the only OpenGISSpecifications that products could conform to were the OpenGIS Simple FeaturesSpecifications for CORBA OLECOM and SQL (McKee 1998) but there are now 11different specifications Within computer environments there are many different aspectsof interoperability (Vckovski 1998) (1) independent applications running on the samemachine and operating system ie interoperability through a common hardwareinterface (2) application A reading data written by another application B ie inter-operability through a common data format and (3) application A communicating withapplication B by means of interprocess communication or network infrastructureie interoperability through a common communication protocol Besides technical issuesthere are also interoperability topics at higher levels of abstraction such as semanticbarriers (Harvey 1999 Seth 1999) A system based on the OS described in a later sectionof 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 withoutrequiring that both have the same geo-processing or viewer software (2) no singleGeographic Information System (GIS) mapping tool imaging solution or database answersevery 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 (eg GPS integrated into mobile devices) are increasing the number of database

450

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

records with location information (4) the number of software companies offeringcomponents to deal with geographic information is growing (5) it is more efficient tocollect data once and maintain them in one place (this is particularly cost effective ifcommunities of users can find access and use the information online so they do notneed 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 datafrom multiple sources opens new possibilities for improved decision making and makesdata more valuable and (7) the ability for multiple users including non-GIS experts touse a particular set of data (perhaps at different levels with different permissions) alsomakes the data more valuable Gardels (1997) discusses how compliance with OGCrsquosOpenGIS specifications and the resulting interoperability can contribute to integratingdistributed heterogeneous environments into on-line environmental information systems(EIS) He points to three technical strategies (federation catalogs and data mining) forthe integration of these systems and how they are heavily dependent on interoperabilityamong diverse data sources formats and models He concludes that properly designedgeodata access and analysis tools combined with open environmental information systemscan 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) (httpwwwopengisorg)and the World Wide Web Consortium (W3C) (httpwwww3org) The W3C has createdmore than forty technical specifications (httpwwww3orgTR) and as of January2002 the OGC has adopted nine OpenGIS Implementation Specifications and 11 candidatespecifications are in the works (Hecht 2002a a roadmap to the specifications work ispresented at httpwwwopengisorgroadmapindexhtm)

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 redistributeeither the original or modified program without further limitations or royalty payments(httpwwwopensourceorgdocsdefinitionphp) Among the most well known OSSprojects are the Linux operating system and Apache web server Sometimes the termOpen Technologies is used to refer to these projects and others such as XML HTMLTCPIP and Java technology A comprehensive list of GIS-related OSS can be found athttpopensourcegisorg According to Wheeler (2002) OSS reliability performancescalability 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 totheir proprietary counterparts

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

This section provides background information about the origin and relationships amongthe OS and OSS we used We also point to their relevance for the creation of web-basedgeo-processing functionality

The Extensible Markup Language (XML) is a subset of the Standard GeneralizedMarkup Language (SGML) [ISO 8879] (httpwwww3orgTR1998) XML usespairs of text-based tags enclosed in parentheses to describe the data These tags makethe information passed across the Internet ldquoself describingrdquo (Waters 1999) Part of itssuccess comes from (1) the fact that it can be read and written by humans (in contrast

Web-Based Spatial Information Solutions

451

copy Blackwell Publishing Ltd 2003

with binary formats) and thus provides a single way of representing structure regardlessof whether the information is intended for human or machine consumption and (2) itssimilarity to the widely used Hyper Text Markup Language (HTML) XML satisfiestwo compelling requirements firstly it separates data from presentation and secondly ittransmits data between applications XML is a metalanguage ie a language thatdescribes other languages (Boumphrey et al

1998 httpwwwxmlcom) These languagesare called XML schemas (for a detailed definition of what constitutes a schema andhow new schemas can be created see Ducket et al 2001) There are schemas for over40 different areas of expertise (httpwwwxmlorgxmlregistryjsp presents a registry ofXML schemas) In the web-based geo-processing arena XML is being used to exchangemetadata and control information between computers and between them and humansAccording to Aloisio et al

(1999) XML will play a major role in enabling computersto communicate universally with other computers and to create a new generation ofweb services designed to interact with other services They also reaffirm that XML issimple and powerful and its similarity to HTML ensures universal adoption

Scalable Vector Graphics (SVG) and the Geography Markup Language (GML) areXML schemas The first is a vector graphics language written in XML to describetwo-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 ofgeographic features SVG is a W3C open specification (httpwwww3orgTRSVG)GML is an OGC open specification (httpwwwopengisnetgml02-069GML2-12html)

In SVG the graphical elements are represented within XML tags hence SVG offersall the advantages of XMLrsquos openness transportability and interoperability (Eisenberg2002) SVG drawings can be dynamic and support embedded interactivity animationembedded fonts XML code Cascading Style Sheets and scripting languages A rich setof 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 coordinatesas the user moves the mouse over the SVG map SVG is capable of using real worldcoordinate systems in contrast to other popular vector graphics formats such as Macro-media Flash (Neumann 2002 compares the capabilities of SVG and Flash to handlevector graphics in web applications) All these features make SVG appealing for thegraphical representation of geographic data on the web (Gould and Ribalaygua 1999)Puhretmair and Woss (2001) used dynamically generated SVG maps as an intuitiveinterface to present tourist information contained in distributed data sources The informa-tion is distributed among several servers and websites and is structured in different waysXML is used to create query tools and integrate the data by communicating with thedifferent services Then the SVG capabilities to support embedded interactivity anima-tion embedded fonts XML Cascading Style Sheets and scripting languages are used tocreate on the fly maps as response to queries The SVGOpen Conference is an excellentsource for the growing field of SVG applications (httpwwwsvgopenorg)

Lake (2001a) briefly presents the organization of the GML specification In GMLthe geometries and attributes of geographic layers are represented within XML tagsagain this brings forth all the advantages of XMLrsquos openness transportability andinteroperability GML is designed to support interoperability and does so through theprovision of basic geometry tags (all systems that support GML use the same geometry tags)a common data model (featuresproperties) and a mechanism for creating and sharingapplication schemas (see the GML 212 specification at httpwwwopengisnetgml02-069GML2-12html) GML conforms to the OGCrsquos ldquoSimple Featuresrdquo specificiations

452

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

and it is not concerned with the visualization of geographic features such as the drawingof maps Hence we used SVG for the graphical representation of the data in GMLformat GML is as critical to the evolution of the geospatial infrastructure on the webas HTML was to the development of the conventional Internet (Lake 2001b) GMLsupports 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 schemasto share the same mechanisms for geometry description and hence be able to interpretthe correspondence between the schemas when they are referring to the same feature inthe real world and third the definition and publication of GML schemas that can beshared across communities of interest such as transportation environmental issuespetroleum exploration etc facilitates interoperability on the semantic level

XLST (Extensible Stylesheet Language Transformations) is one of three parts thatcompose a bigger language called XSL (Extensible Stylesheet Language) XLST is a W3Copen specification (httpwwww3orgStyleXSL) Essentially it is an XML basedlanguage for transforming the structure of XML documents for display on screen onpaper or spoken word (Kay 2001) In addition XLST is commonly used to transformdata from one data model (eg text) in one application to the data model used inanother (eg SQL statements to create a table in a Relational Database ManagementSystem) The XLST formatting code contained in a text file is known as a Style Sheet

XML documents are commonly processed through parsing Geographic data inGML format tend to be huge text files (Sahay 2002) therefore it is critical to use themost efficient parsing method to process them The SAX (Simple API for XML) parsingmethod has been proven to be more efficient than its alternative DOM (Document ObjectModel) method for processing GML documents (Sahay 2002) The use of SAX resultsin reduced memory overhead compared to DOM which requires the retention of thecomplete document as a tree in memory In our application we used the SAX methodto extract the geometries from the geographic layers in GML format and convert themto 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 Java2DAPI includes the Constructive Area Geometry Methods for the Boolean overlay operationsintersection union subtraction and exclusive-OR (httpjavasuncomproductsjava-media2D) The JDK is free and includes a Java2D demonstration

PHP (acronym derived from its origin as Personal Home Page Tools) is a server-sideHTML-embedded cross-platform scripting language (Rasmus 2000 httpwwwphpnet)It borrows concepts from other common languages such as C and Perl PHP provides away to put instructions into HTML files to create dynamic content The developer canembed PHP structured code (eg loops conditionals rich data structures) inside HTMLtags PHP is an OSS We used it on the server side for process control processing of theuserrsquos 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 transactionsand user-defined types and functions It is the most advanced OSS database availabletoday (Stinson 2001 Stones and Matthew 2001 httpwwwpostgreSQLorg)

PostGISwhich is also an OSS is an extension of the PostgreSQL RDBMS that adds support forgeographic objects (httppostgisrefractionsnet) In effect PostGIS spatially enablesthe PostgreSQL server allowing it to be used as a backend spatial database for Geographic

Web-Based Spatial Information Solutions

453

copy Blackwell Publishing Ltd 2003

Information Systems (GIS) much like ESRIrsquos Spatial Database Engine (SDE) or OraclersquosSpatial extension PostGIS follows the OGC ldquoSimple Features Specification for SQLrdquo(httpwwwopengisorgtechnoimplementationhtm)

MapServer is an OSS development environment for building basic web-mappingapplications (httpmapservergisumnedu) It facilitates the display and browsing ofgeographic data in commonly used vector and raster formats It is not designed to be afull-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 HatLinux distribution (httpwwwredhatcom) The Apache web server is a Hyper TextTransfer Protocol (HTTP) compliant web server It is an OSS maintained by the ApacheHTTP Server Project (httpwwwapacheorg) As of August 2002 63 of the web siteson the Internet are run on the Apache web server (Netcraft Web Server Survey httpwwwnetcraftcomsurvey)

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

41 The need for the web-based system

During the decade of the 90rsquos the National Institute for Forest Agriculture and LivestockResearch (INIFAP) in Mexico started to use GIS as part of its land suitability studiesThe largest of these studies was a strategic level national land use planning project toidentify the areas with potential to grow specific crops forage and forestry speciesconsidered 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 layerssoils (digitized from 150000 scale maps with information about primary and second-ary soil type and presence of chemical or physical phases) a digital elevation model at30 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 deriveother parameters that help to estimate the suitability of an area for a specific crop suchas the evaporationprecipitation coefficient For each agricultural forage and forestryspecies considered of strategic importance for the country INIFAPrsquos researchers com-piled a list of the values of the environmental factors (soil type slope precipitationmaximum minimum temperatures etc) that are considered ideal for the growth of theparticular species Together with this information they compiled what is called a ldquotech-nological packagerdquo which is a handbook of best practices for the production of the speciesin question State and federal government agencies researchers land owners seed com-panies entrepreneurs and agricultural insurance companies among others can requestthe identification of the areas that fulfill the environmental factors for the production ofthe species of their interest These areas are identified by querying the spatial databaselayers for the specific range of values considered ideal for the species in question Thesequery results are overlaid using a Boolean intersect operation to find the areas where allthe 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 INIFAPrsquos researchresponsibilities However soon after starting this service the units were overwhelmedby requests to identify areas that meet specific environmental requirements INIFAP is

454

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

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

In the past INIFAP had considered using the web as a platform to serve their geographicdata or selected pieces of it and to perform the previously described geo-processinganalyses However several factors had deterred them from further pursuing this option(1) the required Boolean overlay geo-processing capabilities currently do not exist outof the box in commercial web-GIS systems (2) the high costs of web-GIS software (3) thespecial 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 existingIT infrastructure (personnel skills software and applications) We decided to test theviability of using OS and OSS technologies to create a web-based spatial informationsystem for non-expert users that will overcome these issues The aim of the system is toallow end users to perform queries for desired values of environmental factors and doBoolean overlays of the results of these queries to identify the areas where all the desiredenvironmental factors are present By changing the values in their queries end users canhave a quick idea of the effects of these changes on the areas selected and their intersection

42 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 developmentstrategy for the system It would (1) easily integrate with the remainder of its existingIT infrastructure (personnel skills software and applications) (2) be scalable with initiallow costs and low total costs of ownership of the system over the long run (3) minimizespecial requirements (4) not imply steep learning curves and (5) eventually improve theefficiency in the expansion maintenance and quality control of the national database bycentralizing these functions in one place

Next we present the step-by-step process to create a prototype web-based spatialinformation system around OS and OSS that is capable of processing attribute queriesand Boolean intersection overlays The prototype system is based on a PC computer withaverage 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 theinterface prompts This demo system and all the referenced source code and relevantweb links can be found at http206168217254guanajuato The demo on this websitehas detailed instructions of how to perform queries intersect overlays and display theresults The prototype system continues to evolve Some improvements to the firstversion will be described in the discussion section The interface of the prototype versionthat is presented in this website still contains interaction steps that eventually will behidden from the end users However at this point the exposure of these steps serve toclosely illustrate each of the processes that occur in the system when processing a queryand overlay request

On the interface the user is presented with a screen divided into two areas on theleft an area to input queries and present instructions to the users and a map display areaon the right (see Figure 4) To input queries the user uses drop-down boxes to choosevalues (or a range of values) for each of the environmental factors (eg soils elevationtemperature) contained in the spatial database After selecting the desired values foreach parameter the user hits the submit query button The map display window is built

Web-Based Spatial Information Solutions

455

copy Blackwell Publishing Ltd 2003

using MapServer (httpmapservergisumnedu) In it the user selects which layershe or she wants to display including the features in each layer that were selected in thequery The map must be refreshed every time the type or number of layers displayed ischanged Visually it can be determined if there is an area where all the selected featuresintersect 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 canbe displayed by itself or with other layers using the SVGeoprocessor application TheSVGeoprocessor application takes the image generated by MapServer as backgroundand then overlays the intersection area in SVG format The SVG interactivity capabilitiesare used to respond to userrsquos actions as described in STEP 7 All of the following describedprocessing takes place on the server side of the system The client side is only used topresent 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 userrsquos requestfor queries on the thematic layers and overlay intersect geo-processing In the descriptionof 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 originallyin ESRIrsquos (Environmental Research Systems Institute Redlands California) shapefile formatare converted to tables in the PostgreSQL RDBMS This conversion is achieved using theshp2pgsql utility included as part of the PostGIS extension This utility takes a shapefileand outputs a series of SQL statements (eg CREATE TABLE and INSERT) to create atable in the PostgreSQL RDBMS (Figure 2) The resulting table contains all the attributesof the shapefile including the coordinates that define each feature These SQL statementsare 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 resultingtable PostGIS contains a file with close to 1800 projection definitions to choose fromThis process was repeated for each of the layers provided (soils elevation and theclimate layers)

STEP 2

In the query building interface (an HTML form see Figure 4) the user queriesthe database for the parameters of interest for each layer When the system finishesprocessing the intersect query the area where all the requested environmental parametersintersect is displayed on a SVG map If the requested environmental parameters do notintersect a message is sent to the user The user also has the option to invoke the ldquooverlayprocessorrdquo interface (Figure 5) This HTML form informs the user first about the numberof features in each layer that meet the requested parameters and second the number ofselected features whose bounding boxes intersect the bounding boxes of the selectedfeatures in a second layer By analyzing these numbers the user should be able to (1) seehow many features satisfy the specified parameters for each layer (2) identify which is themost limiting environmental factor in his or her query based on the number of selectedfeatures and (3) identify which layers do not intersect With this information the user canperform 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 usingthe HTML form In the server a PHP script converts the userrsquos input for each layer into aSQL statement (eg SELECT all FROM elevation WHERE elevation

ge

1500 AND ele-vation

le

3000) that is fed to the PostgreSQL-PostGIS RDMS PostgreSQL-PostGIS isinvoked 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 attributesrequested) This string is parsed in another PHP script to create a GML polygon andor

456

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

multipolygon entity in a GML document that now will represent the selected features andattribute (Figure 6)

STEP 5

The resulting GML documents corresponding to the features selected in eachlayer (eg SoilsSelectedxml ElevationSelectedxml etc) are input into a Java programthat computes the intersection of the features (one pair at the time) This program definesa Java class (GMLoverlayclass) that uses the SAX parsing method to search each GML

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

Web-Based Spatial Information Solutions

457

copy Blackwell Publishing Ltd 2003

document for the geometries and writes each polygon to an array of Java2D area objectsThese 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(intersectionxml)

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) inthe table simpleshape (that represents a layer) For illustration purposes we are showing alayer with a single feature

458

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

STEP 6

A XSLT Style Sheet (svgxsl see Figure 8) was created to transform the GMLcode contained in the intersectionxml file to SVG graphics for display as a map AgainStyle Sheets are custom-made XML instructions for formatting XML files By creatingother XSLT Style Sheets the GML output (intersectionxml) can be potentially formattedinto any text-based format for example any of the existing XML schemas for over fortydifferent areas of expertise HTML delimited text or UNGENERATE ArcInfo format

STEP 7

For convenience and due to the short development cycle for the prototypewe used MapServer to provide the map layout interface (frames legend scale bar andzoom levels) and for rendering the individual layers contained in the spatial databaseThe graphics generated by MapServer are then used as background for the display ofthe 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 tosend a query to the PostgreSQL-PostGIS database that returns the values for each ofthe layers at the point where the mouse is clicked (the equivalent of ldquospearingrdquo throughthe layers and pulling out the values for each layer) Plate 1 shows the SVG map that theuser gets as response to his query and geo-processing request

5 Discussion

We demonstrated how spatial information in a proprietary GIS format can be convertedto tables and managed in a RDBMS environment This simple transformation makes theinformation contained in GIS layers easier to combine and process with informationcontained in other DBMS applications (such as accounting and inventory systems) thatmight be part of the organizationrsquos IT infrastructure In the case of INIFAP after thistransformation 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 cropsrsquo

Figure 4 Sample HTML form

Web-Based Spatial Information Solutions

459

copy Blackwell Publishing Ltd 2003

yields rural census data or results of fertilization experiments contained in otherRDBMS 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 constantlyevolving and in the near future they will have enough capabilities to satisfy many simplegeo-processing requirements For example currently PostgreSQL-PostGIS is capable ofperforming over sixty spatially related operations such as finding the extent of a featureor group of features distance in projected units between two features selection offeatures to the left or right of a feature and intersection of two feature extents Thereare 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 beperformed directly in the PostgreSQL-PostGIS RDBMS using database records

Figure 5 The ldquooverlay processorrdquo interface

460

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

We also chose to transform the geographic layers from ESRIrsquos shapefile format totables in a RDBMS system in STEP 1 where SQL queries were executed to extract desiredfeatures and attributes from each layer Then using a PHP script the strings of textreturned by these queries were converted to GML documents that represent the selectedspatial features and their attributes Once the GIS layers are in GML format they can bepassed to any system application or geo-processing service that is able to read this OpenSpecification This is how the use of this OS enables a certain degree of interoperabilitybetween applications These applications or services can reside on a single machine ona local-area network or on any server connected to the Internet A packet of information(eg 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 fromone of the layers in the spatial database

Web-Based Spatial Information Solutions

461

copy Blackwell Publishing Ltd 2003

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 facilitatesdistributed processing and opens new possibilities for the combination and processing ofgeographic 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 documentin 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 AreaGeometry Methods contained in this API to generate the intersection subtraction additionand exclusiveOr of two Java2D area objects We currently using only the CASE 3 for theintersect method

462

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

process larger areas the processing time was unacceptable (several minutes) To minimizethe number of selected features that have to be converted to GML we used the boundingbox intersect function within PostgreSQL-PostGIS This function returns the records(features) from one table (layer) whose bounding boxes intersect the bounding boxes offeatures in a second layer In this way only the records that fulfill the query and whosebounding boxes intersect with bounding boxes of features from a second layer arereturned for conversion to GML documents This preprocessing greatly reduces thenumber of records that must be converted to GML for performing the actual intersectionof features in the GMLoverlayclass program and allowed us to process larger geo-graphic areas In the latest version of the prototype system we were able to significantlyimprove the response times by (1) replacing the use of PHP scripts to control theprocesses flow by PERL CGI scripts and (2) consolidating the conversion to SVGand GML formats of the overlay result (intersectxml) into the GMLoverlayclass Javaclass The full code for this implementation can be found at the demonstration website(http206168217254guanajuato)

We then created a Java class (GMLoverlayclass) that implements the intersect func-tion that is part of the Constructive Area Geometry Methods included in the Java2DAPI in STEP 5 In the same way we could have as easily implemented any of the otheroperators 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 codein Figure 7 is invoking these methods from the Java2D API we are just not currentlyusing them

In STEP 6 we demonstrated the use of XSLT Style Sheets to convert a layer in GMLformat (intersectionxml) to SVG (for graphical display) If geographic data in GML

Figure 8 XSLT Style Sheet to transform the GML document (intersectionxml) which repres-ents the area where the selected environmental parameters intersect to SVG for display onthe end userrsquos browser

Web-Based Spatial Information Solutions

457

copy Blackwell Publishing Ltd 2003

document for the geometries and writes each polygon to an array of Java2D area objectsThese 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(intersectionxml)

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) inthe table simpleshape (that represents a layer) For illustration purposes we are showing alayer with a single feature

458

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

STEP 6

A XSLT Style Sheet (svgxsl see Figure 8) was created to transform the GMLcode contained in the intersectionxml file to SVG graphics for display as a map AgainStyle Sheets are custom-made XML instructions for formatting XML files By creatingother XSLT Style Sheets the GML output (intersectionxml) can be potentially formattedinto any text-based format for example any of the existing XML schemas for over fortydifferent areas of expertise HTML delimited text or UNGENERATE ArcInfo format

STEP 7

For convenience and due to the short development cycle for the prototypewe used MapServer to provide the map layout interface (frames legend scale bar andzoom levels) and for rendering the individual layers contained in the spatial databaseThe graphics generated by MapServer are then used as background for the display ofthe 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 tosend a query to the PostgreSQL-PostGIS database that returns the values for each ofthe layers at the point where the mouse is clicked (the equivalent of ldquospearingrdquo throughthe layers and pulling out the values for each layer) Plate 1 shows the SVG map that theuser gets as response to his query and geo-processing request

5 Discussion

We demonstrated how spatial information in a proprietary GIS format can be convertedto tables and managed in a RDBMS environment This simple transformation makes theinformation contained in GIS layers easier to combine and process with informationcontained in other DBMS applications (such as accounting and inventory systems) thatmight be part of the organizationrsquos IT infrastructure In the case of INIFAP after thistransformation 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 cropsrsquo

Figure 4 Sample HTML form

Web-Based Spatial Information Solutions

459

copy Blackwell Publishing Ltd 2003

yields rural census data or results of fertilization experiments contained in otherRDBMS 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 constantlyevolving and in the near future they will have enough capabilities to satisfy many simplegeo-processing requirements For example currently PostgreSQL-PostGIS is capable ofperforming over sixty spatially related operations such as finding the extent of a featureor group of features distance in projected units between two features selection offeatures to the left or right of a feature and intersection of two feature extents Thereare 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 beperformed directly in the PostgreSQL-PostGIS RDBMS using database records

Figure 5 The ldquooverlay processorrdquo interface

460

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

We also chose to transform the geographic layers from ESRIrsquos shapefile format totables in a RDBMS system in STEP 1 where SQL queries were executed to extract desiredfeatures and attributes from each layer Then using a PHP script the strings of textreturned by these queries were converted to GML documents that represent the selectedspatial features and their attributes Once the GIS layers are in GML format they can bepassed to any system application or geo-processing service that is able to read this OpenSpecification This is how the use of this OS enables a certain degree of interoperabilitybetween applications These applications or services can reside on a single machine ona local-area network or on any server connected to the Internet A packet of information(eg 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 fromone of the layers in the spatial database

Web-Based Spatial Information Solutions

461

copy Blackwell Publishing Ltd 2003

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 facilitatesdistributed processing and opens new possibilities for the combination and processing ofgeographic 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 documentin 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 AreaGeometry Methods contained in this API to generate the intersection subtraction additionand exclusiveOr of two Java2D area objects We currently using only the CASE 3 for theintersect method

462

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

process larger areas the processing time was unacceptable (several minutes) To minimizethe number of selected features that have to be converted to GML we used the boundingbox intersect function within PostgreSQL-PostGIS This function returns the records(features) from one table (layer) whose bounding boxes intersect the bounding boxes offeatures in a second layer In this way only the records that fulfill the query and whosebounding boxes intersect with bounding boxes of features from a second layer arereturned for conversion to GML documents This preprocessing greatly reduces thenumber of records that must be converted to GML for performing the actual intersectionof features in the GMLoverlayclass program and allowed us to process larger geo-graphic areas In the latest version of the prototype system we were able to significantlyimprove the response times by (1) replacing the use of PHP scripts to control theprocesses flow by PERL CGI scripts and (2) consolidating the conversion to SVGand GML formats of the overlay result (intersectxml) into the GMLoverlayclass Javaclass The full code for this implementation can be found at the demonstration website(http206168217254guanajuato)

We then created a Java class (GMLoverlayclass) that implements the intersect func-tion that is part of the Constructive Area Geometry Methods included in the Java2DAPI in STEP 5 In the same way we could have as easily implemented any of the otheroperators 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 codein Figure 7 is invoking these methods from the Java2D API we are just not currentlyusing them

In STEP 6 we demonstrated the use of XSLT Style Sheets to convert a layer in GMLformat (intersectionxml) to SVG (for graphical display) If geographic data in GML

Figure 8 XSLT Style Sheet to transform the GML document (intersectionxml) which repres-ents the area where the selected environmental parameters intersect to SVG for display onthe end userrsquos browser

458

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

STEP 6

A XSLT Style Sheet (svgxsl see Figure 8) was created to transform the GMLcode contained in the intersectionxml file to SVG graphics for display as a map AgainStyle Sheets are custom-made XML instructions for formatting XML files By creatingother XSLT Style Sheets the GML output (intersectionxml) can be potentially formattedinto any text-based format for example any of the existing XML schemas for over fortydifferent areas of expertise HTML delimited text or UNGENERATE ArcInfo format

STEP 7

For convenience and due to the short development cycle for the prototypewe used MapServer to provide the map layout interface (frames legend scale bar andzoom levels) and for rendering the individual layers contained in the spatial databaseThe graphics generated by MapServer are then used as background for the display ofthe 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 tosend a query to the PostgreSQL-PostGIS database that returns the values for each ofthe layers at the point where the mouse is clicked (the equivalent of ldquospearingrdquo throughthe layers and pulling out the values for each layer) Plate 1 shows the SVG map that theuser gets as response to his query and geo-processing request

5 Discussion

We demonstrated how spatial information in a proprietary GIS format can be convertedto tables and managed in a RDBMS environment This simple transformation makes theinformation contained in GIS layers easier to combine and process with informationcontained in other DBMS applications (such as accounting and inventory systems) thatmight be part of the organizationrsquos IT infrastructure In the case of INIFAP after thistransformation 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 cropsrsquo

Figure 4 Sample HTML form

Web-Based Spatial Information Solutions

459

copy Blackwell Publishing Ltd 2003

yields rural census data or results of fertilization experiments contained in otherRDBMS 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 constantlyevolving and in the near future they will have enough capabilities to satisfy many simplegeo-processing requirements For example currently PostgreSQL-PostGIS is capable ofperforming over sixty spatially related operations such as finding the extent of a featureor group of features distance in projected units between two features selection offeatures to the left or right of a feature and intersection of two feature extents Thereare 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 beperformed directly in the PostgreSQL-PostGIS RDBMS using database records

Figure 5 The ldquooverlay processorrdquo interface

460

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

We also chose to transform the geographic layers from ESRIrsquos shapefile format totables in a RDBMS system in STEP 1 where SQL queries were executed to extract desiredfeatures and attributes from each layer Then using a PHP script the strings of textreturned by these queries were converted to GML documents that represent the selectedspatial features and their attributes Once the GIS layers are in GML format they can bepassed to any system application or geo-processing service that is able to read this OpenSpecification This is how the use of this OS enables a certain degree of interoperabilitybetween applications These applications or services can reside on a single machine ona local-area network or on any server connected to the Internet A packet of information(eg 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 fromone of the layers in the spatial database

Web-Based Spatial Information Solutions

461

copy Blackwell Publishing Ltd 2003

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 facilitatesdistributed processing and opens new possibilities for the combination and processing ofgeographic 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 documentin 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 AreaGeometry Methods contained in this API to generate the intersection subtraction additionand exclusiveOr of two Java2D area objects We currently using only the CASE 3 for theintersect method

462

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

process larger areas the processing time was unacceptable (several minutes) To minimizethe number of selected features that have to be converted to GML we used the boundingbox intersect function within PostgreSQL-PostGIS This function returns the records(features) from one table (layer) whose bounding boxes intersect the bounding boxes offeatures in a second layer In this way only the records that fulfill the query and whosebounding boxes intersect with bounding boxes of features from a second layer arereturned for conversion to GML documents This preprocessing greatly reduces thenumber of records that must be converted to GML for performing the actual intersectionof features in the GMLoverlayclass program and allowed us to process larger geo-graphic areas In the latest version of the prototype system we were able to significantlyimprove the response times by (1) replacing the use of PHP scripts to control theprocesses flow by PERL CGI scripts and (2) consolidating the conversion to SVGand GML formats of the overlay result (intersectxml) into the GMLoverlayclass Javaclass The full code for this implementation can be found at the demonstration website(http206168217254guanajuato)

We then created a Java class (GMLoverlayclass) that implements the intersect func-tion that is part of the Constructive Area Geometry Methods included in the Java2DAPI in STEP 5 In the same way we could have as easily implemented any of the otheroperators 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 codein Figure 7 is invoking these methods from the Java2D API we are just not currentlyusing them

In STEP 6 we demonstrated the use of XSLT Style Sheets to convert a layer in GMLformat (intersectionxml) to SVG (for graphical display) If geographic data in GML

Figure 8 XSLT Style Sheet to transform the GML document (intersectionxml) which repres-ents the area where the selected environmental parameters intersect to SVG for display onthe end userrsquos browser

Web-Based Spatial Information Solutions

459

copy Blackwell Publishing Ltd 2003

yields rural census data or results of fertilization experiments contained in otherRDBMS 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 constantlyevolving and in the near future they will have enough capabilities to satisfy many simplegeo-processing requirements For example currently PostgreSQL-PostGIS is capable ofperforming over sixty spatially related operations such as finding the extent of a featureor group of features distance in projected units between two features selection offeatures to the left or right of a feature and intersection of two feature extents Thereare 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 beperformed directly in the PostgreSQL-PostGIS RDBMS using database records

Figure 5 The ldquooverlay processorrdquo interface

460

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

We also chose to transform the geographic layers from ESRIrsquos shapefile format totables in a RDBMS system in STEP 1 where SQL queries were executed to extract desiredfeatures and attributes from each layer Then using a PHP script the strings of textreturned by these queries were converted to GML documents that represent the selectedspatial features and their attributes Once the GIS layers are in GML format they can bepassed to any system application or geo-processing service that is able to read this OpenSpecification This is how the use of this OS enables a certain degree of interoperabilitybetween applications These applications or services can reside on a single machine ona local-area network or on any server connected to the Internet A packet of information(eg 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 fromone of the layers in the spatial database

Web-Based Spatial Information Solutions

461

copy Blackwell Publishing Ltd 2003

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 facilitatesdistributed processing and opens new possibilities for the combination and processing ofgeographic 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 documentin 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 AreaGeometry Methods contained in this API to generate the intersection subtraction additionand exclusiveOr of two Java2D area objects We currently using only the CASE 3 for theintersect method

462

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

process larger areas the processing time was unacceptable (several minutes) To minimizethe number of selected features that have to be converted to GML we used the boundingbox intersect function within PostgreSQL-PostGIS This function returns the records(features) from one table (layer) whose bounding boxes intersect the bounding boxes offeatures in a second layer In this way only the records that fulfill the query and whosebounding boxes intersect with bounding boxes of features from a second layer arereturned for conversion to GML documents This preprocessing greatly reduces thenumber of records that must be converted to GML for performing the actual intersectionof features in the GMLoverlayclass program and allowed us to process larger geo-graphic areas In the latest version of the prototype system we were able to significantlyimprove the response times by (1) replacing the use of PHP scripts to control theprocesses flow by PERL CGI scripts and (2) consolidating the conversion to SVGand GML formats of the overlay result (intersectxml) into the GMLoverlayclass Javaclass The full code for this implementation can be found at the demonstration website(http206168217254guanajuato)

We then created a Java class (GMLoverlayclass) that implements the intersect func-tion that is part of the Constructive Area Geometry Methods included in the Java2DAPI in STEP 5 In the same way we could have as easily implemented any of the otheroperators 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 codein Figure 7 is invoking these methods from the Java2D API we are just not currentlyusing them

In STEP 6 we demonstrated the use of XSLT Style Sheets to convert a layer in GMLformat (intersectionxml) to SVG (for graphical display) If geographic data in GML

Figure 8 XSLT Style Sheet to transform the GML document (intersectionxml) which repres-ents the area where the selected environmental parameters intersect to SVG for display onthe end userrsquos browser

460

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

We also chose to transform the geographic layers from ESRIrsquos shapefile format totables in a RDBMS system in STEP 1 where SQL queries were executed to extract desiredfeatures and attributes from each layer Then using a PHP script the strings of textreturned by these queries were converted to GML documents that represent the selectedspatial features and their attributes Once the GIS layers are in GML format they can bepassed to any system application or geo-processing service that is able to read this OpenSpecification This is how the use of this OS enables a certain degree of interoperabilitybetween applications These applications or services can reside on a single machine ona local-area network or on any server connected to the Internet A packet of information(eg 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 fromone of the layers in the spatial database

Web-Based Spatial Information Solutions

461

copy Blackwell Publishing Ltd 2003

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 facilitatesdistributed processing and opens new possibilities for the combination and processing ofgeographic 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 documentin 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 AreaGeometry Methods contained in this API to generate the intersection subtraction additionand exclusiveOr of two Java2D area objects We currently using only the CASE 3 for theintersect method

462

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

process larger areas the processing time was unacceptable (several minutes) To minimizethe number of selected features that have to be converted to GML we used the boundingbox intersect function within PostgreSQL-PostGIS This function returns the records(features) from one table (layer) whose bounding boxes intersect the bounding boxes offeatures in a second layer In this way only the records that fulfill the query and whosebounding boxes intersect with bounding boxes of features from a second layer arereturned for conversion to GML documents This preprocessing greatly reduces thenumber of records that must be converted to GML for performing the actual intersectionof features in the GMLoverlayclass program and allowed us to process larger geo-graphic areas In the latest version of the prototype system we were able to significantlyimprove the response times by (1) replacing the use of PHP scripts to control theprocesses flow by PERL CGI scripts and (2) consolidating the conversion to SVGand GML formats of the overlay result (intersectxml) into the GMLoverlayclass Javaclass The full code for this implementation can be found at the demonstration website(http206168217254guanajuato)

We then created a Java class (GMLoverlayclass) that implements the intersect func-tion that is part of the Constructive Area Geometry Methods included in the Java2DAPI in STEP 5 In the same way we could have as easily implemented any of the otheroperators 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 codein Figure 7 is invoking these methods from the Java2D API we are just not currentlyusing them

In STEP 6 we demonstrated the use of XSLT Style Sheets to convert a layer in GMLformat (intersectionxml) to SVG (for graphical display) If geographic data in GML

Figure 8 XSLT Style Sheet to transform the GML document (intersectionxml) which repres-ents the area where the selected environmental parameters intersect to SVG for display onthe end userrsquos browser

Web-Based Spatial Information Solutions

461

copy Blackwell Publishing Ltd 2003

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 facilitatesdistributed processing and opens new possibilities for the combination and processing ofgeographic 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 documentin 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 AreaGeometry Methods contained in this API to generate the intersection subtraction additionand exclusiveOr of two Java2D area objects We currently using only the CASE 3 for theintersect method

462

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

process larger areas the processing time was unacceptable (several minutes) To minimizethe number of selected features that have to be converted to GML we used the boundingbox intersect function within PostgreSQL-PostGIS This function returns the records(features) from one table (layer) whose bounding boxes intersect the bounding boxes offeatures in a second layer In this way only the records that fulfill the query and whosebounding boxes intersect with bounding boxes of features from a second layer arereturned for conversion to GML documents This preprocessing greatly reduces thenumber of records that must be converted to GML for performing the actual intersectionof features in the GMLoverlayclass program and allowed us to process larger geo-graphic areas In the latest version of the prototype system we were able to significantlyimprove the response times by (1) replacing the use of PHP scripts to control theprocesses flow by PERL CGI scripts and (2) consolidating the conversion to SVGand GML formats of the overlay result (intersectxml) into the GMLoverlayclass Javaclass The full code for this implementation can be found at the demonstration website(http206168217254guanajuato)

We then created a Java class (GMLoverlayclass) that implements the intersect func-tion that is part of the Constructive Area Geometry Methods included in the Java2DAPI in STEP 5 In the same way we could have as easily implemented any of the otheroperators 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 codein Figure 7 is invoking these methods from the Java2D API we are just not currentlyusing them

In STEP 6 we demonstrated the use of XSLT Style Sheets to convert a layer in GMLformat (intersectionxml) to SVG (for graphical display) If geographic data in GML

Figure 8 XSLT Style Sheet to transform the GML document (intersectionxml) which repres-ents the area where the selected environmental parameters intersect to SVG for display onthe end userrsquos browser

462

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

process larger areas the processing time was unacceptable (several minutes) To minimizethe number of selected features that have to be converted to GML we used the boundingbox intersect function within PostgreSQL-PostGIS This function returns the records(features) from one table (layer) whose bounding boxes intersect the bounding boxes offeatures in a second layer In this way only the records that fulfill the query and whosebounding boxes intersect with bounding boxes of features from a second layer arereturned for conversion to GML documents This preprocessing greatly reduces thenumber of records that must be converted to GML for performing the actual intersectionof features in the GMLoverlayclass program and allowed us to process larger geo-graphic areas In the latest version of the prototype system we were able to significantlyimprove the response times by (1) replacing the use of PHP scripts to control theprocesses flow by PERL CGI scripts and (2) consolidating the conversion to SVGand GML formats of the overlay result (intersectxml) into the GMLoverlayclass Javaclass The full code for this implementation can be found at the demonstration website(http206168217254guanajuato)

We then created a Java class (GMLoverlayclass) that implements the intersect func-tion that is part of the Constructive Area Geometry Methods included in the Java2DAPI in STEP 5 In the same way we could have as easily implemented any of the otheroperators 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 codein Figure 7 is invoking these methods from the Java2D API we are just not currentlyusing them

In STEP 6 we demonstrated the use of XSLT Style Sheets to convert a layer in GMLformat (intersectionxml) to SVG (for graphical display) If geographic data in GML

Figure 8 XSLT Style Sheet to transform the GML document (intersectionxml) which repres-ents the area where the selected environmental parameters intersect to SVG for display onthe end userrsquos browser

Web-Based Spatial Information Solutions

463

copy Blackwell Publishing Ltd 2003

format gains popularity Style Sheets could be developed to transform GML documentsto a wide array of formats (eg any text format any XML schema or GIS proprietaryformats) 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 formatsfor high quality output Eventually libraries of Style Sheets could be posted on websitesdownloaded to reside locally or invoked directly from remote servers to perform atransformation This possibility would greatly increase the speed and ease with whichgeographic 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 currentlyavailable OSS and OS The required technology for solving spatial problems in an Internetbased computing environment is available from at least one mature OS project We usedthe OSS we consider to be the most powerful widespread accessible easy to learn andwith a good level of user support in the form of software documentation books anduser-groupsrsquo forums Typical OSS installation involves downloading the source code forthe target Operating System (eg Linux Windows XP NT or 2000) identifying anddownloading other required software components configuring the desired features andcompiling 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 littleprogramming experience However most mature OSS are well supported with thoroughinstallation instructions and any motivated GIS user should be able to install and startusing the OSS presented in this article

Given that the purpose of the project here described was exploratory we ended upusing a wider array of OS and OSS than would probably have been optimally requiredto create the functionality present in the prototype system For the same reason we tookmore 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 issuesfaced when implementing advanced OSS web-based GIS solutions is the breadth oftechnical skills required and the logistics of orchestrating the interaction of manyapplications Designing web-based GIS solutions requires a thorough understanding ofcore 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 isnot difficult to find these necessary skills in an IT department or in a highly motivatedpower user

In developing the prototype system we learned (1) the potential of SVG to develophighly interactive mapping applications on the web (2) PostgreSQL-PostGIS is a robustdatabase management system that offers a considerable and continuously increasingnumber of geo-processing functions (3) Java2D can be effectively used for basic 2D vectoroverlay (a specifically geo-spatially oriented Java API such as the OS Java TopologySuite (httpwwwvividsolutionscomjtsjtshomehtm) is clearly preferable for moreadvanced 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 Internetmap server

464

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing Ltd 2003

From this experience we can conclude that for organizations with scarce resourceswanting 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 withgeneral IT background (UNIX programming databases design and management)(3) small software footprints (4) no need to commit to a proprietary web-GIS DBMSor web software with their associated costs (5) ease of compatibility with existing ITinfrastructure (personnel with basic databases and programming skills existing DBMSsoftware and DBMS applications) (6) flexibility to implement geo-processing capabil-ities currently non-existent in commercial web-GIS software (eg Boolean intersectoverlays) (7) the principles to implement these technologies are straightforward andaccessible to a broad audience of geographic information scientists and developersand (8) the system developed has the potential to interoperate with other systems andapplications that use the same OS

Our experience also showed that the resulting text files tend to be large whengeographic 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 pointsper feature contained in a layer (Sahay 1999 provides a formula for calculating thestorage size of a GML document based on these two parameters) As an example a layerin ESRIrsquos shapefile format of size 342708 bytes would occupy 599473 bytes in itscorresponding GML representation In addition because GML up to version 212 doesnot support topology common boundaries between features must be stored twice (oncefor each feature) The size of the GML files could affect secondary storage (eg harddrive or tape) requirements as well as the time required to parse the file to extractdesired information A large implementation would greatly benefit from file compres-sion algorithms and highly efficient parsing methods More research is required on bothof these areas

Figure 9 SVG graphic of a simple feature Figure 6 shows the GML code from which thisimage is generated

Web-Based Spatial Information Solutions

465

copy Blackwell Publishing Ltd 2003

Next we will test the scalability capacity of these technologies to create the fullimplementation for INIFAPrsquos web-based spatial information needs In addition we areplanning to make a full evaluation of the reliability performance security and totalcosts of ownership for the system We also need to make the overlay processor interfacemore user friendly and improve its capacity to explain the intersection results obtainedFinally so far we have dealt only with geographic data in vector format and we arecurrently working on developing web-based geo-processing capabilities for raster data

Acknowledgements

The authors would like to thank the National Institute for Forest Agriculture andLivestock Research (INIFAP) Central Region and especially Dr Hilario Garcia-Nietofor their support and cooperation in the development of this project We would also liketo thank the anonymous reviewers for their helpful comments and suggestions forimprovement 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 91ndash100Boumphrey 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

BirminghamWrox 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 OrsquoReilly amp AssociatesGardels K 1997 Open GIS and on-line environmental libraries

SIGMOD Record

26 32ndash8Gould M and Ribalaygua A 1999 A new breed of web-enabled graphics

GeoWorld

12(3)46ndash9

Harvey F 1999 Designing for interoperability Overcoming semantic differences In Goodchild M FEgenhofer M Fegeas R and Kottman C (eds)

Interoperating Geographic Information Systems

Boston MA Kluwer 85ndash97

Hecht L 2002a Get your free interoperability roadmap

GeoWorld

15(2) 22ndash3Hecht L 2002b Insist on interoperability

GeoWorld

15(4) 22ndash3Hecht L 2002c Web services are the future of geo-processing

GeoWorld

15(6) 23ndash4Herring J 1999 The OpenGIS data model

Photogrammetric Engineering and Remote Sensing

65585ndash8

Holland D 2001 Delivering the digital national framework in GML

GeoEurope

10(8) 29ndash30Kay 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 39ndash54Lake R 2001a GML 20 enabling the geospatial web

Geospatial Solutions

11(7) 38ndash41Lake R 2001b GML lays the foundation for the geospatial web

GeoWorld

14(10) 42ndash5Lowe J 2002 Spatial on a shoestring Leveraging free Open Source Software

Geospatial Solutions

12(6) 42ndash5McKee L 1998 What does OpenGIS Specification conformance mean

GeoWorld

11(8) 38Neumann A 2002 Comparing SWF (Shockwave Flash) and svg (Scalable Vector Graphics) file

format specifications In

Proceedings of the

SVG Open Developers Conference

15ndash17 July 2002Zurich Switzerland (available at httpwwwcartonetpaperssvgcomparison_flash_ svghtml)

Web-Based Spatial Information Solutions

465

copy Blackwell Publishing Ltd 2003

Next we will test the scalability capacity of these technologies to create the fullimplementation for INIFAPrsquos web-based spatial information needs In addition we areplanning to make a full evaluation of the reliability performance security and totalcosts of ownership for the system We also need to make the overlay processor interfacemore user friendly and improve its capacity to explain the intersection results obtainedFinally so far we have dealt only with geographic data in vector format and we arecurrently working on developing web-based geo-processing capabilities for raster data

Acknowledgements

The authors would like to thank the National Institute for Forest Agriculture andLivestock Research (INIFAP) Central Region and especially Dr Hilario Garcia-Nietofor their support and cooperation in the development of this project We would also liketo thank the anonymous reviewers for their helpful comments and suggestions forimprovement 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 91ndash100Boumphrey 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

BirminghamWrox 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 OrsquoReilly amp AssociatesGardels K 1997 Open GIS and on-line environmental libraries

SIGMOD Record

26 32ndash8Gould M and Ribalaygua A 1999 A new breed of web-enabled graphics

GeoWorld

12(3)46ndash9

Harvey F 1999 Designing for interoperability Overcoming semantic differences In Goodchild M FEgenhofer M Fegeas R and Kottman C (eds)

Interoperating Geographic Information Systems

Boston MA Kluwer 85ndash97

Hecht L 2002a Get your free interoperability roadmap

GeoWorld

15(2) 22ndash3Hecht L 2002b Insist on interoperability

GeoWorld

15(4) 22ndash3Hecht L 2002c Web services are the future of geo-processing

GeoWorld

15(6) 23ndash4Herring J 1999 The OpenGIS data model

Photogrammetric Engineering and Remote Sensing

65585ndash8

Holland D 2001 Delivering the digital national framework in GML

GeoEurope

10(8) 29ndash30Kay 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 39ndash54Lake R 2001a GML 20 enabling the geospatial web

Geospatial Solutions

11(7) 38ndash41Lake R 2001b GML lays the foundation for the geospatial web

GeoWorld

14(10) 42ndash5Lowe J 2002 Spatial on a shoestring Leveraging free Open Source Software

Geospatial Solutions

12(6) 42ndash5McKee L 1998 What does OpenGIS Specification conformance mean

GeoWorld

11(8) 38Neumann A 2002 Comparing SWF (Shockwave Flash) and svg (Scalable Vector Graphics) file

format specifications In

Proceedings of the

SVG Open Developers Conference

15ndash17 July 2002Zurich Switzerland (available at httpwwwcartonetpaperssvgcomparison_flash_ svghtml)

466

G Anderson and R Moreno-Sanchez

copy Blackwell Publishing 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 346ndash58

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

GeoWorld

15(8) 23ndash5 Rasmus L 2000

PHP Pocket Reference

Sebastopol CA OrsquoReilly amp AssociatesSahay N 2002 GMLView A GML Map Renderer Unpublished MS Technical Paper Department

of Computer Engineering University of Minnesota (available at httpwww-userscsumn edu~sahay8701planb_1_10htm)

Seth A P 1999 Changing focus on interoperability in information systems From system syntaxstructure to semantics In Goodchild M F Egenhofer M Fegeas R and Kottman C (eds)Interoperating Geographic Information Systems Boston MA Kluwer 5ndash30

Stinson B 2001 PostgreSQL Essential Reference Indianapolis IN New Riders Stones 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 SoftwareFree Software (OSSFS) Look at the Numbers

WWW document httpwwwdwheelercomoss_fs_whyhtml Waters N 1999 Is XML the answer to internet-based GIS GeoWorld 12(7) 32ndash3