Cleopatra

Publishing GML data as interactive SVG maps

Keywords: SVG, GML, XSLT, XML, ECMAScript

Alison Meynert
Software Developer
Schema Software Inc.
Vancouver
British Columbia
Canada
alisonm@schemasoft.com
http://www.schemasoft.com

Biography

Alison Meynert is the most recent addition to SchemaSoft's development team as of July 2003. She completed three of her co-op work terms with NewHeights Software Corporation and was part of the initial development group working on the XMLLite parser presented at Vancouver XML Developer's Association (http://www.vanx.org) by Dr. Michael Levy. Alison has a Computer Science and Statistics degree from the University of Victoria, where she was the top graduate in her department. She spent the summer 2002 term funded by an NSERC grant researching algorithms for the generation of Latin squares (http://www.cs.uvic.ca/~ameynert/lsq).


Abstract


Cleopatra is a proof of concept for generating Sclable Vector Graphics [SVG] maps from Geographic Markup Language [GML] data sources. The conversion process is intended to occur at runtime, providing a publishing layer between a GML data source and end users. End users could be on different platforms and have different requirements of the data. To this end, it is desirable to publish GML data using open standards, which means SVG is an ideal output format.

The overriding project goals were customization and interactivity. Customization of the output maps is important because of potentially widely varying end user needs. Interactivity is the key distinguishing feature between paper and computer maps. This presentation is a description of how we used existing technologies to implement the conversion of GML to interactive SVG maps, the limitations of current tools, and the potential extensions of the project.


Table of Contents


1. Conversion process
2. Navigation
3. Level of detail
4. Styling
5. Data analysis
6. Online resources
Footnotes
Acknowledgements
Bibliography

1. Conversion process

GML is an eXtensible Markup Language [XML] encoding for the transport and storage of geographic information, including both the spatial and non-spatial properties of geographic features. Spatial data is well defined and fixed, but non-spatial data is not. Contributors could not agree on a fixed set of names for things such as features. For example: river, stream, creek, or brook? What about support for multiple languages?

To work around this, the GML schema allows for extensions. The great strength of GML is its resulting ability to easily describe proprietary encodings. This is also its great weakness: a universal GML viewer cannot be designed. This is an example of GML data provided by the UK Ordnance Survey (http://www.ordsvy.gov.uk):

<osgb:topographicMember
    xmlns:osgb="http://www.ordnancesurvey.co.uk/xml/namespaces/osgb">
    <osgb:TopographicArea fid="osgb1000000334379659">
        <osgb:featureCode>10172</osgb:featureCode>
        <osgb:version>1</osgb:version>
        <osgb:versionDate>2001-11-07</osgb:versionDate>
        <osgb:theme>Roads Tracks And Paths</osgb:theme>
        <osgb:calculatedAreaValue>116.925804</osgb:calculatedAreaValue>
        <osgb:changeHistory>
            <osgb:changeDate>2000-08-05</osgb:changeDate>
            <osgb:reasonForChange>New</osgb:reasonForChange>
        </osgb:changeHistory>
        <osgb:descriptiveGroup>Road Or Track</osgb:descriptiveGroup>
        <osgb:make>Manmade</osgb:make>
        <osgb:physicalLevel>50</osgb:physicalLevel>
        <osgb:polygon>
            <gml:Polygon xmlns:gml="http://www.opengis.net/gml"
                            srsName="osgb:BNG">
                <gml:outerBoundaryIs>
                    <gml:LinearRing>
                        <gml:coordinates>278189.470,186194.440
                        278199.630,186197.890 278193.570,186208.660
                        278185.500,186205.920 278189.470,186194.440
                        </gml:coordinates>
                    </gml:LinearRing>
                </gml:outerBoundaryIs>
            </gml:Polygon>
        </osgb:polygon>
    </osgb:TopographicArea>
</osgb:topographicMember>

Since GML and SVG are both XML encodings, the natural conversion tool is eXtensible Stylesheet Language Transformations [XSLT] . We can use XPath [XPath] parameters to locate extended information for any GML schema. These and other customizable conversion parameters are stored in an XML file, as in the example below:

<!-- this has various GML application Schema specific xpaths -->
<settings:xpaths>
    <!-- absolute xpath that will find features -->
    <settings:feature>//osgb:topographicMember</settings:feature>

    <!-- relative xpath from feature to feature type -->
    <settings:featureType>./*[1]/osgb:theme</settings:featureType>

    <!-- relative xpath from feature to attribute data-->
    <settings:attributeData>./*[1]/*[text() and count(text()) = 1]</settings:attributeData>
    <!-- relative xpath from attribute data to data name-->
    <settings:attributeDataName>local-name()</settings:attributeDataName>
    <!-- relative xpath from attribute data to data value-->
    <settings:attributeDataValue>./text()</settings:attributeDataValue>
</settings:xpaths>

One of the stated project goals is a highly customizable parameter-driven conversion process. The conversion parameters XML file, some of which is displayed above, is our solution. Some of the other parameters are:

The conversion from GML to SVG should happen on the fly, which requires speed. There is an XSLT compiler (XSLTC - http://xml.apache.org/xalan-j/) that compiles XSLT to Java bytecodes. The resulting translets [1] can be used in place of the original stylesheet, greatly improving conversion speed. However, the Cleopatra stylesheets use some Saxon XSLT extensions (http://saxon.soureforge.net). Saxon is an open source XSLT processor which will also handle some useful extensions to XSLT. These extensions are not part of XSLTC. An in-house developer with XSLTC experience estimated the task of adding these extensions as ~1 week.

cleopatra-map.png

Figure 1: Example output map

2. Navigation

Useful maps tend to be large relative to typical computer screen sizes, and they come at many different scales. Therefore zooming and panning are important user interface features of an online map. SVG has built-in zooming capabilities; however, the default zooming and panning behaviours in most SVG viewers are not ideally suited to map viewing. Firstly, some map components should not change under zoom and pan operations, like legends and UI controls. Secondly, it is helpful to provide some indication of view context: what region of the full map is represented by the current view. Scripting makes both of these things possible.

The Cleopatra SVG maps contain a key map, which is a small version of the main map with a superimposed rectangle describing the current view. Panning is achieved by dragging the view rectangle around the key map using the mouse. Zooming and additional panning controls are associated with the key map. During the conversion process, the key map and controls can be placed anywhere in the main map window. The controls can be described by any SVG file containing graphics with the correct id attributes. This file can be specified in the conversion settings XML file.

cleopatra-keymap.png

Figure 2: Keymap

The keymap, legends and controls should remain static as the user navigates through the map. The Adobe implementation of the SVG DOM doesn't contain the required coordinate and zoom level information for the zoom and pan event. Instead, calculations were done in the zoom/pan script. The script adjusts viewports and bounding boxes while tracking panning offsets and the zoom level.

cleopatra-controls.png

Figure 3: Zooming and panning controls

When the mouse hovers over the map, the user expects some indication of where the selected point is in a coordinate system they can understand, such as latitude/longitude. A script catches mouse move events and updates a coordinate display component on the map. The received events contain coordinates in the client window system. The SVG DOM has a method (getCTM) for this kind of transformation, but it is not implemented by the Adobe client. All the transformations need to be done in script, using the zoom level and panning offset stored by the zoom script.

3. Level of detail

From an end user's point of view, the map should provide exactly the required amount of detail. A user may not know in advance exactly what this level of detail is, or even what map coordinates they wish to view. Providing a high level of detail at a high zoom level throughout a large map requires prohibitive file sizes. Therefore there is a need to dynamically adapt level of detail to current viewing context. Level of detail is also a useful parameter to restrict for other reasons; e.g. an online map provider may wish to link it to the amount a user is willing to pay.

There are two major types of map generalization:

  1. number of features displayed depending on feature size
  2. line generalization - how many vertices can the user distinguish?

The Cleopatra stylesheets do a simple line generalization. Point values are rounded and duplicates discarded.

When a user requests a map, parameters describing the requested coordinates and level of detail are input to the conversion process. The original data source, or the XSLT conversion, or both can do any necessary generalization. It is preferable for the data source to output only the necessary GML for the end result. If the user chooses to zoom past a certain level, or pans out of the current map's boundaries, a new map will be requested from the server.

4. Styling

SVG is XML, and can be styled using Cascading Style Sheets (CSS). The same map can be presented to different users with different style sheets, providing a simple solution to the problem of accessibility. CSS identifies classes of elements in the SVG. We take advantage of this in the scripted implementation of interactive styling. The external stylesheet can be specified in the conversion parameters.

Interactive styling is, in a sense, another form of customization. A user can modify any SVG attributes through scripting, and potentially save their personalized settings for future use. The list of stylable features and their possible attribute values can be stored in the conversion settings XML file. For example:

<settings:styles>
    <settings:style id="fill">
        <settings:styleItem>blue</settings:styleItem>
        <settings:styleItem>red</settings:styleItem>
        <settings:styleItem>green</settings:styleItem>
        <settings:styleItem>black</settings:styleItem>
        <settings:styleItem>grey</settings:styleItem>
        <settings:styleItem>none</settings:styleItem>
    </settings:style>
    <settings:style id="opacity">
        <settings:styleItem>0</settings:styleItem>
        <settings:styleItem>0.25</settings:styleItem>
        <settings:styleItem>0.50</settings:styleItem>
        <settings:styleItem>0.75</settings:styleItem>
        <settings:styleItem>1</settings:styleItem>
    </settings:style>
</settings:styles>

<settings:stylableFeatures>
    <settings:stylableFeature>
        <settings:stylableFeatureName>Land</settings:stylableFeatureName>
        <settings:stylableFeatureStyle>visibility</settings:stylableFeatureStyle>
        <settings:stylableFeatureStyle>stroke</settings:stylableFeatureStyle>
        <settings:stylableFeatureStyle>stroke-width</settings:stylableFeatureStyle>
        <settings:stylableFeatureStyle>stroke-dasharray</settings:stylableFeatureStyle>
        <settings:stylableFeatureStyle>fill</settings:stylableFeatureStyle>
        <settings:stylableFeatureStyle>opacity</settings:stylableFeatureStyle>
    </settings:stylableFeature>
    <settings:stylableFeature>
        <settings:stylableFeatureName>Water</settings:stylableFeatureName>
        <settings:stylableFeatureStyle>visibility</settings:stylableFeatureStyle>
        <settings:stylableFeatureStyle>stroke</settings:stylableFeatureStyle>
        <settings:stylableFeatureStyle>fill</settings:stylableFeatureStyle>
        <settings:stylableFeatureStyle>opacity</settings:stylableFeatureStyle>
    </settings:stylableFeature>
</settings:stylableFeatures>

The Cleopatra demonstration implements interactive styling through Adobe's customizable context menu (right-click on map), which is exposed as an XML DOM. The styling script also updates the legend correspondingly.

cleopatra-styling.png

Figure 4: Interactive styling menu

cleopatra-legend.png

Figure 5: Legend

A major styling challenge is to have map symbols (e.g. terrain and height) stylable by CSS and easily changed through the same interactive styling as other features. The solution is to use SVG fonts.

5. Data analysis

The most useful information contained in GML is not necessarily spatial, but the data associated with spatial features. Any of this non-spatial data can be copied into SVG as metadata, and accessed through scripting. A click of the mouse can bring up, for example, population statistics or land values.

We can display this type of data, and we can provide simple analysis tools such as graphs and thematic mapping. Thematic mapping is the coloring of map features according to an associated value. The types of data associated with features and available for display and analysis can be stored in the conversion settings XML file. For example:

<settings:dataFeatures>
    <settings:dataFeature id="dataFeature:Buildings">
        <settings:dataFeatureName>Buildings</settings:dataFeatureName>
        <settings:dataFeatureOption label="Area value"
                                    option="calculatedAreaValue"
                                    scaleMin="0" scaleMax="100" />
    </settings:dataFeature>
    <settings:dataFeature id="dataFeature:Land">
        <settings:dataFeatureName>Land</settings:dataFeatureName>
        <settings:dataFeatureOption label="Area value"
                                    option="calculatedAreaValue"
                                    scaleMin="0" scaleMax="500" />
    </settings:dataFeature>
</settings:dataFeatures>

The Cleopatra demonstration displays metadata using a simple ECMAScript pop-up window containing HTML. A more advanced (and customizable) method would be to use an SVG fragment such as the legend as a template. Thematic mapping can be toggled on and off. If a user changes a style after applying thematic mapping, the previous styles are restored before the new style is applied.

cleopatra-analysis.png

Figure 6: Thematic mapping and data analysis

6. Online resources

http://www.schemasoft.com/cleopatra/index.shtml
Cleopatra GIS demonstration files are available for download here
http://www.w3.org
W3C - XML, XSLT, CSS, SVG standards
http://opengis.net/gml/01-029/GML2.html
GML v2.0 standard
http://www.opengis.org
OpenGIS Consortium, Inc.
http://saxon.sourceforge.net/
Saxon XSLT Processor project information and source code
http://www.ordsvy.gov.uk
UK Ordnance Survey
http://xml.apache.org/xalan-j/
XSLTC - XSLT processor that outputs Java bytecode

Footnotes

  1. A set of compiled Java classes which represent an XSLT transformation.

Acknowledgements

The author would like to acknowledge the team lead for this demonstration project, Darryl Fuller at SchemaSoft (http://www.schemasoft.com).

Bibliography

[CSS2]
Cascading Style Sheets, level 2, B. Bos, H. W. Lie, C. Lilley, I. Jacobs, W3C Recommendation, 12 May 1998. Available at http://www.w3.org/TR/REC-CSS2/.
[GML]
Geography Markup Language (GML) 2.0, S. Cox, A. Cuthbert, R. Lake, R. Martell, editors, OpenGIS Implementation Specification, 20 February 2001. Available at http://www.opengis.net/gml/01-029/GML2.html.
[SVG]
Scalable Vector Graphics (SVG) 1.0 Specification, J. Ferraiolo, editor, W3C Recommendation, 4 September 2001. Available at http://www.w3.org/TR/SVG/.
[XPath]
XML Path Language (XPath) Version 1.0, J. Clark, S. DeRose, editors, W3C Recommendation, 16 November 1999. Available at http://www.w3.org/TR/xpath.
[XSLT]
XSL Transformations (XSLT) Version 1.0, J. Clark, editor, W3C Recommendation, 16 November 1999. Available at http://www.w3.org/TR/xslt.
[XML]
Extensible Markup Language (XML) Version 1.0 (Second Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, editors, W3C Recommendation, 6 October 2000. Available at http://www.w3.org/TR/REC-xml.

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