Generating SVG From System Independent Conceptually Modeled Geodata

Prototype Implementation

Andreas Morf, Hans Rudolf Gnaegi
Institute for Geodesy and Photogrammetry
ETH Zürich

8093 Zurich
fax: ++41-1-6331101

Keywords: SVG; INTERLIS; GIS; Interoperability; Model Driven Approach; XML-Database


System independent conceptual data modeling provides an exact description of application data as well as of symbology elements needed for graphical presentation of geodata. The swiss standard SN612031 INTERLIS 2 supports this modeling process by means of an object-oriented conceptual schema language and an associated transfer service using XML. In addition INTERLIS 2 allows to link application data with symbologies based on the corresponding conceptual schemas. Our recent developments presentated in this paper show that the last step of the presentation process, namely the visualisation itself, can be achieved by applying standard open source software tools to conceptual models. The model-driven approach builds a consistent middleware bridge from geodata to their SVG presentation.

1. Introduction

The recent evolution of standards with focus to spatial data and the last OEEPE meeting of European mapping authorities showed a noticeable need for solutions with regard to following aspects:

In the following chapters we want to give an overview of the phases from an exact conceptual model to the (carto-) graphic presentation. We will also present the architecture of a prototype which was developed at our group. The resulting software is capable to transform geodata which correspond to the model-based approach defined by the INTERLIS-standard, to SVG [1].

Finally some conclusions and restrictions of the currently used technologies will be presented.

2. Model Driven Approach

2.1 Data Modeling Provides a Consistent Workflow

To treat application problems with GIS methods an abstraction process and its inverse are inevitable: Starting with real world objects one has - by abstraction - to arrive at data characterizing these real world objects. Only digital data can be treated, analyzed and presented by a GIS. The results are again digital data, lists, maps etc. These results need to be fitted to the real world objects - by interpretation, the inverse of the starting abstraction - to provide a basis for information, decision-making and finally modifying the real world, which has been the starting point [2].

Figure 1: From Reality to Data - Modeling Phases

The abstraction process from real world phenomena to data is called modeling. We base our modeling methodology on the so-called 4-phase (or 4-shell) concept (Fig. 1 and [3]).

Phase 1:
The spatial schema describes the reality selection (also called universe of discourse, abstract universe, nominal ground) - which is the part of the real world relevant to the application - and its systematic structure. Natural language may be used for this description.

Phase 2:
The conceptual schema (also called conceptual model) is created with classes, attributes, relationships and methods of the data objects, which correspond to the real world objects and their properties. A formal language is used to describe the data structure by means of a conceptual schema. Such a formal language is called conceptual schema language (CSL). A CSL can be either graphical or textual (lexical).

Phase 3:
The logical schema is the translation of the conceptual schema to the facilities of a dedicated application or GIS. The logical schema is necessary only for database creation (data definition language DDL like SQL). Language elements of the logical schema language are the building blocks for the database of a specific software. If a sequential transfer format (i.e. a file format) is created or if objects have to be serialized, there is only one logical decision concerning data fields, which has to be taken. Typically a decision has to be made whether data fields are fixed, free format or tagged.

Phase 4:
The physical schema (internal or external) is provided. In case of database creation the elements of the logical schema are mapped to internal data structures and pointers. Usually this step is automatically performed by the database-software. In case of sequential transfer format creation, no special logical schema is needed, as we have seen in phase 3. The classes and attributes of the conceptual schema can be directly mapped to the records and data fields of the sequential transfer format or to an interface definition. Such an interface definition allows to specify application programming interfaces (API) for the handling of serialized object streams. This can also be done automatically by appropriate software tools.

Modeling is not a new topic. It is stated by every GIS manufacturer that modeling is inevitable to apply its GIS [4] in a sustainable manner. But in this case modeling is done on the logical level of an adopted GIS and is heavily system-dependent, so that persons concerned with modeling often need to focus on specialties and fallacies of the used GIS. The system-neutral or system-independent modeling approach is new (i.e. the exact description of data on a conceptual level independent of any present-day GIS).

As our goal is to arrive at a graphical presentation of geo-data, we first need to export the data out of a GIS. The left side of figure 1 shows how the model driven approach is used for the data transfer.

