A Simple Web Mapping Solution for Complex Spatial Databases

Brandon Plewe
Department of Geography
Brigham Young University
Provo, Utah USA


The Internet holds great potential as a distribution medium for maps and geographic information. Its abilities to connect directly to source data on servers, and to reach a global audience as cheaply as a single person have made Web GIS a rapidly growing industry. However, expensive web mapping software leaves much to be desired: map quality has generally been poor, interactivity capabilities have been limited, and only simple database queries are allowed.

The Atlas of Historical County Boundaries in Utah and Nevada uses a powerful, but complex database to support temporal GIS data. The web version needed to deliver high-quality, interactive maps based on customized spatiotemporal queries, with minimal programming and cost. The Scalable Vector Graphics (SVG) specification has the visual quality to meet the design needs, but does not have database query capabilities. This was accomplished using a new tool from Oracle, XML Structured Query Language (XSQL), which uses simple parameter files to enable web-based query of Oracle databases. A third XML application, the Extensible Stylesheet Language (XSL), with a processor built into the Oracle Web Server, was used to convert XSQL results into SVG maps.

The XML files have fairly simple structures, and Javascript programming was only needed for advanced interactive features in SVG, not for the core mapping service. The service was created with no software cost (except Oracle, which was already acquired for the database). The only concern was rather slow performance, due to internal database processing more than the web mapping process. All told, the XML-based solution was able to successfully build a useful, high-quality historical atlas.

Keywords: SVG, Oracle Spatial, Database-driven graphics, webmapping

1 Introduction

Cartographic publishing is a challenge.  With the advent of geographic information systems (GIS), remote sensing, and digital cartography tools, an unprecedented amount of geographic information has been collected (and can be collected), much of which would be useful to a very large (but often very specialized) group of people. However, the traditional means of map publishing, such as printed atlases, has proved inefficient for reaching many audiences.

For example, we have compiled a historical GIS to produce a volume of the Atlas of Historical County Boundaries (Long 1993) covering Utah and Nevada. This is a landmark series documenting changing county boundaries in great detail. This information would be useful for local governance, management of tax and other land records, and genealogy. However, the Atlas series was recently dropped after 20 volumes (covering 24 states) by their publisher because the market was too small to support printing such large volumes. What is the best way to deliver this information to this modest-sized (compared to a road atlas) but varied audience?

Each of the options for map publishing has advantages and disadvantages. A printed atlas can be of a very high visual quality, and easy to carry and read. However, it is expensive to produce, publish, and distribute, especially for "small-run" publications; they are also static and space-limited, reducing the amount of information that can be covered. The Internet provides an inexpensive, global distribution channel, as well as interactive capabilities and limitless database size. Thus, the integration of GIS, maps, and the Internet is a natural solution for distributing geographic information to a wide audience (Plewe 1997, Kraak and Brown 2001). This is attested by the phenomenal growth of the Internet GIS industry (Plewe 2000).

Unfortunately, Internet-based map services have many problems as well. The maps are of an almost universally poor quality; the Internet reaches only a minority of the world's population; current Internet GIS server software is very expensive; map services are difficult to create and maintain (most require extensive programming to create a usable service); and their capabilities are limited. Each of the two approaches mirrors the other; the strengths of the print atlas are the weaknesses of the Internet atlas, and vice versa.

The limited capabilities of Internet GIS are especially difficult for our county atlas. In order to represent temporal change and boundary uncertainty, a complex data model was needed (12 interconnected tables). Most software does not support custom database queries for generating maps without extensive programming; they expect to display complete layers from a static database.

The goal of the research presented in this paper was to develop an atlas that retained the advantages of both media, thus eliminating their respective disadvantages. Therefore, it needed the following features:

  1. Distributed via the Internet, consuming as little bandwidth as possible
  2. High visual quality, having a feature symbology, labeling, and user interface that rivals print atlases (although it cannot be the same, due to inherent limitations in screen resolution)
  3. Interactive, allowing for typical map browsing as well as content control, custom spatiotemporal queries, animations, and links to text and multimedia
  4. Inexpensive, requiring no more cost than the Internet server software and GIS/database software that is needed anyway
  5. Can be created with minimal programming, and even then it is only necessary for added features, not the basic map display

Although many of these goals have been mutually exclusive in traditional GIS and cartography technology, several recent developments offer a potential solution. We used the latest tools to build an online atlas, then tested it against the above criteria.

2 Available Technologies

