Closed nmtoken closed 5 years ago
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
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
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:
FYI we are working on GML -> GeoJSON conversion rule here : https://github.com/INSIDE-information-systems/WFS3/issues/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
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
Yes CRS:84 only (see https://github.com/INSIDE-information-systems/WFS3/issues/2)
@nmtoken @sgrellet Can this issue be close (or moved)?
I guess can be closed if we're not looking into any more alternate encodings at the moment
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:
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