Fig. 2: Sample UML schema of a small selection of reality

The conceptual phase starts with the Unified Modeling Language (UML) as a graphical conceptual schema language for creating an overview of classes, relationships and attributes. Figure 2 shows a simple general roads model with 5 classes: "Street" show associated classes "StreetNamePosition" and "StreetAxis". "LandCover" is a class of regions, covering a certain planar surface without overlaps and "PointObjects" contains interesting objects of point-type geometry. The specialized model "RoadsExtended" takes over all the classes of the model "Roads" but two classes are adopted to special needs by means of inheritance: "StreetAxisExtended" has an additional attribute "Precision" and for "PointObjectExtended" the "Type" attribute is extended in its detailing (this cannot be seen in the UML-schema but would appear in the complete textual conceptual schema). In addition to ordinary business data models, geometry plays a main role in geo-data modeling. In the presented methodology geometry is treated as an attribute of a class (e.g. "Position" for a location in class "PointObjerct" or "Geometry" for a line sequence in class "StreetAxis") like thematic attributes (e.g. "Name" in class "Street").

An important support to a modeling process is provided by UML-editors, which allow the generation of a conceptual schema in a textual form directly out of UML diagrams. This textual model at least contains the graphically defined subdivisions of the conceptual schema (classes, relationships and all defined names). Newer tools like the UML-editor of KOGIS [5] or the ili2rose add-on to the Rational Rose Modeler Edition [6] allow the definition of attribute types as well within the graphical schema and consequently the generated textual conceptual schema is supplemented with this information.

The main advantages of the textual conceptual schema languages are:

  Point2D = COORD 0.000 .. 200.000 [m]  !!min East, max East
                  0.000 .. 200.000 [m]  !!min North, max North
                  ROTATION 2 -> 1;
CLASS LandCover =
  Type: MANDATORY (building, street, water, OTHERS);
   VERTEX Point2D;
END LandCover;

CLASS PointObject =
  Type: MANDATORY (tree, geodetic_point, OTHERS);
  Position: MANDATORY Point2D;
END PointObject;

Code Example 1: Textual conceptual schema for a part of the UML-schema of figure 2

The description of the conceptual model with the INTERLIS language automatically generated out of the UML diagram in figure 2 is partially shown in figure 1 and in code example 1.

For code example 1 we have selected the two classes "LandCover" and "PointObject". To provide better legibility of the text an attribute type "Point2D" is introduced in the DOMAIN section to define 2-dimensional coordinates. It starts with the keyword COORD followed by the boundary interval for the coordinate values on the east and north axis. The length units follow in brackets ([m] for meter). Optionally the name and the axis numbers of the corresponding coordinate reference system may be added , which has been omitted here. The phrase 'ROTATION 1 -> 2' indicates, that directed angle measurement is done clockwise with 0-direction equal to northing. The two attributes of class "LandCover" are now specified in detail. "Type" is an enumeration attribute (or codelist) whose values can be directly stated in parenthesis. We distinguished between building, street and water. The keyword OTHERS allows to extend the enumeration horizontally. The "Geometry" of the land cover regions is treated as normal attribute of the class. The keyword SURFACE indicates that the objects of the class are regions, independently defined by their boundaries. VERTEX Point2D shows that the boundary vertices are of the coordinate type Point2D. 'WITH (STRAIGHTS)' denotes that only straight-line segments are allowed as connection type between two sequent vertices of the boundary. The "Type" attribute of the second class "PointObject" is an enumeration too and "Position" is of 2-dimensional predefined coordinate type "Point2d". For more details refer to the INTERLIS 2 Reference Manual [5].

XML has been chosen by the swiss standardisation commitee as transfer file format for INTERLIS 2 and - similar to ISO19118 [6] - encoding rules have been defined, i.e. how to (automatically) derive a transfer format for an application corresponding its underlying conceptual schema. This I-XML (INTERLIS-XML, see [5] chapter 3) encoding is one of four existing possibilities at the moment together with the ISO-encoding (of ISO19118), OGC's GML [8] and the Japanese GXML [7]. Due to the model-driven approach, a migration to another encoding may be easily achieved for INTERLIS 2, if necessary. The question only is, if rather format-based approaches like GXML or GML allow exchanging data which tap the full modeling potential provided by INTERLIS 2. The automatic deduction of the XML based data format is a key for the introduction of the SVG presentation layer and simplifies its implementation.