Because current Internet GIS is lacking in many respects, I had to look elsewhere for solutions. Fortunately, many others are grappling with similar issues of interactive, graphical, database-generated web content, so internet tools are being created that are indirectly related to our application. Three recently-developed standards are especially pertinent: Scalable Vector Graphics (SVG) for displaying vector graphics such as maps (Lilley and Jackson 2001), XML Structure Query Language (XSQL) for querying databases via the web (Oracle 2002), and the Extensible Stylesheet Language (XSL) for translating documents from one format to another (Froumentin 2002).

All three technologies are applications of the Extensible Markup Language (XML), a "meta-standard" for structuring information in many forms. XML has many advantages over previous standards for the representation and transformation of information. Because the basic structure of any XML document is the same, a single XML tool can process any document, even if they are very different kinds of information (e.g., geographic and textual) in different applications. In fact, the processor is rarely even aware of the nature of the information. Because XML is clear text, it is easy (if a bit slow) to process, and it is easy to create new processing tools (e.g., it can be created with any free text editor). Different XML tools can be tightly integrated, since the information being passed between them is similar. XML also eases the burden on the developer since most applications are high-level declarative files, leaving all the low-level processing to common off-the-shelf software.

2.1 SVG

Scalable Vector Graphics is an official World Wide Web Consortium (W3C) specification for describing object-based graphics (in contrast to raster images in JPEG and PNG). In general, vector files have several advantages over raster in some applications: they consume less bandwidth for many kinds of graphics (including most maps), retain their quality even when one zooms in, and can be transferred incrementally. In addition, SVG includes many powerful features used in this research:

