Roy Grønmo, Arne-Jørgen Berre, Ida Solheim, Hjørdis Hoff, Kim Lantz*
Roy.Gronmo|Arne.J.Berre|Ida.Solheim|Hjordis.Hoff@informatics.sintef.no
SINTEF Telecom and Informatics,
Kim.Lantz@gis.dk
*GIS Denmark
Emerging standards from ISO/TC 211 convey principles for building interoperable, distributed geographical information systems. Important building blocks are UML for specifying the conceptual schema and XML for implementation-neutral exchange of geodata models. By means of a model-based approach using UML, and corresponding mapping to
XML and service implementations, it is possible to provide a well-founded basis for interoperability. Essential parts of this methodology have been elaborated, tested and proven successful in the Esprit project DISGIS. The ISO/TC 211 principles are recommended as a general framework for building interoperable SDIs within a GSDI.
Interoperability – the ability of organisations, systems, information, technologies and infrastructures to operate together – is addressed heavily in different communities around the world. Component-based systems, plug-and-play solutions and distributed computing platforms (DCPs) are advocated by software vendors and required by customers.
This paper describes a successful example of applying the ISO/TC 211 ([1]) model-based approach for the purpose of achieving interoperability between Geographical Information
(GI) systems. The paper first introduces the challenges of interoperability (section 2) and then describes the ISO/TC 211 model-based approach around conceptual schema language, encoding and service architecture (section 3). Section 4 describes the interoperability framework used in the Esprit project DISGIS ([2]). The DISGIS framework applies the
ISO/TC 211 principles through its UML-to-XML approach ([3] [4]). Section 5 provides an evaluation of various XML encoding strategies. Section 6 presents a conclusion and plans for future work.
In the GI world today, there are several geodata models, interchange formats, communication mechanisms, operating systems, programming languages etc. Typical GI systems work as depicted in Figure 1, with a tight and rigid coupling between a client and its server. For selfcontained and limited usage within an organisation, traditional GI solutions may work well.
However, more widespread use of GI calls for interoperability on several levels.

Interoperability is defined as follows: "Two components X and Y can interoperate (are interoperable) if X can send requests S i
for services to Y, based on a mutual understanding of
S i
by X and Y and if Y can similarly return responses R i
to X." [5]
Client A Client B Client C
?
?
?
Internet / Intranet
?
Geodata
Server A
Geodata
Server B
Geodata
Server C
Figure 1 GSDI community of today
Various standardisation communities are addressing the challenge of interoperability. Also the geographical information domain has for several years been subject to standardisation efforts for the very purpose of interoperability – and with good reason. GI access, exchange and use have become crucial topics both within and between companies, local authorities, and nations. The OpenGIS Abstract Specification ([6]) by the Open GIS Consortium (OGC) is one attempt to standardise digital GI; another is the emerging 191xx family of standards from
ISO/TC 211 ([1]).
Work is going on to harmonise the GI models from ISO/TC 211 and OGC, e.g. the adoption of OGC’s OpenGIS Simple Features Specification for SQL by ISO/TC 211 ([7] [8]). ISO/TC
211 is addressing the GI problem area from a top-down perspective, using a UML modelbased approach. On the other hand, OGC is working from a bottom-up perspective, allowing for multiple implementation specifications, which currently have not been derived from one common, precise and implementation-neutral UML model. Right now, one crucial point for harmonisation is how to get the top-down and bottom-up approaches to meet. In order to achieve this goal: From one conceptual and implementation-neutral specification it shall be possible to have a well-defined mapping to implementation-specific specifications for various
platforms and implementation environments ([9]). This capability will make it possible to achieve a basis for interoperability across various environments and DCPs.
3.1
ISO/TC 211 Principles
The ISO/TC 211 technical committee is developing the ISO 191xx series of standards for geographic information/geomatics. The base series of standards is intended to be independent of any particular implementation environment or distributed computing platform (DCP). It is still intended to support implementation of the standards in different environments, and to support data and service interoperability between different environments.