2.2 System Independent Symbology Modeling

The same 4-phase method used in chapter 2.1 to model data of an application may be used as well to model symbologies, which finally provides a basis for graphical presentation of data. Such a symbology model can be developed independently of any data and should be used to provide maps based on different models and corresponding data sets. From the point of view of a given data model, this data-independent definition of graphical elements allow introducing different symbology models for the same data model, e.g. for the presentation of the same data in different scales or thematic presentation. In this chapter we will show how a symbology model will be defined. Within the following chapter 2.3 it is explained, how the link between a data model and an appropriate symbology model is realized. The necessary support is also provided by the INTERLIS mechanism.

Phase 1 provides as reality selection for the symbology application a reference map and/or a list of needed symbols. To provide a presentation of our simple data model in chapter 2.1 we need the following point symbols: a circle for trees and a triangle for geodetic points. As line symbols we need a thick red line for precisely given street axes and a small dashed black line for imprecise street axes. For surfaces fill colors or hatch patterns are needed. In the following phases we concentrate on point symbols for simplicity.

Fig. 3: Conceptual Symbology Model (UML)

The first part of phase 2 (UML, conceptual graphical) provides a graphical overview of classes and relationships. Figure 3 shows the part of the UML diagram needed for the description of the point symbols. We again simplify supposing that every point symbol is only of linear type, but may be composed of different polylines (e.g. consists of two concentric circles). The lines used for the picture of our point-type symbols are described by the class "Symbol_Polyline", which points by directed associations to the classes "Color" and "PolylineAttrs" providing objects with color definitions and additional detail attributes respectively. The necessary lines are collected together by a composition association defined by the attribute "Symbol". If a "color"-object is referenced here by the attribute "ColorRef" - which is not compulsory, because "ColorRef" is not MANDATORY - all the "color"-objects possibly referenced by the lines of the composition are overridden. Furthermore two special remarks concerning the class "SymbolSigns" of our point-type symbols:

CLASS Symbol_Polyline = ColorRef : REFERENCE TO Color; !! nur fuer Symbole LineAttrs : REFERENCE TO PolylineAttrs;
END Symbol_Polyline;
Scale : 1 .. 2000000000;
Color : REFERENCE TO Color; !! overwrites colors from Symbol_Polyline
Symbol : LIST OF Symbol_Polyline;
PositionOfSymbol: MANDATORY SymbCoord;
Rotation : 0.000 .. 359.999 CIRCULAR [Angle_Degree]
COUNTERCLOCKWISE; !! default 0.000
Priority : MANDATORY 0 .. 9999;
END SymbolSign;

Code Example 2: Conceptual Model (INTERLIS 2, textual) of symbol classes

The second part of phase 2 (conceptual textual) provides the conceptual schema in INTERLIS 2 syntax with all the details for every element, especially the attribute definition. Code example 2 shows these details for the four classes of figure 3, where "METAOBJECT" and "SIGN" are predefined by INTERLIS 2 and "SymbolSigns" and "SymbolPolyline" are user-defined. Some new aspects of the conceptual schema language are obvious, e.g.:

- Geometric data type POLYLINE with straights, arcs and overlap condition
- The (ordered) composition attribute LIST OF
- The possibility to define angles as circular intervals
- PARAMETER definitions for detailed controlling of the occurrence of graphical elements at runtime

Phase 3 of our modeling process again is rather simple because have to treat the transfer service case again. Symbology data are needed so that they may be linked to application data. On the logical level the tranfer format has to be chosen. This is XML as stated above.

In phase 4 the INTERLIS 2 compiler derives the transfer format (physical schema, XML schema definition) out of the conceptual schema using the format deduction rules explained above. Finally the (meta-) data objects are stored in an I-XML-file providing a so-called symbol-library. The code example 3 shows the I-XML-code for the object called "circle" of the class "SymbolSigns" within the topic "Signs" of the model "Symbology".

 <Symbology.Signs.SymbolSigns TID="102">
