GML support in software
Presented by Clemens Portele
Slides by Marcel Reuvers & Linda van den Brink
Courtesy of Wim van Berkel, TNO
27-5-2014
Ingrediënten voor slimme toepassingen
Main
question as starting point for testing of GML support
What’s the best exchange standard for distributing
the national large scale topography to software
suppliers?
That means:
The data has to be consumed by software without
any additional software development
Complexity model
It’s a complex model like the Inspire
models are too
30-1-2014
De samenhang der dingen
Exchange formats that were tested
Ingrediënten voor slimme toepassingen
•  CityGML ADE IMGeo
•  GML SF 3.2: Simplified schema of CityGML ADE,
based on OGC GML version 3.2.1 Simple
Features profile level 0
•  GML SF 3.1: Simplified schema of CityGML ADE,
based on OGC GML version 3.1.1 Simple
Features profile level 0
•  KML: OGC KML
Software that was tested (november 2013)
Ingrediënten voor slimme toepassingen
•
•
•
•
•
•
•
•
•
PostGIS 2.0
Quantum GIS 2.0
ESRI ArcGIS 10.2
Microstation v8
Bentley Map serie 3
AutoCAD Map 3D 2013
Mapinfo 12
Geomedia 2013
FME 2014 beta
Scope of testing
Ingrediënten voor slimme toepassingen
•  It was internal testing (without help of the
vendors)
•  The results are not for publication because this
means another test procedure. It was only for a
quick overview to decide which exchange format
has to be supported for distribution
Results
Ingrediënten voor slimme toepassingen
Software
IMGeo GML
GML SF 3.2
GML SF 3.1
KML
xxx
X
X
√
X
xxx
X
X
X
X
xxx
X
X
√
X
xxx
X
X
√
met support
√
xxx
X
X
X
√
xxx
X
X
√
√
xxx
√
X
√
√
xxx
√
√
√
X
xxx
√
√
√
X
When software could read and visualize the data the
test was succeeded. Even when software skipped arcs
or attributes, or when coordinates were not correct.
Conclusions and recommendations
Ingrediënten voor slimme toepassingen
•  GML 3.1.1 SF is well supported
•  Currently GML 3.2.1 and higher is badly
supported
•  Is it an idea to do an GML estafette to trigger the
software suppliers in supporting GML for Inspire
•  Is it an idea that Inspire promotes the use of SF
more
•  How can we get people to use spatial data? Does
the solution lie in other formats for geo-data
(GeoJSON, GeoPackage, …)
GML complexities
Presented by Clemens Portele
Slides by Linda van den Brink
Courtesy of Wim van Berkel, TNO
27-5-2014
Context §  IMBRO: information model for Dutch base
registry for soil, based on NEN 3610
§  Implemented in a SOA with WUS and ebMS
protocols
§  Code generation with java and .NET
§  Findings presented by Dutch Geological Survey
(TNO) to Geonovum recently
Circular dependencies between GML XSD’s Description
GML 3.2.1. has a number of circular dependencies
in between XSD’s. These circular dependencies
make it difficult to create an implementation.
Examples
Gml.xsd imports depcrecatedTypes.xsd,
deprecatedTypes.xsd imports gml.xsd
GML .xsd includes includes deprecated
Types .xsd Circular dependencies (con>nued) Work around
The deprecatedTypes.xsd requires adaptations. Instead
of importing gml.xsd in its entirety, the following imports
need to be included.
Envisioned solution
OpenGIS schemas will be adapted.
<include
<include
<include
<include
<include
<include
schemaLocation="dynamicFeature.xsd"/>
schemaLocation="topology.xsd"/>
schemaLocation="coverage.xsd"/>
schemaLocation="coordinateReferenceSystems.xsd"/>
schemaLocation="observation.xsd"/>
schemaLocation="temporalReferenceSystems.xsd"/>
GML is too complex §  Not limited to spatial objects; also defines
concepts for temporal objects, observations and
measurements, etc.
§  Not modularized > not straightforward to use
these concepts selectively
§  There are multiple realizations for some of these
concepts, e.g. observations also in O&M
GML is too complex (con>nued) Envisioned solution
Introduce a more modular approach to GML in
which each (group of) concept(s) is bound to its
own name space.
This assures for a more fine-grained control on
which concepts are used and ultimately leads to a
better usability of GML.