Interoperability at different levels is needed to integrate enterprise systems. The different levels may be separated by the five viewpoints of ISO Reference Model-Open Distributed
Processing (RM-ODP) [10]: enterprise, information, computational, engineering and technology. ISO RM-ODP provides a framework for developing distributed systems. Each viewpoint is an abstraction of the system based on a specific set of concerns. Interoperability may be considered along all the five viewpoints. The main focus for ISO/TC 211 is on the technology independent computational and information viewpoints. The computational viewpoint focuses on service interfaces and interaction between different system components.
The information viewpoint focuses on the information model for geodata that is being maintained and processed by the components.
XML
DTD based
XML
Schema based
ISO 19118
Encoding and
Data Exchange
ISO 19103 UML Rules and guidelines
Proprietary
Binary
XML
DTD
Impl.-neutral
UML model
Mapping rules
COM
Spec.
XML Stream
R/W
Service
Implementations
Can be supported by code generation
CORBA
Spec.
J2EE
Spec.
XML Stream
R/W
XML Stream
R/W
ISO 19119 and future ISO implementation profiles
(OpenGIS etc)
SQL
Spec.
Figure 2 From implementation-neutral to implementation-specific specifications
The ISO/TC 211 models are implementation-neutral, meaning that the models are at a conceptual level and independent of implementation details of a particular environment or
DCP. Still it is precise enough to serve as a basis for further mapping to implementationspecific models.
Figure 2 illustrates the ISO/TC 211 approach from implementation-neutral models to XMLbased encoding and service implementations for various environments.
Implementation-neutral models are being described in UML according to the rules and guidelines in ISO 19103 Conceptual Schema Language ([11]). These models are mapped to an XML-based encoding format according to ISO 19118 Encoding ([12]). Implementationspecific models are created for target implementation environments and DCPs according to a mapping. The mapping describes how each construct of an implementation-neutral model is handled on the implementation-specific level. These principles are briefly described in the following sections.
3.2
The ISO 19103 UML Modelling Rules and Guidelines
ISO/TC 211 has decided to use UML (Unified Modelling Language) by OMG as the common language for describing the implementation-neutral models that are part of the ISO 191xx

series of standards. The reason for this decision is that the goal of ISO/TC 211 is to create a framework that supports:
• syntactic and technical interoperability,
• a basis for semantic interoperability,
• multiple interchange formats and
• multiple service implementations.
The ISO 19103 standard contains rules and guidelines for how to develop implementationneutral UML models. The ISO 19109 Rules for Application Schema defines a general feature model for representing geographic information.
3.3
The ISO 19118 XML Encoding
The models to be used for the ISO 19118 encoding are based on implementation-neutral UML models. It could also have been based on an implementation-specific specification of this model for a particular implementation environment, but it is assumed that more optimal encoding formats exists for the different environments, and that the native mechanisms within an environment will be used when it is known that all interaction will take place within that environment only.
The ISO 19118 encoding contains rules for how to map from the implementation-neutral
UML models to a corresponding representation of data according to these models in XML.
There are many possible alternative choices of XML formats that are able to transport data instances of the implementation-neutral UML model. Section 5.2 evaluates the ISO 19118 encoding approach against other GI XML encoding approaches.
3.4
The ISO 19119 Service Architecture
The goal of the evolving ISO 19119 service standard ([13]) is to establish a framework for specification of geospatial services, and to identify a set of services for further standardisation. In addition it defines how to map from implementation-neutral service models to implementation-specific service models for environments and DCPs such as COM,
CORBA, J2EE, EXPRESS/SDAI, SQL, etc. The goal is to be able to define implementationspecific profiles of the implementation-neutral models, ensuring that there is a well-defined mapping between these.
The reason for having support for different implementation platforms is that it is not possible for the whole world to agree upon one platform. The technological development is fast, and it is also important to preserve the value invested into developing domain models, and to ease a change of technology. This is the main reason why ISO/TC 211 is focusing on standardising on implementation-neutral models, with a precision sufficient for further mapping to implementation-specific environments and DCPs.
XML is introduced as a basis for an implementation-neutral exchange format. The XML format is derived from the definitions in the implementation-neutral UML models, and not from implementation-specific models. Thus it can be used when there is a need to achieve interoperability between various implementation environments, or within one environment if not a more optimised environment-specific encoding has been chosen.
For an implementation-specific specification to be a proper profile of an implementationneutral specification it is necessary to describe how types with their operations, attributes and