<Name> Circle </Name> !! for Metaobject references
<Scale> 1 </Scale>
<Color> 5 <Color
<P C1="-0.5" C2="0.0" />
<A C1="0.0" C2="0.5" R="0.5" />
<P C1="0.5" C2="0.0" />
<A C1="0.0" C2="-0.5" R="0.5" />
<P C1="-0.5" C2="0.0" />

Code Example 3: Symbol library extract of a 'circle' symbol according to the small example

Circular arcs are encoded by adding a point near the middle of the arc (with <A /> as tag) between the two end-points of the arc (tagged with <P />). Now we have all the ingredients at disposition to define the symbolization rules (often called graphic description).

2.3 Linking Data and Symbologies

Within the concept of the INTERLIS mechanism the two independent models of data and symbology are linked to each other via symbolization instructions: symbols and styles out of the dedicated symbol library are assigned to every object of a class or view of the geodata model (cf. figure 4 and 5).

Fig. 4: Conceptual Workflow of the Symbolisation Process

Together with this symbol assignment the user defines - still on the conceptual level - for each selected symbol the necessary parameters (location, color etc.) according to the attributes of the data objects which shall be represented. This finally allows the generating software (in our case the SVG-generator) the production of graphic-objects to be displayed.

MODEL RoadsSymbolization (en) = !! Roads graphics
CONTRACT ISSUED BY Unknown; !! Contractor(s) have to be defined!
IMPORTS RoadsModel;
IMPORTS Symbology;
SIGN BASKET SymbologyBsk ~ Symbology.Signs; TOPIC Graphics = DEPENDS ON RoadsModel.Roads;
!! Text_,Surface_ and Line_Graphics omitted
GRAPHIC Point_Graphics
BASED ON RoadsModel.Roads.PointObject =
Circle OF Symbology.Signs.SymbolSign:
WHERE Type == #tree (
Sign := Circle;
PositionOfSymbol := Position;
Priority := 130);
Triangle OF Symbology.Signs.SymbolSign:
WHERE Type == #geodetic_point (
Sign := Triangle;
PositionOfSymbol := Position;
Priority := 130);
END Point_Graphics;
END Graphics;
END RoadsSymbolization.

Code example 4: Graphic description joins data and symbology model

Whereas the full initial and closing statements of the INTERLIS 2 model for symbolization of the small roads example are given by code example 4, the details of the presentation definition are shown only for the the class "PointObject". A full example also dealing with texts, surfaces and lines is included in annex C of the INTERLIS 2 reference manual [5].

As code example 4 shows, the symbolization description starts like an ordinary INTERLIS 2 model with the keyword MODEL followed by the model-name. The next line with the keywords CONTRACT ISSUED BY shows, that symbolization is not part of the INTERLIS 2 kernel, which has to be realized by every INTERLIS 2 processor. The next two lines refer to the model-names of the two components needed to define symbolization, the description of the structure of the geodata on one side (RoadsModel) and of the symbology data on the other side (Symbology). By the next line SIGN BASKET is given the identification (SymbologyBsk) of the container or basket with the data for the symbols of the interesting symbology topic (Symbology.Signs). This basket depicts the symbol-library and refers to a part of an XML document containing corresponding symbologies..

The TOPIC keyword indicates the beginnig of a symbolization description topic called "Graphics" linked to the topic "RoadsModel.Roads" by means of the keywords 'DEPENDS ON'. A symbolization topic is a sequence of presentation-definitions starting each with the keyword GRAPHIC and providing one or more drawing-rules for one class, whose identification is given after the keywords BASED ON. As a small example, the presentation-definition called "Point_Graphics" is shown for the class "PointObjects" of the topic "Roads" in the data model "RoadsModel". The first drawing-rule of "PointGraphics" assigns the symbol-object with name "Circle" to a data-object of the class "PointObject", if its attribute "Type" contains the value "tree". If such a data-object has been found, the parameters for the symbol-object have to be defined according to the attribute-values of the data-object: The symbol-name (attribute "Sign"), which has to be searched in the basket of symbol-objects, becomes the value "Circle", the "PositionOfSymbol" takes over the value of the data-attribute "Position" (coordinate) and finally, the parameter "Priority" is set to 130. The data-object, whose "Type" equals "geodetic_point" is handled the same way.

