GEOSS Banner

2.2.2 : Data modeling needs & GML Formal definition of a data model is possible only when the changes are made in a centralized way Practical definition in GML application schemas GML application schemas from UML models ShapeChange setup UML model edition Automatically application schema generated by ShapeChange Generating a feature collection from the automatically generated application schema GML profiles Using Simple feature profile GML media type The axis order issue

<<Prev T.O.C.  Next>> Formal definition of a data model is possible only when the changes are made in a centralized way

The main format used in WFS is GML. GML requires a clear definition of the data model, as previously mentioned, it specifies the feature types and their properties. In this section of the tutorial we are going to use a very simple layer defining the position of 4 different pole locations that we have extracted from the "Atlas of the Cryosphere" web site (CSR record: The portal has the functionality of saving the data for a later use, and thus one can retrieve the desired layer in Shapefile or in GML format.


The shapefile format is downloaded in a ZIP file. The ZIP file contains 5 files.


As a classical GIS file, a shapefile is geospatial-centric which means that entities are encoded as point files whose positions are being binary encoded in a .shp file.


These points are linked to a separate table file that contains alphanumeric attributes in a .dbf file.


The shapefile is implicitly defining a data model. In this example, there is only one feature type, let’s call it PoleLocationType. This type has 3 properties: one geometric property and two thematic properties. The geometric one is expressed by a point coordinate, and the thematic ones are represented as a number (Id) and as a name (description).

A GML file is a text file that can be seen in an XML editor (such as XMLSpy). This tutorial assumes that you are familiar with XML; if this is not the case, we recommend you to get started with the course available in the W3C school tutorial at

This is how the position of the Geographic North Pole is expressed in GML.

<ogr:PoleLocation fid="F0">







<ogr:name>Geographic North Pole</ogr:name>

</ogr: PoleLocation >

In GML format, objects are represented in upper camel case (all words start by a capital letter) and properties in lower camel case (all words start by a capital letter except the first one). Objects are composed by property elements, which in turn can be described by objects. So that, GML alternates objects and properties and this is clearly identifiable by the alternated use of upper camel cases and lower camel cases (the original GML file does not follow this notation and thus, it has been altered in this example).

A very common way of encoding a complete GML file is to pack features into feature collections. A feature collection is a list of features. This XML fragment shows the whole feature collection.



<ogr:PoleLocation fid="F0">


<ogr:name>Geographic North Pole</ogr:name>




<ogr:PoleLocation fid="F1">


<ogr:name>Magnetic North Pole (2005)</ogr:name>




<ogr:PoleLocation fid="F2">


<ogr:name> Geomagnetic North Pole (2005)</ogr:name>




<ogr:PoleLocation fid="F3">


<ogr:name>North Pole of Inaccessibility</ogr:name>




<ogr:PoleLocation fid="F4">


<ogr:name> North Pole of Cold </ogr:name>




XML files can be validated to a XML schema (XSD) that ensures that a particular XML file only contains data types that are defined in the XML schema. GML uses this mechanism to define the data model in a GML application schema and thus, forcing GML files to strictly follow the expected data model. Practical definition in GML application schemas

Because of what it has just been explained, you must define your own data model as a GML application schema (or reuse a previously created data model) and connect your GML file to it. By creating your GML application schema, you also create you namespace. Please do not be scared by this last word; a namespace is only the group of elements and types that define your model. You will also need other preexisting namespaces like the GML namespace and the XML Schema instance namespace. It is now when things can get complicated. A namespace receives 3 different names in an XML file:

• A short name of typically 2 or 3 characters, which is used to qualify elements in XML.

• A long name in the form of a URI. This is a thing that resembles an http URL, but it is not. Since it is only a long name that uses the URL structure to be sure that it is unique in the whole world.

• The real URL position of the XSD file (or files) that defines the namespace.

To be practical, in the XML file, you could define a default namespace that has no short name and is generally assigned to the most used namespace (this is not the case in the following example).

The root elements of a typical GML file is FeatureCollection. To connect these elements to the right namespaces, you must use the attributes of this element:






In this GML file you have 3 namespaces:


long name (URI)



no needed


still unknown




Our own namespace is called "ogr" as the short name and as the long name, which can be found at: cryosphere_atlas_north_pole_location.xsd. This is the file that will define your namespace. The root element of your schema defines that the taretNamespace (the namespace that will be defined) is The first child element in root is the "import" element that sets the location for the gml namespace to a real URL:

<xs:schema xmlns:ogr=""
           elementFormDefault="qualified" version="1.0">

           <xs:import namespace=""

Now we are ready to define the Atlas of the Cryosphere North Pole Location data model. To do that we only have to define 2 data types: one data type for a FeatureCollection and another for features (these are called PoleLocations). This could be done in a simple way by using XML schema types, but it is not recommended, because we have to ensure both data types are derived from GML types, so instead we can use the geometric types that GML provides (particularly, we need gml:Point in our example).

The following UML class model illustrates how FeatureCollection (from the FeatureCollectionType) and PoleLocation (from PoleLocationType) are derived from GML types (which in turn are also derived from other more primitive GML types). GML types are represented in grey in the UML model illustrations.


This figure shows the inheritance model of the data types (classes and subclasses)

A FeatureCollectionType is a subclass of AbstractFeatureCollectionType which is a subclass of AbstractFeatureType that in turn is a subclass of AbstractGMLType. In practice this means that a FeatureCollection inherits all elements and attributes of the previous ones. PoleLocation becomes an element of FeatureCollection because it is a subclass of AbstractFeatureType, and a FeatureCollection is composed by a _Feature element or some element subclass of AbstractFeatureType type (such as PoleLocation).

PoleLocation has a Point element because it has a GeometryPropertyType element that has a _Geometry that has been subclassed to a PointType.

Fortunately, this inheritance mechanism happens automatically in XML, so the UML object model shows all attributes available for the 4 objects that are used in the definition of the feature collection.


This figure represents the feature instances of the types specified, as well as all the properties available from the different class dependencies nested.

The UML models presented here have been elaborated to illustrate the GML class dependencies and inheritance model. Latter we will present a simplified version of this model that is based on ISO types and on the way that this model can be automatically translated into XML.

XMLSpy offers us another view of the same model directly extracted from the XML Schema, so in this model more possibilities can be seen which are not shown in the UML diagram, although the main idea remains the same.


Now we are going to illustrate the process of translating manually a data model into a GML application schema. In order to do that, we have to do 4 things:

• Declare the root element FeatureCollection

• Define a type for the FeatureCollection

• Declare a PoleLocation element for our features

• Define a type for the PoleLocation

To declare the root element FeatureCollection is done by creating an element called substitutionGroup (subclass of) gml:_FeatureCollection.

<xs:element name="FeatureCollection" type="ogr:FeatureCollectionType"


The definition of a type for the FeatureCollection is done by extending gml:AbstractFeatureCollectionType. It adds to it a two additional attribute lockId and scope.

<xs:complexType name="FeatureCollectionType">


<xs:extension base="gml:AbstractFeatureCollectionType">

<xs:attribute name="lockId" type="xs:string" use="optional"/>

<xs:attribute name="scope" type="xs:string" use="optional"/>




The declaration of a PoleLocation element for our features is done by creating an element that is substitutionGroup (subclass of) gml:_Feature.

<xs:element name="PoleLocation" type="ogr:PoleLocationType"


To define a type for the PoleLocation is an essential step because it is going to define how our features will be (defines our feature types). It is done by defining a new type that extents gml:AbstractFeatureType.

<xs:complexType name="PoleLocationType">


<xs:extension base="gml:AbstractFeatureType">







The sequence of extended elements (and eventually attributes) define the properties of features (the only kind in this small example)

The first element added is a geometry property that uses a generic geometry property type: gml:GeometryPropertyType. This trick makes possible to use any of the generalized types of gml:GeometryPropertyType and particularly a gml:PointType (the one we are using). It is of best practice to directly use a type that adjusts best to our data model (i.e. gml:PointType in our case), but it is of common practice to use a more generic one such as gml:GeometryPropertyType

<xs:element name="geometryProperty"

type="gml:GeometryPropertyType" nillable="true"/>

Following the geometric element, we have two elements that are not GML types but common XML types (i.e. xs:integer and xs:string) restricted to follow convenient limitations:

<xs:element name="id" nillable="true" minOccurs="0">


<xs:restriction base="xs:integer">

<xs:totalDigits value="6"/>




<xs:element name="name"nillable="true" minOccurs="0">


<xs:restriction base="xs:string">

<xs:maxLength value="50"/>



</xs:element> GML application schemas from UML models

Many GML application schemas are elaborated directly in a XML editor like XMLSpy, but this requires the user to be XML proficiency. Another approach is to design them using ISO 19103 conformant UML model, and then the GML application schema can be created by following the rules given in the GML standard (Annex E of ISO 19136). In deed, conversion from simple UML models to GML application schemas is an important step to simplify the GML application schema creation. Some tools have automated the migration from UML to GML application schema, so one no longer has to worry about XML schemas. Fullmoon ( and and ShapeChange ( are two open source software solutions that partially automate the process.

FullMoon provides a more complete environment, but the process of preparing the environment is quite complicated (even if you use the setup wizard, you have to follow several additional steps), so it is only recommended for complex projects maintained by specialists (

ShapeChange is a Java based command line tool that has a manual setup process, which is not simple either, although it has a more limited number and clearer steps.

We are going to illustrate the use of ShapeChange v1.0rc to generate GML application schemas from UML models. ShapeChange setup

Shapechange requires Java, Xerces and Xalan.

• Java JDK can be obtained from
• Xerces 2 for java can be obtained from
• Xalan for java
In this example we have downloaded: jdk-6u20-windows-i586.exe, and Once you setup the java JDK using the setup wizard, you have to uncompress and and only copy the jar files to a new "endorsed" folder in your java "lib" folder (by default: "c:\Program Files\Java\jdk1.6.0_20\lib\endorsed" (some files are already duplicated in both zip files, and you just have to keep the newer one).


Then, you can proceed to install the ShapeChange tool by downloading it from and decompress it in a folder.
ShapeChange is prepared to generate GML 3.2 (ISO version) by default. In this example, we want to be compatible with WFS 1.1 and GML 3.1.1. These will require small modifications in the ShapeChange configuration. ShapeChange main configuration is stored in the ShapeChangeConfiguration.xml file from the "ShapeChange-1.0\config" folder. Actually, the file only contains pointers to three files that store respectively, aliases for UML stereotypes, URI namespaces and transformation mappings from UML attributes and types to GML elements. This file can be duplicated to support alternative configurations. In our case, we have cloned it to ShapeChangeConfigurationGML311.xml. Then we have edited it to point to two new configurations files:

<?xml version="1.0" encoding="UTF-8"?>

<ShapeChangeConfiguration xmlns:xi="" xmlns="http://www.interactive-instruments.d.../Configuration" xmlns:xsi="" xsi:schemaLocation="http://www.interactive-instruments.d.../Configuration ShapeChangeConfiguration.xsd">

<xi:include href="StandardAliases.xml"/>

<xi:include href="StandardNamespacesGML311.xml"/>

<xi:include href="StandardMapEntriesUML.xml"/>


StandardNamespacesGML311.xml was created by cloning StandardNamespaces.xml and editing the GML namespace to point to the 3.1.1.

<Namespace nsabr="gml" ns="" location=""/>

Also, StandardMapEntriesUML.xml was created by cloning StandardMapEntries.xml and introducing a new line for convenience.

<MapEntry type="String" xsdEncodingRules="iso19136_2007 iso19136_2007_ShapeChange_1.0_Extensions" xmlPropertyType="string" xmlType="string"/> UML model edition

We are going to create our UML model in Enterprise Architect v8.0. The UML model for our pole location example will look very simple, since we have only one feature type called PoleLocation with three properties.


In Enterprise Architect v8.0 we will create a new project and generate a Domain Model.


We will remove Class1, Class2 and Class3 classes that EA creates automatically as examples, and then we will open the Domain Object diagram. We will create a new class by dragging and dropping a class from the toolbox in the Domain Object diagram. This class will be named PoleLocation and will have a "featureType" stereotype (featureType is not on the stereotypes drop down list, and it needs to be typed in). As a language we will select and accept the dialog box.



Now we are going to add attributes to the class: The first one will be named geometryProperty and will have the GM_Point type (this will be a public scope attribute). ShapeChange uses the geographical feature datatypes defined in ISO 19107 and GM_Point is an ISO datatype for a point. You can find some of these type names in the freely available ISO_TC _211_Standards_Guide.pdf document, specifically, in Figure 4 _Geometry basic classes with specialization relations, as well as in the GML 3.1.1 specification, illustrated in Figure 13. You can also see the comprehensive list of supported geospatial ISO data types and their corresponding GML types in the StandardMapEntriesUML.xml file. The second attribute will be named "id" and it will be an Integer type. Finally, the third attribute will be named "name" and it will be a String type (theses types are on the Type drop down list). In the class diagram you will see:


At this point we are almost done; now, in order for the ShapeChange tool to work you just need to specify which package in the project is the application schema package (this step has to be done even if you have only one package). To do that, you have to mark this package as an "applicationSchema" stereotype.


Note that now a useful trick needs to be done for the ShapeChange to communicate with the XML abbreviated namespace, namespace URI and XSD filename. This is done by adding to the applicationSchema package the following tagged values:
















This is an important step (if you miss it, the ShapeChange will not produce the result) , which is not explained in the installing documentation that comes with the program. In a project with more than one package, it will result in more than one file. The RationalRose$ShapeChange tagged values have to be documented in the package that will become the main applicationSchema, and the RationalRose$UGAS values have to be included in all packages.
In this example, we are using the same values as the one in pole location original example.

image14.png Automatically application schema generated by ShapeChange

Let’s now explain how to export the UML model fromUML 1.3 (XMI 1.0) to an xml file (Project|ImportExport|Export Package to XM)


We will export the "PoleLocationXMI.xml" xmi file into the "input" directory of the ShapeChange setup.
Now we are going to execute the ShapeChange from the command line and from the "input" directory. Simply by typing:
"C:\Archivos de programa\Java\jdk1.6.0_20\bin\java"
-Djava.endorsed.dirs="C:\Archivos de programa\Java\jdk1.6.0_20\lib\endorsed"
-Xms128m -Xmx1024m
-jar "../bin/ShapeChange.jar"
-o "../result" -s -P -v 3.1 -D NONE -r DEBUG
-c "../config/ShapeChangeConfigurationGML311.xml"
-R "iso19136_2007_ShapeChange_1.0_Extensions" PoleLocationXMI.xml

The result will be stored in the "result" directory.
Using "-r DEBUG" will result in reporting the maximum level of the process information:

D Added tagged value 'version' for element with ID 'EAPK_C0C177F7_A154_44b4_BD1A_F3A9999E3678' with value: 1.0.
D Added tagged value 'version' for element with ID 'EAPK_C0C177F7_A154_44b4_BD1A_F3A9999E3678' with value: 1.0.
D Added tagged value 'xsdDocument' for element with ID 'EAPK_C0C177F7_A154_44b4_BD1A_F3A9999E3678' with value: PoleLocation.xsd.
D Added tagged value 'xmlns' for element with ID 'EAPK_C0C177F7_A154_44b4_BD1A_F3A9999E3678' with value: ogr.
D Added tagged value 'version' for element with ID 'EAPK_C0C177F7_A154_44b4_BD1A_F3A9999E3678' with value: 1.0.
D Added tagged value 'xmlns' for element with ID 'EAPK_C0C177F7_A154_44b4_BD1A_F3A9999E3678' with value: ogr.
D Added tagged value 'xsdDocument' for element with ID 'EAPK_C0C177F7_A154_44b4_BD1A_F3A9999E3678' with value: PoleLocation.xsd.
D Added tagged value 'targetNamespace' for element with ID 'EAPK_C0C177F7_A154_44b4_BD1A_F3A9999E3678' with value:
D Added tagged value 'xsdEncodingRule' for element with ID 'EAPK_C0C177F7_A154_44b4_BD1A_F3A9999E3678' with value: iso19136_2007.
D Added tagged value 'version' for element with ID 'EAID_15E40ACC_24C0_4c83_9380_81C311E8B73A' with value: 1.0.
D Added stereotype 'Application Schema' for element with ID 'EAPK_C0C177F7_A154_44b4_BD1A_F3A9999E3678'.
D Application schema found, package name: Domain Objects
D Added stereotype 'featureType' for element with ID 'EAID_15E40ACC_24C0_4c83_9380_81C311E8B73A'.
D The package with ID MX_EAID_C0C177F7_A154_44b4_BD1A_F3A9999E3678 and name 'EA
Model' was created. Namespace: .
D The package with ID EAPK_C0C177F7_A154_44b4_BD1A_F3A9999E3678 and name 'Domain
Objects' was created. Namespace:
D Processing Classes...
D The class with ID EAID_11111111_5487_4080_A7F4_41526CB0AA00 and name 'EARootCl
ass' was created.
D The property with ID eaxmiid2 and name 'geometricProperty' was created.
D The property with ID eaxmiid4 and name 'id' was created.
D The property with ID eaxmiid6 and name 'name' was created.
D The class with ID EAID_15E40ACC_24C0_4c83_9380_81C311E8B73A and name 'PoleLoca
tion' was created.
D The class with ID eaxmiid5 and name 'Integer' was created.
D The class with ID eaxmiid7 and name 'String' was created.
D The class with ID eaxmiid3 and name 'GM_Point' was created.
D Fixing Unknowns...
D Checking overloading. Class = Integer; current class = Integer.
D Checking overloading. Class = PoleLocation; current class = PoleLocation.
D Checking overloading. Class = String; current class = String.
D Checking overloading. Class = EARootClass; current class = EARootClass.
D Checking overloading. Class = GM_Point; current class = GM_Point.
D Generating XML Schema for application schema Domain Objects.
D Creating XSD document 'PoleLocation.xsd' for package Domain Objects.
D Processing class PoleLocation.
D Processing class 'PoleLocation', rule 'iso19136_2007'.
D Import to namespace '' added.
D Processing local properties of class PoleLocation.
D Found: gml:PointPropertyType - direct
D Found: integer - direct
D Found: string – direct

The resulting xml file is the GML application schema automatically generated from the UML application schema:

<?xml version="1.0" encoding="windows-1252"?>

<schema xmlns="" xmlns:gml="" xmlns:ogr="" targetNamespace="" elementFormDefault="qualified" version="1.0">

<import namespace=""


<!--XML Schema document created by ShapeChange-->

<element name="PoleLocation" type="ogr:PoleLocationType"


<complexType name="PoleLocationType">


<extension base="gml:AbstractFeatureType">


<element name="geometryProperty" type="gml:PointPropertyType"/>

<element name="id" type="integer"/>

<element name="name" type="string"/>





<complexType name="PoleLocationPropertyType">

<sequence minOccurs="0">

<element ref="ogr:PoleLocation"/>


<attributeGroup ref="gml:AssociationAttributeGroup"/>


</schema> Generating a feature collection from the automatically generated application schema.

A pole location GML file is a feature collection of PoleLocation elements. ShapeChange does not generate any Type for feature collections, but we can reuse an element that already exists in wfs schemas by specifying the location of both our application schema (PoleLocation.xsd) and the wfs schemas.
A GML file that includes a single GML point with the position of the geographic north pole (0.0 0.0) looks like this:

<?xml version="1.0" encoding="UTF-8"?>

<wfs:FeatureCollection xmlns="" xmlns:wfs="" xmlns:gml=""xmlns:xsi="" xsi:schemaLocation=" PoleLocation.xsd">


<PoleLocation gml:id="F0">



<gml:pos>0.0 0.0</gml:pos>




<name>Geographic North Pole</name>



</wfs:FeatureCollection> GML profiles

(This text is based on a blog from Ron Lake : and this list:
GML 3 includes a wide range of elements and data types in 0, 1, 2 and 3 dimension for geometric, topologic, temporary objects, coverages, CSRs, dictionaries, default styles, etc. GML xsd files are arranged in a modular fashion and you only need to import geometryBasic0D1D.xsd for different applications. Many people though, find GML 3.1 possibilities overwhelming and prefer a more limited subset of them. Generic GML profiles lower the entry bar facilitating the understanding of a GML and making it easier to apply and to be read by GML parsers (while improving interoperability). This ensures that the application schemas developed with these profiles, avoid loading components that will never be used. These profiles live in the GML namespaces ( and define restricted subsets of GML. In other words, any application schema that can be generated using a profile must also be a valid application schema with respect to the full GML specification. Examples of this kind of profiles are:

• A very simple GML Point Profile aimed at specification developers that have point geometric data but do not want to use the GML grammar.
• A simple GML for Simple Features profile aimed at supporting vector feature requests and transactions (e.g. to/from a WFS).
• A GML profile for GMJP2 (GML in JPEG 2000)
• A GML profile for RSS (discussed below)
Another kind of GML profile provides the basis for domain or community specific GML application schemas, which in turn support data interoperability within a community of interest. This profile incorporates new XML vocabularies defined using GML and which lives in an application-defined target namespace.
GML application schemas can be built on specific GML profiles or the full GML schema set can be used. Using Simple feature profile.

(This text is based on the blog from Ron Lake : and the simple features profile specification document OGC 10-100)
The GML Profile for Simple Features provides enough support for a wide range of vector feature objects. It includes:

[1] A reduced geometry model allowing 0d, 1d and 2d linear geometric objects (all based on linear interpolation) and the corresponding aggregated geometries (gml:MultiPoint, gml:MultiCurve, etc).
[2] A simplified feature model which can only be one level deep (in the general GML model, arbitrary nesting of features and feature properties is not permitted).
[3] All non-geometric properties must be XML Schema simple types – i.e. cannot contain nested elements.
[4] Remote property value references are used (xlink:href), just like in the main GML specification.
Since the profile aims to provide a simple entry point, it does not provide support for coverage, topology, observations, value objects (for real time sensor data), nor support for dynamic features.
Simple features profile defines three compliance levels called SF-0, SF-1, and SF-2.
Compliance level SF-0 limits the property types of both spatial and non-spatial properties. Non-spatial properties are limited to being one of the following common xml types: integer, measurement, date, boolean, binary, URI, character or real; and cardinality of non-spatial properties is limited to zero or one (not allowing more that one). Spatial properties are limited to being one of the following GML types: point, curve with linear and/or circular arc interpolation, planar surface, or aggregates thereof. In GML instance documents compliant with level SF-0, values for a particular property may be encoded inline or by-reference but not both. By-reference property values are only supported through the use of the type gml:ReferenceType (the more generalized GML property-type pattern allowing mixed inline and by-reference encoded property values within the same instance document is disallowed in this level).
Compliance level SF-1 supports everything in compliance level SF-0 but removes the restriction on value cardinality (allowing more that one occurrence of the same property per object) and allows user defined non-spatial property types to be used. As with compliance level SF-0, in GML instance documents compliant with level SF-1, values for a particular property may be encoded inline or by-reference but not both. By-reference property values are only supported through the use of the type gml:ReferenceType.
Finally, compliance level SF-2 essentially corresponds to the OGC Simple Features specification. There are no restrictions placed on non-spatial properties. Spatial properties, however, are limited to the set of geometric types supported by compliance levels SF-0 and SF-1. In instance documents, the restriction on remote or referenced geometric property values, found in compliance levels SF-0 and SF-1, is removed
Nonetheless, it supports a good variety of real world problems and it is quite useful. It is the right profile to convert a Shapefile (SHP) to GML data because Shapefiles have similar limitations. GML media type

When submitting a request to a service or when receiving a response from a service using a GML file, a GML media type format has to be specified. Previously, in OGC several notations where used for this particular media type (e.g. WFS 1.0 uses "GML2", WFS 1.1 uses ""text/xml; subtype=gml/3.1.1" and GML simple features profiles suggests text/xml; subtype=gml/3.1.1/sfgml).
All this notations have been set aside in favor of a standard media type "application/gml+xml" (OGC 09-144r1. This MIME type has been submitted to IETF for approval:, which it only has 2 optional parameters: "charset" and "version". For "version" only the major and the first minor version number are provided.
To refer to a particular GML version 3.2 you can use: "application/gml+xml; version=3.2". References to profile are no longer allowed. The axis order issue.

In the previous discussion we have ignored the coordinate reference system upon which the position of geospatial objects rely. In previous examples, we used a polar stereographic projection because data came from an arctic zone dataset. One of the most common geospatial reference systems is latitude/longitude in WGS84 (EPSG code database identifier: 4326). The reference system can be specified by adding an attribute to the gml:Point. (This notation for CRS names comes from the GML 3.1.1 standard examples and it is deprecated; currently OGC is recommending URIs instead of URNs) There is a known issue with the axis order interpretation in the EPSG:4326. OGC edited the document 08-038r5 ( to settle down this issue and to determine the axis order specified in the EPSG database in order to be adopted by all OGC standards. In practice, this means that EPSG:4326 shall be used in latitude/longitude ordering.
Unfortunately, many implementations of GML, as well as many layers continue following the reverse longitude-latitude ordering, this either could be explained because implementations where done before 08-038r5 or because they continue ignoring the OGC recommended standards. Some GML readers have the capability to specify a parameter to invert the coordinates ordering while reading it; this is just a transitory solution until implementations progressively adopt the axis order from the OGC policy.
For instance, the service CIESIN/SEDAC WFS Service (Center for International Earth Science Information Network (CIESIN), Columbia University; and NASA's Socioeconomic Data and Applications Center (SEDAC)) with CSR record has a feature type for IPCC assessment that can be obtained as a GML file with this URL: This dataset honors the axis order OGC policy and represent coordinates ordered latitude and longitude.


This is what happens if the client does not take into account the right axis ordering and supposes first longitude and then latitude:


<<Prev T.O.C.  Next>>


Files (0)

You must login to post a comment.