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
Ingrediënten voor slimme toepassingen Exchange formats that were tested 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
Ingrediënten voor slimme toepassingen Software that was tested (november 2013) 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
Ingrediënten voor slimme toepassingen Scope of testing 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
Ingrediënten voor slimme toepassingen Results 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.
Ingrediënten voor slimme toepassingen Conclusions and recommendations 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 schemalocation="dynamicfeature.xsd"/> <include schemalocation="topology.xsd"/> <include schemalocation="coverage.xsd"/> <include schemalocation="coordinatereferencesystems.xsd"/> <include schemalocation="observation.xsd"/> <include 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.