3. Architecture of the Prototype Implementation

In the following chapters we want to provide an overview about the prototype implementation. The concept of our model driven SVG generator will be presented and the interaction between the different components and adopted software tools is explained.

3.1 Design Overview

The rather complex workflow which had to be worked out to retrieve the visual results has leaded us to the following architecture:

Fig. 5: Software Architecture

3.2 Adopted Software-Tools

3.2.1 Selection of software components

Due to the fact that the processes of our framework are rather complex, we decided to employ available components. The programming effort and therefore time cost can be drastically cut. Another aspect is the stability of the resulting software which is much better if one reverts to widely tested and stable modules.

The development of open source software and APIs around the core XML technology upon which the INTERLIS transfer format relies induced us to focus on the well known projects of the Apache Software Foundation [10, 13]. Within the large palette of tools the following were chosen:

Table 1: Adopted Software Tools and API's.
Product-Name Description
Xerces V1.4.3 [13] XML-Parser/Processor
Batik V1.5beta3 [16] Java Toolkit for SVG Solutions
Xinidice V1.0 [10] native XML Database


The transformation of the textual description of the conceptual data model imposed one of the first problems to solve. Several solutions for parsing formalised languages which follow a well defined grammer were looked at. The properties of the ANTLR parser generator framework quite optimally fitted our needs.

The following paragraphs provide a short overview of these components and libraries:

3.2.2 ANTLR Parser Generator [9]

Based on the well defined grammar of INTERLIS it is possible to implement a parser which translates a data model to a machine readable structure, a so called abstract syntax tree (AST). All elements of a datamodel are mapped to nodes of the tree whereas the type of the nodes follow the meta-model of the INTERLIS-Language. These nodes are hierarchically linked and form a tree:


Fig. 6: AST-View of a Geodata Model

For our project we decided to use the open source parser generator 'ANTLR' [9] as a tool to implement an INTERLIS language parser. The meta-language of the parser generator provides a very flexible approach for defining AST's which simplifie the handling of tasks in most domains. One feature to mention at this place is the possibility to specialize the class of a tree node which allows you to introduce properties as needed to store all necessary metadata given by the (geo)data-model. Among a large variety of features ANTLR supports extended BNF notation, syntactic and semantic predicates. A short code fragment of a shows the implementation of a grammar rule:

