GeoSciML-Lite

[nmtoken]

Simplified encoding example

Short description

GeoSciML Lite (previously called GeoSciML-Portrayal), is a simplification of parts of GeoSciML and Observations and Measurements (ISO 19156).

GeoSciML Lite conforms to the Level 0 of the Simple Features Profile for GML (OGC 10-100r, OGC 06-049).

The simple features profile supports only a limited subset of possible GML geometry types that may be used to describe feature geographic location and shape. For the purposes of GeoSciML simple features, these include GEO::Point, GEO::LineString, GEO::Curve, GEO::Polygon, GEO::Surface, GEO::MultiPoint, GEO::MultiCurve, GEO::MultiSurface and multi-geometry types consisting of collections of these base types.

There are seven GeoSciML-Lite views descibed in the 4.1 standard, these are: GeologicUnitView, ShearDisplacmentStructureView, ContactView, BoreholeView, SiteObservationView, GeologicSpecimenView, GeomorphologicUnitView.

UML model (HTML) for GeoSciML including Lite can be found at: http://www.geosciml.org/doc/geosciml/4.1/documentation/html/

Example instance

BoreholeView

The following services provide BoreholeView
WMS: http://resource.europe-geology.eu/service/wmsBorehole?service=WMS&request=GetCapabilities&
WFS: http://resource.europe-geology.eu/service/wmsBorehole?service=WFS&request=GetCapabilities&

Example request (GML):
http://mapsrefdev.brgm.fr/wxs/epos/epos_boreholeview?SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&TYPENAMES=ms:BoreholeView&STARTINDEX=2000&COUNT=100&SRSNAME=urn:ogc:def:crs:EPSG::4326&BBOX=52.5561761583996514,-22.26424005614752488,64.09903939032463427,-6.31379936534628783,urn:ogc:def:crs:EPSG::4326

Underlying (INSPIRE) conceptual model

OGC Geoscience Markup Language 4.1 (GeoSciML) ~ http://docs.opengeospatial.org/is/16-008/16-008.html

Purpose & use

Developed for both WMS and simple feature WFS to more readily show Geoscience data, using existing clients. The intention is to support interoperable map services, for which interoperability is based on a shared data schema and the use of standard vocabulary terms for basic type classification of contacts and faults, age of geologic units and faults, and lithology of geologic units.

For WMS attributes follow defined element names to allow construction of harmonized styles, or the construction of SLD on-the-fly by aware clients.

Services exist and are registered in the OneGeology portal, portal can do SLD re-portrayal for WMS declaring conformance (through keywords), for GeologicUnitView.

Used simplification rules

Lite properties are mapped to existing GeoSciML or O&M properties. Values from GeoSciML and O&M complex properties are converted into GML SF-0 valid basic types (OGC 10-100r2, Clause 8.4.4.1). Different transformations scenarios are possible:

• The GeoSciML property is already a basic type and the value is used as-is
• A representative element of the complex type is used. For example; only SWE::Category::value.
• The value is constructed from several fields merged into a single string.

Lite properties cardinalities are limited to 0..1, while GeoSciML properties are often multiple. The data provider must then either a) choose one representative value or b) aggregate from the collection of values a new value. Strings will generally be concatenated while numerical values might be averaged or processed in some way to produce a significant value. Some Lite properties are designed to represent explicitly one particular occurrence, such as GeologicUnitView::representativeOlderAge_uri, which is the oldest age. Others are more suggestive and require the judgement of the data provider, such as GeologicUnitView::representativeLithology_uri. When values are concatenated, they shall be human readable and using simple separators (e.g., commas).

Properties ending with “_uri” shall not have concatenated values. Those properties are designed to fulfill specific query and rendering use cases.

For each GeoSciML Lite view, a table provides the mapping between Lite and GeoSciML properties. The mapping is expressed in OCL syntax as a path from the base type of the view to the property where the value resides in GeoSciML.

Additional information

[sgrellet]

Static example of one 'ideal' instance served by the WFS server : https://forge.brgm.fr/svnrepository/epos/trunk/instances/BoreholeView.xml

Example WFS app schema query (the one above queries MapServer and not Geoserver) with a BBOX around Roma: http://resource.europe-geology.eu/service/wfsBorehole?service=wfs&version=2.0.2&request=GetFeature&typenames=gsmlp:BoreholeView&srsName=urn:ogc:def:crs:EPSG::4326&BBOX=41.3,11.7,43.5,14.0&count=10

[sgrellet]

INSPIRE 2017 conference presentation on how it is applied within EPOS Research Infrastructure EU Borehole Index : http://cnig.gouv.fr/wp-content/uploads/2017/10/EU_BoreholeIndex_Cipolloni_Grellet2.pdf

[nmtoken]

Example WFS app schema query (the one above queries MapServer and not Geoserver) with a BBOX around Roma: http://resource.europe-geology.eu/service/wfsBorehole?service=wfs&version=2.0.2&request=GetFeature&typenames=gsmlp:BoreholeView&srsName=urn:ogc:def:crs:EPSG::4326&BBOX=41.3,11.7,43.5,14.0&count=10

Getting response of type 'geoserver-GetFeature.application' which is an XML response. I see a JSON example would be:

https://epos.brgm-rec.fr/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=gsmlp:BoreholeView&srsName=urn:ogc:def:crs:EPSG::4326&BBOX=41.3,11.7,43.5,14.0&count=10&outputformat=json&

[sgrellet]

FYI we are working on GML -> GeoJSON conversion rule here : INSIDE-information-systems/OAPIF#6 to be included in Geoserver core. Gihub is not fully up to date as of today. I'll update the content (instances & al.) soon

[nmtoken]

Is this going to be strict GeoJSON i.e. only CRS:84 projection (no crs member) with re-projection of coordinates when specified in any other CRS in the GML?

That's what it should be

[sgrellet]

Yes CRS:84 only (see INSIDE-information-systems/OAPIF#2)

[nmtoken]

Will you use RFC7946 Layer Creation Option of GDAL, or build you own?

[michellutz]

@nmtoken @sgrellet Can this issue be close (or moved)?

[nmtoken]

I guess can be closed if we're not looking into any more alternate encodings at the moment