associations are mapped from the implementation-neutral to the implementation-specific specification.
Client A Client B Client C
Application
Layer
Client Mapping
Client Mapping Client Mapping
COM+
XML
Stream
CORBA
XML
Stream
J2EE
XML
Stream
Business
Layer
Internet / Intranet
Data
Layer
COM+
XML
Stream
Server Mapping
Simple Feature SQL
SQL DB
XML
Stream
CORBA
Server Mapping
ODMG OODB
J2EE
XML
Stream
Server Mapping
Proprietary DB
XML
Stream
XML
Exchange
files
FileStore
Figure 3 Supporting multiple implementation environments
Figure 3 shows a three-tier architecture that enables interoperability among different servers and different clients. The application layer involves the browser and editor clients that are offered to end-users. The business layer involves a model that is the basis for an interaction between the clients and the servers. The data layer involves stored representations of the information models, according to standardised storage representations, such as a SQL-profile for the implementation-neutral models, or it can be stored in proprietary database storage formats and data stored as flat files.
There are existing client applications and there are existing storage formats within the GSDI community. The responsibility of the business layer is to enable interoperability, that is communication among these heterogeneous servers and heterogeneous clients.
It is possible to use the specific communication infrastructures and representation forms provided by a specific implementation environment and DCP, but then the interactions are restricted to be within that environment. Figure 3 shows the direct communication within a
COM+, a CORBA and a J2EE environment within the business layer, as well as within database environments, such as SQL, on the data layer. Such interactions have been standardised by OGC (Open Geodata Corporation) for instance by the Simple Features specification for OLE/COM ([14]), CORBA ([15]) and SQL ([7]). These have, however, currently not been derived from a common implementation-neutral model, and are thus not directly interoperable with each other.
The ISO/TC 211 approach lends itself naturally to be supported by code generation, and the
DISGIS project has tried this out in practice, as will be described and discussed in chapter 4.
Code generation can be used to automate the process at different levels. Code generation may be used to implement the mapping from implementation-neutral model to implementationspecific models as well as implementing the implementation specific models to a specific environment. There are several general advantages of using code generation:

•
The implementation is documented by an always up-to-date model.
•
Domain experts can intercommunicate with the programmers through the specifications, and changes will automatically be incorporated in the implementation.
•
Much of the implementation can be automated, resulting in less manual work for the programmers.
•
Implementation logic is centralised by generic code resulting in faster development, consistency and easier maintenance. Each class may for instance have a copy() method which is generated by a single generic algorithm. The generic algorithm generates different copy() implementations for each class depending on the attributes and relations of the specific class.
•
The same naming conventions, documentation and programming techniques will be used throughout the implementation, thus making it consistent and easy to read.
•
Code generation removes the possibility of manual programming mistakes in all the generated parts. A mistake in the generated parts occurs globally, thus increasing the chance of discovering this mistake.
A good code-generation tool supports the software development life cycle and not only the initial generation. Within such a tool the UML models can be edited and new code will be generated without effecting or over-writing the manual parts.
Distributed Geographic Information Systems (DISGIS) ([2, 16, 17]) was an EC-supported
Esprit project with a focus on developing mechanisms for GIS interoperability, building on state-of-the-art technology from the distributed system domain, and applying the ISO/TC 211 model-based approach. The DISGIS interoperability approach is consequently based on the
ISO RM-ODP model for Open Distributed Processing, the usage of UML for model specification and the usage of XML and/or binary streaming for data exchange.
GISDK
AutoCad
Editor
NMA
FYSAK
Editor cl/map FW
DG MOD 4
DG API 4
DG CFW cl/map FW
DG MOD 4
DG API 4
DG CFW
<XML,Binary>
Sysdeco
Editor cl/map FW
DG MOD 4
DG API 4
DG CFW
<NMA TCP/IP, ..>
<XML,Binary>
DG CFW
DG API 4
DG Mod 4
GISDK server
<phys. com: sockets,CORBA, ..>
DG CFW
DG API 4
DG Mod 4
NMA Quadri ser
DG CFW
DG API 4
DG Mod 4
Sysdeco server
Coordinate
Transformation
server
Oracle ProC
Oracle 7.3
Quadri
Store
SQL/3
MapServer
Figure 4 final DISGIS pilots
Figure 4 shows the pilot configuration by the end of the project. The partners of the DISGIS consortium had 3 existing heterogeneous servers and 3 existing heterogeneous clients, using proprietary geodata models. The DISGIS project achieved interoperability between each of