graphicDef!          // rule name
// define available properties of a graphic definition
{ String[] str_prop = {"ABSTRACT", "FINAL"}; }
( pr:properties[str_prop] )?
( extds:EXTENDS grref:generalRef[ref_graphic] )?
( BASED "ON" vref:generalRef[ref_view] )?
( (selectionDefs)=>sel:selectionDefs )?
( (signAttributeDefs)=>signattr:signAttributeDefs )?
END b:IDENT { b.getText().equals(grname.getText()) }?
SEMI // construct a new AST node for a graphic definition
{ ## = #([GRAPHIC, grname.getText()], #([PROPERTIES, "PROPERTIES"], pr), #([EXTENDS, "EXTENDS"], grref), #([BASED, "BASED ON"], vref), sel, signattr); };

Code example 5: Sample Grammar Rule for the Recognition of Graphic Definitions

Once built, an AST may be serialized to an XML document and therefore stored to disk or an XML-database as we will see later.

For the evaluation of the syntax tree or parts of it the meta-language of ANTLR is equipped with elements for the construction of a so called tree parser. To perform the desired tasks during a traversal of the AST, actions are insertet within the grammar rules. This is done by means of small java code fragments.

3.2.3 Xindice: native XML database [10]

Apache Xindice is a database designed from the gound up to store XML data and indexes in order to provide that data to a client application. So if we are dealing with geodata according an INTERLIS data model or an SVG documents it was obvious to exert this technology. In a second stage of the project especially the handling of large geodatasets will be contemplated and instead of writing new code for handling large XML documents a database system is more convenient.

At the present time Xindice uses XPath [11] as query language and XML:DB XUpdate [12] as its update language. XPath is the W3C's XML pathing language, and is a very powerful way of selecting sets of nodes from documents in a collection. This is well suited to get direct access to geo-objects within a large dataset.

3.2.4 Xerces Java Parser [13]

As we are able to retrieve small XML documents containig geo-objects out of the database by query, the processing of these documents is easily done by a DOM parser. This allows accessing the contents in a tree manner and is well suited for handling hierarchical structured data according the encoding rules of INTERLIS. We decided to use the java version of the Xerces XML parser framework which is also a basic component of the Xindice database. Due to the fact that Xindice uses the 1.4 version of the parser we decided not to deploy the recently released 2.0 version of Xerces. The restrictions are the lack of handling namespaces and XML-schema but as we are assuming valid and consistent XML-geodata this is not an essential factor for the prototype.

4. Application Architecture

To introduce the steps of the visualisation process a general overview over the main tasks is depicted in the following flow diagram:

Fig. 7: General processing schema of the prototype software

4.1 Creating Graphic Objects and Data Structures

For each symbolisation definition whithin a graphic definition of a conceptual model an instance or object respectively of the graphic class is built. Such an object comprises a container where properties for symbolisation is stored. For the symbol 'Circle' in code example 4, an entry in the symbol container is created. The according properties, constraints and parameters are also stored within.

4.2 Querying Symbologies

In the code example 4 which represents an INTERLIS graphic definition, the attribute 'Sign' points to metaobject 'Circle'. These value represents a symbol definition which is available within the symbology document stored in the XML database. Code example 3 shows a fragment of a symbology stored within a collection in the database.

To retrieve the symbol definition from Xindice a query has to be built in the form of an XPath expression:

// query 'Circle'-symbol:
xpath = "/DATASECTION/child::Symbology.Signs.SymbolSigns \

Code example 6: Sample XPath Statement

A tiny document with the root element named 'Symbology.Signs.SymbolSigns' where the child element 'Name' contains a text node containing 'Circle' is deliverd by the query engine of Xindice.

Due to the object-oriented structure of the conceptual model it is not possible to get all required information as a result of a single query. The 'Color' and 'Symbol' elements are references to other entities of the model. Therefore the implemented processes had to be fully parametrised with respect to polymorphism, refereces and associations in complex data models in order to aquire available information about a single symbol.

4.3 Processing and storing symbol information

The resulting object of a query can be accessed in two ways: it is possible to get a content handler to process the document via a SAX-parser [15] or one might get a DOM-tree of the queried elements. Becaus of the relatively small size of the delivered geo-object or symbol the handling via DOM [14] interface is well suited and reflects the hierarchical structure of conceptually modeled geodata.

After gathering the whole definition of all symbols its drawing sequence and style can be serialized as <defs>-section to the beginning of the SVG document. The same procedure is performed to define line, text and fill styles.

As a next step, all parameters which reference to an attribute of the geodata model are determined (cf. 'Position' in the previous example). Values of these parameters are instated during the visualisation process of the geo-objects. The remainig parameters are set to their assigned values of the graphic model or a default value respectively..

4.4 Querying Geo Objects

The 'BASED ON' and 'WHERE' clauses of an INTERLIS Graphic (Code example 6) provide the necessary information to query the database after the demanded geo objects. The 'Geometry' parameter acts as key to visualize the geo-object at the right position. The assigned value depicts the element where geometry information is stored within the XML encoded data. Possible types are: points, polylines and polygons. Area topologies first have to be transformed to polygons or path compounds: this can be achieved with the use of a view upon an entity containig such a geometry type.

Due to the potentially large amount of accessed geo-objects it was decided not to read the whole information into memory. So if a class of the geodata model has to be visualized the corresponding graphic objects with according 'BASED ON' clauses are evaluated and processed. Therefore the XPath mechanism which allows direct access even to single geo objects is well suited for this task. The results of these queries which are sets of geo objects are handled sequentially with an iterator mechanism and the transformation to SVG output is done immediately. This procedure is implemented as a serialisation method of the graphic class in java.

4.5 Symbolisation Process

Due to the fact that there is no well established standard which lays down the basic way of symbolisation, the INTERLIS designers invented a symbology model as an extension to the basic INTERLIS mechanism. So an implementation has to hardcode the rules which are used to generate specific elements of the output format like filling, stroking, font handling etc. This step is comparable to furnishing a conceptual model for an application domain like traffic networks and the specialized GIS software is required to handle the associated data according to its sense. For example a visualisation processor has to know where to get the information about coloring the objects. Therefore the name and attributes of the corresponding class have to be acquainted to the processor. It is hardly possible for the same software to handle another symbology model without a semantic transformation of the model and its symbologies.

5. Application design

A very important point at the beginning of the project was to create a modular architecture of the resulting application. Among other benefits, it is important for our group an other interested institutions to get a tool kit for handling problems related to the new INTERLIS 2 standard.

The previously introduces modules will be integrated as a internet service. A potential user should be able to query the system for data sets already stored in the database. As an alternative, facilities for uploading of geodata will be implemented. Obviously the aim in this context will be the server-side generation of the requested SVG presentation. In this sense the development results in a dedicated mapserver.

6. Assets and drawbacks

The main intent of INTERLIS was to provide means to model and transfer vector data between GI-Systems. So one of the main disadvantages results in the missing of datatypes for raster data which also could be integrated to an SVG presentation. This point is subject to discussion within the concerned standardisation authorities and is scheduled as proposal for integration into a future release of the INTERLIS mechanism.

When dealing with geodata its is inevitable to provide an architecture which is capable to handle very large data sets (>10MB). The transfer and storage of very large XML documents poses a problem for current XML databases. As we are not yet in the benchmarking phase, it is to early to make a general statement at the moment. One solution to this problem is to divide the original data set in smaller sections, which, due to the 'fine-grained' and well structured manner of geodata, should be feasible.


The recently released INTERLIS 2 standard introduces a new methodology to model symbolisation issues on a conceptual level. This facilitates the implementation of data presentation services. Based on the data transfer service of INTERLIS and its encoding rules a prototype implementation is currently undertaken to ascertain the usability of the approach. SVG was chosen as a semi-interactive presentation format. INTERLIS and SVG both use XML as a common base of data transfer which simplifies the implementation of dedicated software modules. The availability of stable tools and API's focussing on XML accelerates the development process of services handling with geodata.


[1] "SVG - Scalable Vector Graphics 1.0", W3C Recommendation, . September 2001. Available at

[2] "Data modeling - chapter 1 of the course documentation INTERLIS basics", Bruno Späni, 2002. ETH Zurich, Institute for geodesy and photogrammetry.

[3] "Introduction to spatial information systems" - course documentation, Alessandro Carosio, 2001. ETH Zurich, Institute for geodesy and photogrammetry.

[4] "Modeling our world. The ESRI Guide to Geodatabase Design", Michael Zeiler, 1999. ESRI, Redlands Ca, USA.

[5] "INTERLIS 2 Reference Manual", J. Dorfschmid et. al., 1 October 2001. Available at KOGIS, "

[6] "ISO/TC211 CD19118 - Geographic Information Encoding". Document N1136, 20 September 2001, NTS Oslo

[7] "G-XML Specification 2.0", 25 August 2001, DPC Tokyo, Available at

[8] "GML - Geography Markup Language V2.0", OpenGIS Consortium, 20 February 2001, OGC Document Number 01-029, Available at

[9] "ANTLR - complete language translation solutions", Terence Parr, February 1992. Available at

[10] "Xindice - Native XML Database", Apache Software Foundation, December 2001. Available at

[11] "XPath - XML Path Language 1.0", W3C Recommendation, 16 September 1999. Available at

[12] "XUpdate: XML Update Language", Initiative for XML Databases, September 2000. Available at

[13] "Xerces Java Parser", Apache Software Foundation, November 1999. Available at

[14] "Document Object Model (DOM)", W3C Architecture Domain, 2001. Available at

[15] "Simple API for XML (SAX)", David Megginson et. al., May 1998. Available at

[16] "Batik - Java Toolkit for SVG solutions", Apache Software Foundation, 2000. Available at

Valid XHTML 1.0!