SVG as an Enabling Technology for Sharing Geographic Knowledge

Keywords: SVG, scalable vector graphics, WFS, WMS, editing

Nedjo Rogers, MA
Learning Technologies Developer
GroundWorks Learning Centre
British Columbia


Currently working with the community-mapping focused non-governmental organization GroundWorks, Nedjo has combined in his work internet and mapping applications with street community organizing and international partnership in Latin America. His MA in Geography focused on community gardening as an example of local land management in the downtown eastside of Vancouver. Nedjo is a developer of the GeoClient software, a standards-based open source project that aims to help enable social and environmental organizations, citizen groups, First Nations and others to freely share and explore geographic data.


This paper reviews approaches to enabling the collaborative sharing of geographic knowledge--here called geopooling.

Table of Contents

1. Introduction
2. Shared Places
     2.1 Context
     2.2 Geographic Data and SVG
3. Geographic Data Editing in SVG
     3.1 How to parse GML into SVG and vice versa?
     3.2 How to determine the structure of the data to be edited?
     3.3 How to integrate SVG with form-based data input?
     3.4 How to balance standards support with accessibility? 
     3.5 How to enable backward-compatibility for XHTML?
     3.6 How to dynamically construct content like map legends, feature info tables, and editing forms?
     3.7 How to write for both native and plug-in support?
     3.8 How to allow background HTML elements to be seen through an SVG element?
     3.9 How to overcome browser security restrictions of posting to non-originating servers?
     3.10 How to avoid errors in handling of namespace prefixes?
     3.11 How to limit data transactions to just the data being edited?  
     3.12 How to enable vector editing where user has no SVG support?
     3.13 How to implement group- and user-level security on update operations?
4. Conclusions

1. Introduction

Just back from a bike trip where she found a great back-roads shortcut, an avid cyclist opens her web browser to a map of her region showing previously registered routes. Lots of good ones, but hers isn't there. So she clicks her route onto the map, types in a bit of explanatory text, and hits the "submit" button. The next time users throughout the region log on, they'll see her shortcut among the many recommended routes. She may not know or care, but vector graphics have provided the means not only for displaying but also for editing the geographic data she's interested in.

SVG SVG (Scalable Vector Graphics) is now well established (despite delays in browser-support) as a standard format for the client-side display of rich vector graphical content. As presentations at the first SVG Open conference demonstrated, SVG content is not limited to static files but can be generated on the fly based on server- or client-side parsing of vector data from a wide range of sources. The rich capabilities of SVG are particularly applicable in the field of online mapping, where a vector-enabled medium may help illumine the complex interrelation of diverse spatial features.

Yet data display is only one side of the coin. Incorporating standard DOM DOM (Document Object Model) methods for creating and modifying XML XML (eXtensible Markup Language) content, SVG is not limited to display but provides a potentially powerful medium for creating and editing vector data. 

This paper is about the potential contributions of SVG to the collaborative sharing of geographic knowledge--what I'll call, for short, geopooling . More specifically, by geopooling I mean the creation of shared geographic data stores among groups and individuals who may be both data users and data contributors.  

To clarify and limit what's meant by geopooling, it's probably useful to make a few opening distinctions. The first is between interactivity and collaboration. Many current web developments are focused on increasing the ability of website "consumers" to selectively display and interpret information--without actually adding to it. An advanced user interface may provide a high degree of interactivity without in any way challenging the division between data provider and data consumer. In contrast, a collaborative environment is one in which users themselves contribute to the information bases they are exploring.

The second distinction is between what we might call data harvesting and genuine data sharing. From simple web usage statistics to cookie-based tracking and sophisticated customer profiling, there is now a formidable array of devices used to harvest data from internet users, often without their knowledge or informed consent. Largely integrated with promotion and sales efforts, this sort of information collection should be clearly distinguished from the enabling of users intentionally and transparently to share information with each others, building a mutually-accessible data share.

Which brings us really to the last distinction--one of intent. The ability to pool geographic knowledge among concerned or affected citizens and groups is a key need in a range of social and ecological movements and settings. No doubt technologies and data encodings have their own inherent novelty, but my main interest here is an applied one.