the heterogeneous applications by following the principles of the ISO/TC 211 model-based approach.
Starting out with the principles of the ISO/TC 211 and OGC feature and geometry models, the project members agreed upon a common feature model and associated geometry types, and specified these by means of UML class diagrams. This initial, implementation-neutral UML model was then transformed by hand to a second UML model, specialised for implementation in C++. This second UML model is therefore called implementation specific. The project developed a code-generation tool that takes the (C++) implementation-specific model as input and produces C++ program code. DISGIS is extending the model-based approach to be model-driven by also generating parts of the implementations corresponding to the models.
The resulting common geodata model is called DG Mod (version 4) in Figure 4. The mapping framework prescribes to-way mappings between the common model and proprietary client/server models. The DISGIS API (DG API) is a service interface for feature access, query and update according to the ISO19119 service architecture. The communication between clients and servers is supported by a communication framework (DG CFW) that transparently supports service interaction on top of various transport protocols (currently sockets and CORBA, but others like DCOM may easily be added). The encoding of features being communicated between clients and servers has been done both as binary and XML format. A coordinate transformation server was successfully tried out as an example of a more pure processing service.
The DISGIS interoperability framework consists of the common UML models with corresponding C++ implementations for the common geodata model and feature access service, and a communication framework with transparent support for sockets and CORBA for interaction and transport of XML or binary streaming packages.
A set of modelling requirements was defined to ensure proper precision of the model. A set of mapping rules defined the transition from the C++ UML model to:
•
C++ implementation,
•
XML encoding and
• binary C++ encoding from Object Space.
A code-generation tool used the mapping rules to generate much of the C++ implementation and all of the encoding formats with streaming libraries (Figure 5).
C++ implementation
Figure 5 DISGIS - a model-driven development
The DISGIS mapping from UML to XML is different from the ISO/TC 211 encoding and
XMI DTD production rules, but together with binary encoding it demonstrates that encoding format and streaming support can be fully generated from the common UML model.

The strength of the DISGIS mapping from UML to XML encoding of data instances is easy mapping rules and a compact XML format. Though the XML encoding used in DISGIS has a few limitations.
•
An XML DTD/Schema is not explicitly created. This means better performance at the cost of some validation of the XML document.
•
It uses a fixed order of the XML attributes. This means better performance, but is not true to the XML 1.0 specification ([4]) from W3C. In DISGIS the import and export of XML was written by the same vendor utilising and ensuring the fixed attribute order.
•
It defines a precise mapping of the most common model structures (all that was needed to transport geodata in DISGIS), but not all possible model structures. It lacks secure support for list of strings, two-way relationships and multiple inheritance.
These limitations of DISGIS XML encoding can be fixed so that the DISGIS approach is an alternative in the general model case.
When designing a communication protocol, one must try to meet the following demands:
1) Flexibility: The possibility to use different implementation languages such as Java, C++ or other languages.
2) Efficiency: The volume of GIS data implies that efficiency both in terms of memory usage and execution time, have high priority when designing communication protocols. It is important to have efficient implementations of bulk data transfers in the distributed environment.
These two objectives are often conflicting – efficiency means low flexibility and vice versa.
DISGIS implemented two alternative streaming formats: XML encoding schema and C++ binary encoding schema from Object Space. The disadvantage of using XML instead of binary structures is the size and thereby the speed of the applications.
Extensive performance tests were made to compare the XML encoding to the binary C++ encoding. An important measurement of the tests was that the size of XML to binary C++ encoding ratio is between 1.62 and 1.66. This gives high expectations to the prospects of being able to use XML to communicate efficiently since the only real obstacle is the difference in size. Since this difference is less than a factor of two, we would expect that
XML could be used as a generic encoding format instead of using traditional binary formats which are dependent on a specific computer programming language or DCP. Also the experience from Internet development has shown that open, simple and flexible solutions are winning compared to more complex and specialised solutions with higher efficiency. Still the approach of generating streaming from the UML models allows also for the generation of optimised binary streaming for special situations.
The DISGIS Interoperability framework provides a basis for interoperability between different existing heterogeneous geodata servers and clients, through a mapping to a common geodata model and feature query, access and update service. The distributed communication framework enables the services to be supported for various communication protocols.
The results from the DISGIS project is now being used as the foundation for the next generation Norwegian National Geographic Infrastructure (NGIS), and is being developed further in that context.