Thus, SVG can use small files (our need #1) to produce very high quality maps (#2) that can include interactive control (some of #3). For these reasons, SVG has gained popularity recently among professional and academic cartographers. The quality results shown at the 2002 SVG Open/Carto.net Developers Conference show the awesome potential of SVG. The only major disadvantage of SVG is that it currently requires a browser plug-in or specialized software, neither of which are commonly installed, but over time, it will be probably be more accessible.

2.2 XSL

The Extensible Stylesheet Language is another W3C standard specification based on XML. In contrast to most XML documents, that consist of structured content, XSL is actually a language for translating content from one application of XML to another. It uses "templates" that match elements in the input document, changing them to different elements in the output document. XSL also includes many procedural constructs, such as IF statements, to control the output content. One advantage of XSL of special relevance to this research is that it can process XML without knowing the significance or nature of the content. Thus, it can process SVG graphics just as easily as it processes XHTML text, without any special "drawing" procedures.

Because it is a procedural language, XSL is not useful unless it is passed to a interpretor program, called an XSL Translator (XSLT), along with the source XML document. Most of the problems with XSL are minor, such as the tendency for the output documents to be poorly formatted. It appears that there is a performance hit using XSL, especially for long input documents and complex XSL template structures.

2.3 XSQL

The final piece of the puzzle, XML Structured Query Language, is not an official web standard, but a proprietary application of XML created by Oracle as part of their XML and web database services. It is essentially a web-based "wrapper" for SQL: an XSQL page can include one or more SELECT or other SQL statements that may include parameters from the incoming HTTP GET request. The XSQL parser consecutively sends each SQL command to the Oracle RDBMS. The resultant rowset of each is returned to the parser, which formats it into a generic XML document, consisting of row and field elements. Because the output formatting is a simple process, the performance of an XSQL page is very close to that of a raw SQL query.

XSQL can execute any valid query, and will format any data types in the result XML, including complex data types. This is especially important for geographic information stored in Oracle Spatial, which has new data types for geometric shapes and special functions for spatial query and analysis (including topological comparison operators, polygon overlay, and even reprojection). This allows XSQL to do spatial analysis and return geographic data without needing any special spatial knowledge. It is the site creator's responsibility to create valid spatial queries and interpret the spatial results.

Typically, the result XML will be returned directly to the client, but if a <?xml-stylesheet?> directive is in the XSQL page, it will be passed on to the XSL translator to reformat (in this case, to SVG).

3 Implementation

A working mapping website was created by integrating these three XML applications, as shown in Figure 1, using various software tools that were either free or included with software we already owned:

Figure 1. Architecture of XML-based web mapping service

3.1 Database

The creation of the temporal GIS that supports the website is not the topic of this paper, but some of its characteristics are relevant. A new data model was designed (called a Geo-Historical Information System) that uses several tables to represent the changing locations, attributes, and existence of geographic features, including situations in which these locations, attributes, and existences (as well as dates) are uncertain. The individual tables record features, location geometries, attribute values, event dates, and so on. Locations are stored using the Oracle Spatial Object-Relational format, which stores complex spatial structures, such as linestrings, using nested tables of coordinates. The database was built using ESRI ArcSDE, a middleware program for managing GIS data in a database, and ArcView GIS at the client end. However, no ESRI software was used in the web service.

3.2 Interface SVG document

The interactive mapping process begins when the user accesses the main SVG interface (currently at http://webmap.geog.byu.edu/webmap/atlas.svg ). The entire user interface is implemented in SVG, including interactive tools, allowing for better integration between the map and the interface elements. Some relevant portions of this document are shown below:

<svg ...>
function changedate(evt) {
	var dt = datebox.textbox.getFirstChild().getFirstChild().data;
	url = "http://webmap.geog.byu.edu/webmap/counties.xsql?date="+dt;
function newmap(stat) {
	var mapelem = svgdoc.getElementById("map");
	var newnode = window.parseXML(stat.content, svgdoc);
	var svgelem = svgdoc.rootElement;
	svgelem.replaceChild(newnode, mapelem);

<rect id="map" x="0" y="0" width="1020" height="621"/>
<g id="interface">
	... [titles, legends, etc.]
	<g id="btnDate" onmousedown="pushdatebtn(evt)" onmouseup="changedate(evt)">
		... [graphics that look like a "go" button]

One part of this interface is a textbox for entering a date (created using Kevin Lindsey's free Textbox Javascript/SVG widget). When someone pushes the go button, the changedate function needs to request a new map from the server. Unfortunately, the SVG specification has no mechanism for internet communication. Such functionality was added unilaterally in the Adobe Viewer, through the (the window.getURL() method. Generally, using proprietary extensions is not advisable, but it was the only option available; hopefully, such a feature will become standardized in the future. The call to getURL() includes the URL of an XSQL page, with the date as a parameter. When the SVG document is returned, the newmap() function loads it into the document in place of the "map" element (the rectangle is merely a dummy placeholder), which will in turn be replaced by maps returned from future queries.

3.3 XSQL Page

When the XSQL page is requested by atlas.svg, the HTTP server does not return it directly, but refers it to the Oracle XSQL servlet for processing. The XSQL page includes several queries, for loading various types of features as they existed on the given date, including county and state boundaries, towns, county seats, along with labels. The complete page can be found at http://webmap.geog.byu.edu/webmap/counties.xsql.txt, but only the county boundaries portion is shown below:

<?xml-stylesheet type="text/xsl" href="layers2.xsl"?>
<mymap connection="ghis" xmlns:xsql="urn:oracle-xsql">
<layer id="counties">
<xsql:query rowset-element="" row-element="linerow" bind-params="date date" date="29990101">
select object_id as feature_id, shape
	from lines
	where object_id in (
		select object_id from linelocs
		where type_id = 19 and loc_certain = 1
		and start_date &lt;= ? and end_date &gt; ?
		group by object_id )
	order by feature_id
... [other queries for other map layers]

The <mymap> and <layer> elements serve no purpose; anything not recognized by the servlet is verbatim to the result XML document, allowing the developer to customize the output. The servlet replaces the question marks in the SQL query inside the <xsql> element with the date parameter from the URL (or the default value if no parameter was provided) and sends it to Oracle. The database returns a rowset of any matching records, which XSQL transforms into an XML document. Usually the XML has a hierarchy of <rowset> and <row> elements, with self-titled elements for each field within each row (in this case, feature_id and shape). In this case, the element names have been customized by the rowset-element and row-element parameters. The object-relational data types (nested tables) used by Oracle Spatial to store the geometry in the shape field are merely returned as nested XML elements. A sample follows:

<?xml version="1.0" ?> 
 <layer id="counties">
  <linerow num="1">
    ... [oracle spatial metadata]
  ... [<linerow> elements for more shapes]
... [other layers]

3.4 XSL Stylesheet

Since the XSQL page has a stylesheet directive, the XSQL Servlet passes the XML result to the XSL Processor with the requested stylesheet (which can be found at http://webmap.geog.byu.edu/webmap/layers2.xsl). This stylesheet includes the following code:

<xsl:output method="xml" indent="no" media-type="image/svg+xml"/>
<xsl:template match="mymap">
	<svg id="map" ...>
	<xsl:apply-templates />

<xsl:template match="layer">
	<xsl:attribute name="id">
		<xsl:value-of select="@id" />
	<xsl:apply-templates />

<xsl:template match="linerow">
		<xsl:attribute name="points">
				<xsl:if test="position() mod 2 = 1">
					<xsl:value-of select="format-number(. + 180,'##.#####')"/>
				<xsl:if test="position() mod 2 = 0">
					<xsl:value-of select="format-number(90 - .,'##.#####')"/>
					<xsl:text> </xsl:text>
... [templates for other kinds of geometry]

The first template match the processor makes is with <mymap>, which it turns into an <svg> element. Then it searches for matches within <mymap>, finding at least one <layer>, each of which is turned into a <g> in the output SVG document. Within each layer, it matches with several <xxxrow> elements (lines in the case of the county boundaries). The template creates a <polyline> element, changing the list of ordinate elements into a single long attribute. This results in an SVG document:

<svg id="map" ...>
<g id="counties">
<polyline points="68.20793,49.08481 68.20732,49.08409 ...">
<polyline points="...">
... [groups for other layers]

The SVG document includes no styling, to reduce file size; the interface SVG document has a stylesheet based on the group id's to control layer symbology. The document is returned to the SVG viewer to be incorporated into the shell document as described above.

4 Results & Conclusions

The first draft of the online Atlas of Historical County Boundaries in Utah and Nevada was created successfully, and is available at http://webmap.geog.byu.edu/webmap/atlas.svg. Although not yet in its final form, it was evaluated according to the criteria listed earlier:

  1. Bandwidth: The interface SVG document is 12K, while the map returned for each date is about 500K. This is the entire dataset for a given date, including all county boundaries and towns at full resolution; therefore, zooming in requires no more downloading. To decrease startup time, the interface initially loads a pre-existing, compressed map (150K) of current time instead of a generated map. Unchanging reference layers, such as lakes (50K compressed) are only loaded once from pre-generated files. This is large enough to operate slowly over a modem connection, but is acceptable given the amount of information delivered.
  2. Quality: SVG provides excellent symbology control, so the design is only limited by the cartographer's abilities. The Adobe viewer provides anti-aliasing, so the visual quality almost matches print media. The only design difficulty encountered was label placement (automatically generated at the centroid of each polygon, and lower-left justified on each point); we may solve this by precoding label locations in the database.
  3. Interactivity: We were able to design an interface that could make use of Adobe's internal pan and zoom tools, and included an interactive legend, as well as the date entry textbox. Many other interactive tools are planned, such as a date slider bar and dynamic attribute readout. The interactive feel of the date request was limited by performance. Each request took about 15 seconds to retrieve the map (on a high-speed connection); most of that time was taken by the database answering the complex SQL query; XSQL and XSL added only about half a second each. The research was performed on an older server with little memory. The production server will be a dual processor machine with more memory, which should improve response times.
  4. Expense : All of the tools used were either free, or part of software we already owned. Obviously, Oracle and the GIS software are expensive, but this research assumes that one has already built the database. Lately, Oracle has even been offering free fully-functional downloads of 9i on the Internet (the profit must be in support).
  5. Programming : The first experimental version of the site was created in about 30 hours (not including learning time). However, most of that was in developing the interactive features of the SVG interface. Building the core map request engine took only about 8 hours. The most difficult task was not confusing the four different XML flavors used.

Generally, the atlas seems to work quite well. The only real issue is performance, which will be improved a little with better server hardware. Although it is not good enough for real-time generated animations, it is adequate for individual queries. The core system required very little programming (and then in the very simple languages of XSL and XSQL), but a fair amount was needed to design a usable system. As in most development situations, even that burden can be eased when developers share ideas and code. The XML documents and Javascript files were designed for speed and compactness, not for portability (i.e., many custom parameters are hardwired in), but the files should be usable as templates for other projects.


Froumentin, Max (2002) The Extensible Stylesheet Language (Internet Document: http://www.w3.org/Style/XSL/). Boston: World Wide Web Consortium.

Kraak, Menno-Jan, Brown, Allan (2001) Web Cartography: Developments and Prospects. London: Taylor & Francis.

Lilley, Chris, Jackson, Dean (2001) Scalable Vector Graphics (Internet Document: http://www.w3.org/Graphics/SVG/). Boston: World Wide Web Consortium.

Long, John, ed. (1993) Atlas of Historical County Boundaries (Series) New York: Scribner.

Oracle Corporation (2002) Oracle XML Developer's Kit for Java, Oracle Technology Network (Internet Document: http://otn.oracle.com/tech/xml/xdk_java/). Redwood Shores, CA: Oracle.

Plewe, Brandon (1997) GIS Online: Information Retrieval, Mapping, and the Internat. Santa Fe, NM: Onword Press.

Plewe, Brandon (2000) Profiling the DGI Market: Just How Big is It? GeoInfo Systems, V.10#2, 58.

Valid XHTML 1.0!