Within an overall approach to enabling collaborative data sharing, SVG may be useful in building an important component: digitizing spatial geometries and visualizing the results. The first part of the paper looks at the need for and progress towards geopooling technologies. The second examines specific problems and approaches in using SVG as a user interface for editing geographic data, taking as a case study the open source GeoClient project, of which I am one of the developers.

2. Shared Places

Location matters. Social and natural relations, including relations of power and resistance, are worked out over space. From environmental issues - species distributions, contaminant dispersions, or wilderness boundaries - to social questions like poverty, housing, health, urban greening, or the challenges facing indigenous groups asserting sovereignty over their traditional territories, spatial knowledge may be key to understanding and responding to the crises and opportunities of capitalist society.

The spatial aspects of social and ecological issues and movements have sparked a number of sometimes overlapping approaches--community mapping, bioregional mapping, and what has been called PPGIS PPGIS (Public Participation Geographic Information Systems) . Community mappingprojects or organizations - like GroundWorks, where I work - apply popular and generally hands-on methodologies to mapping out assets, problems, and potential solutions. The Green Map System (, which involves a system of symbols to identify "green" sites used in cities around the world, is an example of the many community mapping initiatives linking location to public concerns and interests.  As developed and presented by Doug Aberley and others in publications like Boundaries of Home [BOUND] , bioregional mapping starts with identifying the boundaries of a local "bioregion" and compiling for it layers of social, ecological, and historical information. Adopting the technical tools of GIS GIS (Geographic Information Systems) used by industry and government but turning them to public interest uses, non-governmental organizations, First Nations, and others have begun to develop PPGIS as tools both to assess current impacts and issues and to push for positive change.

Particularly as they've entered the technical domain of GIS, NGOs and First Nations have hit significant barriers--of staff time, technical expertise, computer hardware and software, available funding. These barriers have only increased as groups move to adopt and adapt internet-based mapping technologies. Yet online systems are increasingly key to reaching members and decision makers. And - at least in the rhetoric of its promoters - internet technology was supposed to remove barriers rather than adding them, wasn't it? Before digging into the specifics of SVG and mapping, I'd like to pause and review both barriers to and recent progress in enabling online geopooling.

2.1 Context

After the early days of mainly static web pages and one-way email, internet developments have quickly moved to enable multidimensional and interactive information flows. Website users routinely carry on threaded discussions; groupware (software designed to enable collaborative work) and content management systems (server software that facilitates the production of database-driven websites, often with user-contributed content) enable users to build shared information bases that may be limited to a specific group or open to every web user. Crucially, web technologies are beginning to enable users to move beyond the role of passive receivers to become active participants in collaborative information flows.

Of course, all is not equal within this trend towards increased data exchange. On the one hand, major initiatives like Microsoft's .NET strategy are firmly wedded to existing private interests and proprietary corporate technologies. On the other, innovative initiatives like the Indimedia network enable citizens to post and share stories, photos, or video, contributing to alternative information sources and at some level challenging corporate and state control of media, including the internet. It is at this latter placement - leading edge popular initiatives that cut across dominant interests - that much of the most promising technical development is happening.

2.2 Geographic Data and SVG

While the ready exchange of everything from textual and visual information to musical recordings proceeded apace, geographic information sharing over the internet had a slower start. This fact may have reflected in part the relative dominance of a few key players and their proprietary approaches in the field of GIS. Certainly the first version of key GIS manufacturer ESRI's ArcView Internet Map Server, to take one example, was notable for its approach of trying to force wholesale an existing commercial desktop application with its proprietary formats into an internet role--in this case, an almost complete failure. (ArcIMS progressed only when it took approaches notably similar to those already sketched in by the open source MapServer software.)

But the slow pace of online mapping development also had to do with the inherent complexity of geographic information. A geographic feature typically has spatial geometry in addition to other simple or complex attributes. A lake, for example, may have a name and a maximum depth - both readily represented by text or numerical values in fields - but also a geometry representing its perimeter--not so readily represented, particularly as its accurate recording must include real-world coordinates in a particular spatial reference system (projection).

A system for collaboratively exchanging geographic data would therefore need at least the following components:

  1. A server-based system capable of retrieving existing feature type and feature member data as well as carrying out update, insert, and delete requests on spatial and non-spatial attributes.
  2. Protocols for transmitting data requests between client and server.
  3. A client system capable of displaying spatial geometries and attribute information and allowing interactive input and editing.

Of course there are applications that do all this. As in most high tech areas, military solutions lead the way. For the latest in updateable geographic depictions we need look no further than cutting-edge surveillance or killing machines--if we can or wish to get anywhere near them! On the commercial market, one of the more advanced solutions is Autodesk MapGuide, made by the producers of AutoCAD. The MapGuide server software serves up vector information and accompanying feature attributes to a client application, which optionally includes a basic interface for digitizing feature geometries. While potentially effective, this solution comes with significant costs. From the client end, use of a MapGuide server requires downloading and installing a proprietary plug-in. Data are in a proprietary format not readily accessible to or usable by other applications. And a full MapGuide solution comes with a price tag way out of the range of any but the biggest NGOs. Effectively, the main proprietary approaches limit collaborative geographic data sharing to powerful state and corporate bodies and their clients.

There are also a few lower-cost innovative geopooling applications already in use by NGOs. A good example is the map tools on the "Living Independently in Los Angeles" (LILA) website (???). Designed to allow people with mobility barriers to share information on accessible sites in LA, LILA provides an intuitive interface through which users can add their own site information, filling in a form on site details and clicking a map image to register site location. The LILA website is a compelling example of the potential of community-based geopooling. However, LILA and other similar approaches have notable limitations:

  1. They are specific to the particular datasets being served and dependent on non-standard approaches and therefore not readily adaptable to other uses (even if they were available for use and adaptation, which generally they are not).
  2. They are usually based on commercial softwares and proprietary data formats.
  3. They are limited to point-type features.

So to the technical requirements of collaborative map composing already identified we can add some practical ones. Ideally, to be accessible and applicable to citizen interests and issues, collaborative geographic tools would meet as many as possible of the following criteria:

  1. use non-proprietary data formats (both graphic and geographic) readily used and shared by a variety of applications
  2. be usable with software that many users have already installed (instead of requiring specialized downloads, e.g., of plug-ins)
  3. be usable over relatively low bandwidth connections
  4. include the ability to update existing features as well as add new ones, and
  5. work with point, line, and polygon features.

From the host organization side, desirable solutions would be:

  1. relatively easy to install, set up, and maintain, and
  2. inexpensive or free.

Enter web standards and open source projects.

Somewhere in the interstices between corporate and popular internet developments are emerging web standards. Like the rules of syntax in language, some level of standardization is a prerequisite to any broad computer-based communication. Yet effective, universal standards may in some contexts threaten the existing placements and competitive advantages of proprietary systems (file formats, softwares, operating systems, etc.). And, of course, powerful corporations are themselves key players in the formation of web standards. A bit like the United Nations, standards setting bodies can't effectively act without the support of the leading powers, but those powers won't readily support common approaches that threaten their dominance and prerogatives (Macromedia's lukewarm support of SVG being a noted case in point). The general result is an interesting tension between the potential of universal standards and the undiminished strength of private interests and agendas.

But limitations and all, standards provide a common basis for promoting continuity between efforts. The Open GIS Consortium is the primary standards-setting body in the field of GIS and has established a number of standards potentially relevant to online mapping, among these:

  1. Simple Features for SQL, a set of database encodings and methods for geographic data storage, retrieval, and updating.
  2. Geography Markup Language (GML), an XML encoding for geographic data, including geographic and non-geographic feature attributes.
  3. Web Map Service (WMS), a set of protocols for requesting map graphics (e.g., with specified layers and spatial extent). WMS graphics are usually served up in raster formats, e.g., PNG and GIF.
  4. Web Feature Service (WFS), a set of methods and protocols for the transmission of vector geographic data in GML format. Under the specification, a "basic" WFS can describe its capabilities and answer requests for data, which are sent to a client in Geography Markup Language (GML), an XML encoding that is the defined in another OGC specification. But a "transactional" WFS in addition can accept client requests for creating new features, or for updating or deleting existing ones. In other words, the WFS specification provides a basis not only for serving up data streams over the Internet but also for adding to, editing, and maintaining the underlying geographic data sets.

As in practically every other area of software development, open source projects are leading the way in providing innovative and standards-based solutions to mapping problems. Some key projects on the data storage and serving sides:

All of these projects require a fairly high level of technical expertise to set up and manage and all except GeoTools pretty much require a dedicated server (they're not the sort of software you can commonly convince a commercial hosting company to throw in!). But there are creative solutions to these challenges--for instance, a number of organizations pitching in towards the expenses of a shared server.

There are also (at least!) three more open source projects specifically aimed at enabling geopooling:

A key advantage of working with standards is that it allows a developer to focus on just one part of an overall problem, leaving other parts to those developing for related standards. We're getting ready now to assemble the pieces of an integrated solution to online data pooling. The picture looks something like this:

Component Relevant standards Open source solutions
data storage Simple Features for SQL PostGIS
data transmission Web Feature Service via Geography Markup Language GeoServer using GeoTools or Deegree, Mapserver for raster representation
graphical client Web Feature Service, Web Map Service ?

Table 1

With data transmission and storage solutions in place, the remaining piece is a graphical client.

There are various possible approaches to writing graphical clients that will interact with web feature services, and several current initiatives and developments, some of them open source. A few of these:

Approach Examples
Extend existing proprietary client applications to include WFS/WMS capabilities Dominant GIS software manufacturer ESRI has released an extension to their gratis viewing software ArcExplorer 4 that enables (read-only) WFS and WMS interactions.
Enable server-side rendering of WFS content as raster images UMN Mapserver version 3.7 includes the ability to add WFS feature types as "layers" in a Mapserver application
Assemble HTML/ECMAScript content on server Web Map Composer, a commercial software, includes limited WFS client capability, sending point feature information as client-side image maps (clickable areas on a raster image). The open source PHPWMS project features server-side parsing of XML WMF capabilities, enabling the web browser client to send selective layer requests. While PHPWMS has no WFS support, it could in principle be extended to include at least point-type WFS support.
Write custom client applications (in Java or some other programming language) The Java-based GeoTools project is working on client applications with WMS and WFS support.
Emulate vector graphics on the client to enable data editing An impressive demo from the open source Community Map Builder project at uses the open source wz_jsgraphics library to enable client-side vector data editing.

Table 2

All of these approaches enhance interoperability and some are promising for geopooling applications. But there are also good reasons to consider SVG as an option. Some key considerations:

The rest of this paper is an in-depth look at problems and solutions in applying SVG to the task of editing geographic data, taking as a case study a particular SVG WFS client application that I have produced in collaboration with Amri Rosyada: GeoClient.

3. Geographic Data Editing in SVG

Part of the open source GeoServer project, GeoClient is an SVG-based application written as a WFS client. I presented a detailed overview of GeoClient at the 2002 GML Dev Days--please see "Pictures From Numbers" [PICTURES] and documentation accompanying the software download.

In producing GeoClient, we have come up against a number of interesting problems. Reviewing these problems and our approaches to them may be useful to others developing mapping applications but also more broadly for those working with SVG and other XML encodings or for for native SVG support. And hey, I'm also hoping that, where we're not on the best path, other developers might be able to point us in better directions.

3.1 How to parse GML into SVG and vice versa?

Using SVG as a means of interacting with a WFS requires the intermediate step of parsing the GML content to and from SVG format. This parsing can be done on the server (e.g., through XSLT) but is also possible on the client, through standard DOM methods. GeoClient implements this latter approach. Client-side parsing has the potential advantage of eliminating the need for custom software installations on the server in addition to a WFS.

The basic workflow of enabling data editing is something like this: load GML data from the server > parse GML into SVG > enable interactive modification of the SVG elements (or creation of new elements) > parse data back into GML > post feature geometry - along with any attribute data - back to web feature server.

Translating GML geometries into SVG is surprisingly straightforward. The GML geometries served up by a WFS fall into three basic types and their variants: points and multipoints, linestrings and multilinestrings, and polygons and multipologons. (The remaining type is multigeometries--a combination of two or more of the previous types.) A point is readily represented by an SVG element with an x/y coordinate--like a circle. For GML linestrings and polygons, there are a couple of major options. One is to use the remarkably flexible SVG path element. This has the advantage of handling everything from single linestrings to multipolygons. Alternately, GML linestrings are well represented as SVG polylines while GML polygons map well as SVG polygon elements.

3.2 How to determine the structure of the data to be edited?

Before editing data, an application needs to know the data's structure. In relational database terms, this structure would be the tables and fields, each with names and data types. Working with the WFS specification, the structure of each featureType is described in an XML schema document (XSD) that a client can request from the server. So far so good--but building a client that will handle any XSD that the server throws at it proves to be particularly challenging. In the standard GIS world features typically have a simple set of attributes stored in one attribute table--not in GML! Features served up by a WFS may have complex attributes--multiple companies that own a mine, for example, each having their own name and address. And a feature may even have more than one geometric attribute--for example, a point to represent a centroid as well as a polygon representing a perimeter. Whether nested or not, each attribute may have a range of limitations set (min and max values, length, a list of acceptable values).

Fortunately, in GeoClient our task is simplified by the fact that we're building (at least initially!) for GeoServer, which as yet doesn't support complex feature types and which typically has a single spatial attribute. We're getting somewhere, but certainly comprehensive XSD parsing is one of the larger unfinished tasks.

3.3 How to integrate SVG with form-based data input?

Since geographic data include both feature geometries and other feature attributes, an editing interface has to include both graphical and textual data editing. In GeoClient, we're taking two parallel approaches that have led to two versions of the software: GeoClient, written in pure SVG, and GeoClientX, written in XHTML (blending both SVG and HTML).

With full native browser support for SVG still some time away, the most-used SVG viewing software is the Adobe SVG Viewer (ASV), a web browser plug-in that offers a remarkably full approximation of what native SVG browser support should look like. (The open source Batik SVG viewer is similarly advanced but less used.) In some settings the ASV provides almost seamless SVG browser support. But behaviour of the plug-in is inconsistent across platforms and between browsers, with some of the main issues centring on scripting support and integrating SVG with non-SVG content. Some browser versions don't allow any scripting access to the plug-in; in others, access is limited in hard to predict ways. Without consistent scripting access, interactions between SVG and other elements are problematic.

The response of many leading SVG developers to the problem of inconsistent support is simple: write pure SVG. In the area of web mapping, for example, Andreas Neumann and others at have produced highly-developed pure-SVG user interfaces. This means, for example, building custom SVG elements to replicate standard HTML user interface features like combo boxes.

In GeoClient our first and still our main approach is a modified version of pure SVG.  

Yet there are a number of problems with the purist approach. On the developer side:

And on the user side:

The option is beginning to design for native browser support for SVG.

While full native support for SVG is not here yet, SVG has been incorporated into the core code of the open source Mozilla browser. It is currently switched off by default and in some cases (e.g., for use on Windows) requires a separate graphics library download. SVG-enabled Mozilla can display SVG files but can also display SVG elements mixed with HTML ones--which is of course just what the ASV can also do. So the challenge becomes writing a viewer that will work with both native and plug-in support.

In direct contrast to our approach in the SVG GeoClient, the approach in GeoClientX is: use HTML wherever feasible, save SVG for what only it can do. Restricting SVG use to where it's absolutely required may seem a paradoxical approach for SVG aficionados. The point, however, is to produce a software that has significant functionality even where SVG support is lacking.  

3.4 How to balance standards support with accessibility? 

Handling XML within the browser (rather than, e.g., through server-side scripts) effectively limits support to recent browsers. But how recent?  GeoCleintX is written to work in IE 5.0+, Mozilla 1+, and Netscape 7+. Maintaining backward compatibility to IE5.0 is sometimes a challenge given the limited DOM support of that version but the advantage of greater support seems worth it for now.

3.5 How to enable backward-compatibility for XHTML?

Of the new encodings introduced by the XHTML specification, the most problematic ones for backward compatibility with IE 5.0 are the namespace declaration and the CDATA section designation in scripts, the inclusion of either of which causes IE to throw errors.

Our solution in GeoClientX is to use server-side PHP scripting to detect Internet Explorer and write modified HTML that IE 5.0 will handle.

First, set up a boolean variable $XHTML:

$browser=$_SERVER["HTTP_USER_AGENT"]; //test if
        browser is MSIE $ismsie = strstr ($browser, 'MSIE'); //if not
        MSIE, use XHTML if($ismsie==false){ $XHTML=true; } //otherwise, not
        else{ $XHTML=false; }

Then include the XML content-type header, the strict HTML doctype declaration, and the XHTML namespace reference only if $XHTML is true:

<? if($XHTML==true){ header("Content-type:
        application/xml"); ?> <!DOCTYPE HTML PUBLIC
        "-//W3C//DTD HTML 4.01//EN"
        ""> <html
        xmlns=""> <? } else{
        ?> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
        ""> <html>
        <? } ?>

Finally, set up functions to be called each time a script is opened or closed, including the <![CDATA[ section only if required:

<? function openScript(){ global $XHTML; echo
        "<script type=\"text/javascript\">\n";
        if($XHTML==true){ echo "<![CDATA[\n"; } } function
        closeScript(){ global $XHTML; if($XHTML==true){ echo
        "]]>\n"; } echo "</script>\n"; } ?>

The result is compliant XHTML where possible, backwards compatibility with IE 5.0 where necessary.

3.6 How to dynamically construct content like map legends, feature info tables, and editing forms?

In writing dynamic HTML content, many developers have become attached to a Microsoft-invented method, innerHTML, which allows ready creation of new content by turning text strings into elements. For example, the line elt.innerHTML="<img onclick=\"alert('hello')\" src=\"images/example.png\"/>";would add an image as a child node of the element referenced by elt. So influential has the innerHTML approach become that the Mozilla project implemented innerHTML as one of the few non-standards methods it supports.

But writing in XHTML means saying goodbye to innerHTML along with all other non-standard methods.

Using standard DOM methods, the most obvious option for dynamically adding content is to create a new node (a <table>, for example) using the createElement() method, add attributes using the setAttribute() method, create and append (using elt.appendChild()) sub-nodes, then append the new node to its intended place in the document hierarchy. But this approach runs into two problems. One is a problem of scale. By the time you've coded an image within a table cell within a table row within a table that is itself within a cell, row, and table, all of which have various attributes and various other sub-nodes that have to be appropriately created and appended, you're looking at pages of code.

The second problem is even more intractible. It turns out that both IE and Mozilla are notably uneven in their support for creating new elements. So a given created element may or may not appear on the page, and if it appears it may or may not respond to standard methods (this latter problem is particularly notable with created form elements).

The best answer I've found to both problems with createElement() is to include on a page generic versions of needed elements (e.g., enclosed in a <div> element with style.visibility=hidden) and then use the cloneNode() method to clone these master elements. Attributes can then be customized on the new element through transiting the node tree using methods like firstChild and nextSibling. The cloneNode() method is particularly necessary working with Mozilla's SVG implementation since, at least at the time of writing, new SVG elements created with the createElement() method aren't properly appended and don't appear. If the new element may itself subsequently be replaced (to reflect new data or a changed state) it's handy to use the replaceChild() method instead of the appendChild() one to add the new element, putting in a dummy element (e.g., "<div></div>") in the original base node so that it can be replaced on the first update iteration. The result is code that works in IE 5 and also in Mozilla's strict mode and that is more compact and easy to work with than either using innerHTML or creating everything from scratch with createElement(). In GeoClientX I've only in one instance had to resort to substituting a browser-specific innerHTML call when IE 5 balked at cloning a complex node.

3.7 How to write for both native and plug-in support?

In writing GeoClientX in XHTML we're anticipating inclusion of SVG support in the core Mozilla browser--but in the meantime and until SVG support is available in Internet Explorer too we also need support for the Adobe viewer.

Our approach to coding for both native and non-native support has three stages:

3.8 How to allow background HTML elements to be seen through an SVG element?

Integrating SVG and HTML - in particular, overlaying SVG elements above background raster map images - requires transparent SVG elements--yet in both the AVG and Mozilla's native SVG implementation SVG elements by default include an opaque white background.

In the AVG, making the SVG element transparent is simple: include an wmode attribute in the <embed> element and set it to "transparent". In this mode, only filled or stroked elements are visible. The plug-in will even allow other page elements to be displayed over it.

In the Mozilla SVG implementation I haven't found a similarly full solution. The best workaround I've come up with is to use a Mozilla CSS extension for controlling element opacity. By applying a style of "-moz-opacity:50%;" to the enclosing HTML element (e.g., a <div>) of an SVG element, the SVG becomes partially transparent. Background elements are therefore visible, but muted.

3.9 How to overcome browser security restrictions of posting to non-originating servers?

To interact with a web feature service, a client application needs to exchange information with the server hosting the WFS; but The Adobe SVG Viewer allows exchange of XML only with the "originating server" (a server at the domain where the client application was accessed). For mapping applications, this restriction limits direct interaction with WFSs and WMSs to services on the same server as the client application, neatly defeating the purpose of standards-based development: open exchange! Working with native browser support is not a solution--both Mozilla/Netscape and Internet Explorer include similar restrictions.

The solution we've adopted in GeoClient is simple: have a script posted together with the application act as an intermediary. The flow becomes:

browser > server-side script > web service > server-side script > browser

3.10 How to avoid errors in handling of namespace prefixes?

Support for namespace prefixes within tag names (e.g., the "gml:" in the tag <gml:Point ... >) is incomplete and inconsistent between browsers. Use of namespace prefixes therefore tends to produce script errors. With the ASV proprietary postXML function the stripping out of namespace prefixes can be done through simple global search and replaces after XML files are loaded, since the files are loaded as text strings prior to parsing with the additional proprietary function parseXML. When using native browser functions, though, XML files are imported as nodes, so namespace prefixes have to be stripped out before loading. Given that in GeoClient we're already manipulating the XML through a server script before loading it into the browser, these removals can be done simply with the PHP function str_replace:$response = str_replace("gml:","",$response);

The challenge is that a particular GML file may have additional custom namespace prefixes--an eventuality I haven't yet coded for.

3.11 How to limit data transactions to just the data being edited?  

Geographic datasets are often very large. If a client wishes to edit a single feature, it may be inefficient or impractical to have to download the full feature set first.

An example to clarify the problem. Say you want to update the geometry of a road segment that is part of a database of 100,000 such features, each representing, say, 1k of data in GML format. It would certainly be handy to be able to fetch just the desired segment rather than the full 100Mb featureType set (which, in any case, couldn't be displayed in a standard SVG environment). And ideally designating which feature to edit would be as easy as pointing and clicking (rather than, for example, having to drill down through attributes and potentially multiple hits to find the segment you're looking for). 

The solution we're exploring is to use a raster (WMS) representation of the featureType that can be clicked to bring up GML (vector) data for editing. Setup looks something like this.  

The event chain in active editing:

A bit circuitous, yes, but the approach does succeed in limiting the vector data to what is immediately needed for the data editing task.

3.12 How to enable vector editing where user has no SVG support?

For fullest user support, it would be handy to have at least some vector graphic capability even where the user has neither native nor plug-in SVG support. In GeoClient we're looking at two options here.

3.13 How to implement group- and user-level security on update operations?

As whenever you're dealing with online data editing, it's desirable - in some cases, critically necessary - to have some control over who has edit access to what. Ideally, a geopooling application would include at least an optional system for designating specific permissions to users and groups of users.

The good news is that there are plenty of options out there. Particular candidates are open source content management systems like Nuke and PostNuke, which include well-documented methods for adding "modules". Writing a mapping module for, say, PostNuke isn't something we're doing yet with GeoClient, but it would be a logical next step.

4. Conclusions

Significant progress has been made in the past year towards providing standards-based, free, open source tools applicable to both the presentation and editing of online map data. With storage (PostGIS) and updating (GeoServer) solutions in place, graphical editing clients are the next important step. Work to date confirms that SVG can play a central role.


In writing this paper and accompanying software I've drawn on the contributions of GeoClient co-developer Amri Rosyada and of other open source projects and developers including GeoServer, Refractions Research's PHPWFS, and Steve Lime's DHTML Mapserver interface.


Boundaries of Home, Doug Aberley, Ed., New Society Publishers, 1993. ISBN 1-55092-207-6.
Pictures From Numbers: GeoClient, an open source web feature server (WFS) client, presented at GML Dev Days 2002, (

XHTML rendition created by gcapaper Web Publisher v2.0, © 2001-3 Schema Software Inc.