XML is evolving to be the de-facto-standard for interchange formats. There is ongoing work in ISO/TC 211 and OGC for defining geodata encoding formats with XML. ISO/TC 211 suggests a UML model-based approach to defining XML formats instead of defining the
XML formats by hand. This section describes some of the main approaches that have been proposed for using XML in the GI domain and evaluates these against the ISO/TC 211 approach.
5.1
XML Metadata Interchange (XMI)
Object Management Group defines the XMI standard ([18]). XMI defines XML mapping rules that apply to several meta levels. The resulting XML formats encode meta models, models or data instances depending on the chosen meta level. Applying XMI DTD mapping rules on a GI UML model results in one and only one XML DTD. This XML DTD defines an
XML encoding format for representing geodata instances corresponding to the GI UML model. There are important reasons for using XMI:
•
XMI is the industry standard for mapping a UML model to an XML format.
•
Most UML tools announces recently released or future support of XMI ([19]).
There are two drawbacks that may prevent XMI’s popularity and its adoption in the market:
•
It is complex. The XMI specification requires some understanding of the OMG Meta
Object Facility (MOF) ([20]), which demands thinking in terms of high level abstractions.
•
The first specifications of XMI do not say that XMI may define an XML format for encoding data instances corresponding to UML models, even though it really does due to the generic capabilities of the MOF. Therefor it may be wrongly interpreted as only defining the encoding of models and metamodels.
5.2
ISO 19118 XML Encoding
The ISO 19118 ([12]) is currently based on the principles of the OMG XMI-standard for
XML-based model interchange, but has been optimised for dealing with data instances by using an alias-list mapping from long identifiers to shorter tags. The aliases associate each
XML element name with a shorter name or code. Using compact element names makes the
XML files more compact, so that data can be streamed more efficiently across the network.
These compact element names are introduced at the cost of human readability. Switching back and forth between compact element names and human-readable element names may be done by coming XML tools.
It is a goal of ISO/TC 211 to influence forthcoming versions of XMI to be more efficient for data instance representation. Ideally this should happen with the next major revision of XMI with the support of XML Schema.
5.3
SFXML/GML
OGC have started to standardise XML formats for encoding of geodata instances by introducing the drafts for Geography Markup Language (GML) [21] and Simple Feature
XML (SFXML) [22]. These are two partly overlapping XML formats for expressing OGC
Simple Feature data instances. GML is according to the OGC Simple Features for SQL.

SFXML is according to the OGC Simple Features for OLE/COM. These two implementationspecific specifications are based on the OGC abstract specification. The abstract specification is an implementation-neutral model. The transitions from the abstract specification to the implementation-specific specifications are hand-coded and do not follow well-defined mapping rules. The transitions from the implementation-specific specifications to XML formats are also coded by hand.
OGC Abstract Spec.
OGC SF Spec.
for CORBA
OGC SF Spec.
for SQL
OGC SF Spec.
for OLE/COM
Figure 6 OGC hand-codes XML specifications (GML/SFXML)
There are two major problems of defining the XML formats by hand:
•
Interoperability: Geodata encoded in one of the implementation-specific XML formats cannot be directly sent to the other OGC implementations.
•
Maintenance: The mapping from model to XML is done by hand and without welldefined, explicit rules. Therefor it is hard to maintain the XML format as the model change.
By using the ISO/TC 211 model-based approach UML tools can generate XML encoding format based on the abstract specification in UML, using the ISO 19118 UML to XML mapping. The implementation-specific UML models can also be generated from the abstract specification, but the mapping rules for each platform need to be specified. The challenge is to reach an abstract UML model that is both implementation-neutral and precise enough to be a basis for different automated platform mappings.
ISO/TC 211 prepares the ground for geographic information data and service interoperability.
A model-based approach using UML and XML is essential for making this work. UML is used to express the conceptual model. XML is used as a basis for implementation neutral data exchange, thereby supporting interoperability between different implementation environments. The principles of ISO/TC 211 can be summarised as follows:
1.
Agree on a common, precise and implementation-neutral UML model.

2.
Define mapping rules from the neutral model to different implementations, and follow these rules for defining standard implementation profiles. This can preferably be supported by a code-generation tool.
3.
Use encoding rules from UML to XML to support mapping to a common XML format based on the neutral UML model.
Some of the advantages are as follows:
• a consistent approach for defining various implementation and environment specific standard profiles
• ease of maintenance
−
yielding drastically reduced maintenance time and consistency when a new version of a standard is to be developed. The changes are initially defined on the implementation-neutral level and then propagated to the various implementation specific profiles
• support for both high performance implementation profiles taking advantage of the facilities in various implementation platforms, as well as support for interoperability between various implementation platforms and technical infrastructures
In the DISGIS project, essential parts of the ISO/TC 211 approach were tried out and found useful. This year the full approach is being carried out and tested in ongoing projects around the Norwegian NSDI. With respect to GSDI, the ISO/TC 211 approach should serve as a general interoperability framework for building compatible NSDIs. The first step will be to define the geodata models (ISO 19107) ([23]) and services (ISO 19119) that will be available through implementation neutral UML models, using the ISO 19103 standard, and corresponding ISO 19118 XML encoding, then to define appropriate service specifications.
The services should be made available through a global catalogue service, for instance based on the principles from the OpenGIS Catalog service ([24]). The main advantage of the UML model-based approach in this context is that it is possible to support different local implementations and representations of the same logical geodata models and services. It is also easy to migrate to new technologies as the implementation-neutral models remain stable with respect to technology changes, as for instance the assumed forthcoming change from
XML DTDs to XML Schema representation.
[1] www.statkart.no/isotc211
[2] www.disgis.com
[3] G. Booch, J. Rumbaugh, and I. Jacobsen, The Unified Modelling Language User
Guide: Addison-Wesley, 1999.
[4] W3C, “Extensible Markup Language 1.0”, World Wide Web Consortium February
1998.
[5] M. Brodie and S. Ceri, “On Intelligent and Cooperative Information Systems,”
International Journal of Intelligent and Cooperative Information Systems, pp. 1-35,
1992.
[6] OGC, “OpenGIS Abstract Specification”, Open GIS Consortium 1999.
[7] OGC, “OpenGIS Simple Features Specification for SQL Revision 1.1”, Open GIS
Consortium May 1999.
[8] ISO, “CD ISO 19125-1, Geographic information - Simple feature access - Part 1: SQL option”, ISO/TC 211 N 821, November 1999.
[9] T. Iversland, “UML as a common specification language for multi-platform domain standards demonstrated for the CORBA adn SQL platforms and the GIS domain.,” in

Faculty of Physics, Informatics and Mathematics. Trondheim.: Norwegian University of Technology and Science, 1999.
[10] ISO, “International Standard 10746-1 Open Distributed Processing- Reference
Model”, 1996.
[11] ISO, “CD 19103 Geographic information - Part 3: Conceptual schema language”,
ISO/TC 211 N 755, 1999.
[12] ISO, “CD 19118 Geographic information - Part 18: Encoding”, ISO/TC 211 N 709,
March 1999.
[13] ISO, “Geospatial Services (Working Draft 1.0) - CD version forthcoming, spring
2000”, ISO/TC 211 N043, February 2000.
[14] OGC, “OpenGIS Simple Features Specification for OLE/COM Revision 1.1”, Open
GIS Consortium May 1999.
[15] OGC, “OpenGIS Simple Features Specification for CORBA Revision 1.0”, Open GIS
Consortium March 1998.
[16] A.-J. Berre, R. Grønmo, H. Hoff, and K. Lantz, “DISGIS: An Interoperability
Framework for GIS - using UML and XML,” presented at 5th EC-GIS WORKSHOP,
Stresa, Italy, 1999.
[17] DISGIS, “DISGIS White Paper - Final version”, Distributed Geographical Information
Systems - Models, Methods, Tools and Frameworks. ESPRIT Project No. 22.084 June
1999.
[18] OMG, “XML Metadata Interchange (XMI) Version 1.1”, Object Management Group
OMG Document ad/99-10-02, October 25 1999.
[19] S. I. Brodsky, “XMI Opens Application Interchange”, IBM www-
4.ibm.com/software/ad/standards/xmiwhite0399.pdf, March 1999.
[20] OMG, “Meta Object Facility (MOF) Specification”, Object Management Group ad/97-08-14, September 1 1997.
[21] OGC, “Geography Markup Language (GML)”, Open GIS Consortium 1999.
[22] OGC, “Wep Map Server Interface Specification”, Open GIS Consortium 1999.
[23] ISO, “2. CD 19107, Geographic information - Part 7: Spatial Schema”, ISO/TC 211 N
818, November 1999.
[24] OGC, “OpenGIS Catalog Interface Implementation Specification (Version 1.0)”, Open
GIS Consortium May 1999.