The publication of INSPIRE data sets in the environmental domain usually involves the exposition of real world features, observation generated by monitoring activities and the associated codeLists.
This activity involves mapping the source of the data, for example a database, to the target schema(s).
The INSPIRE recommended pattern involves OGC WFS service in its version 2 and SOS.
Then some software, for example GeoServer App-Schema, are responsible to understand those mappings and produce the final GML document as well to support querying on those GML documents.
After INSPIRE data sets have been published and used in real applications, some common requirements have started to emerge:
GML is very powerful, but more wildly supported and web developper friendly formats, like JSON (and it's derivated), would be preferred, specially when building Web applications.
Querying the data should be fast, the software in the middle needs to be able to bring the query computation to the original data source.
Recent OGC APIs work is following an interesting approach: JSON has the core format, REST like API and basically build on top of modern Web technologies.
Core example are WFS 3.0 and Sensorthings API.
BRGM has been caring on some experiments, deploying these APIs on top of its Ground Water Information System (GIN) Linking those data as much as possible. Also taking into account recent OGC work on this aspect in its Environmental Linked Features Interoperability Experiment - and follow-up IE (ELFIE & SELFIE).
This shift to modern Web technologies and JSON like formats bring several challenges and raise several questions:
Should existing solutions keep using GML as first class citizen and in some way be blend to support JSON outputs on top of the GML?
In the past years, a lot of efforts have been put in the definition of GML schemas, shoudl this work be completely throw away and pure JSON or JSON-LD models be created?
Is the current tendency, which is an automatic translation from GML to JSON like structures realistic?
What could be the optimal mappings support format that would allow the definition of the mappings between several data sources (PostgreSQL, Solr, MongoDB, ...) and atgret output format (GML, JSON, JSON-LD, etc ...).
How will the answers to the questions above impact the querying capabilities of WFS 3.0?
Required knowledge and skills
Data modelling and data management skills
INSPIRE data sets mappings publishing skills
Knowledge of OGC standards especially on WFS 3.0 and SensorThings API Part 1
Knowledge of JSON based formats: GeoJSON and JSON-LD
Offered datasets
Borehole/Wells, ground water monitoring facility (Piezometer), Timeseries observation, Hydrogeological unit
Associated codeLists exposed according to INSPIRE register federation practices
Geographical coverage : France
Temporal coverage : some Timeseries go way back in time
Other relevant datasets
Datasets provided by someone else that you know may be relevant for your challenge
Access details
New technologies to test or evaluate
GeoServer JSON and JSON-LD support
OGC WFS 3.0 work
OGC SensorThings API Part 1
Offered personal resources
INSPIRE expertise
OGC expertise
Linkeddata expertise
In-depth knowledge of the service stack deployed
In-depth knowledge of the datasets exposed
GeoSolutions expertise on GeoServer and App-Schema (max 1 day per week during September)
Offered or suggested tools
QGIS GMLAS toolbox pluging could be an interesting GIS desktop way to access this
GeoServer and App-Schema
Desired outcome and presentation
Consuming this web of ground water data and generate news apps, knowledge, ideas from it.
Offered benefits for the teams
Besides learning what can you offer to the teams that participate in your challenge?
Can you provide access to interesting data that's normally not publicly available?
Are you able to award the winning team with money, vouchers, gifts, etc.?
Background & context
Monitoring of the groundwater resource is key in a climate change context
New paradigm to expose linked environmental datasets using modern OGC APIs while keeping INSPIRE compliancy as much as possible
BRGM GIN has been used in FOSS4G-EU events : on SOS (52N workshops), QGIS GMLAS workshop and OsGeoLive
Cooperation with other Challenge Partners
In order to create 3 to 4 high-quality final challenges, the organisers may suggest that some of the partners submit a combined final challenge.
Are you interested in hosting your challenge together with one or more of the other challenge partners or submitting a common proposal?
Yes
If requested, are you able to provide access to your offered datasets, APIs or tools for a challenge proposed by another submitter?
Yes, after impact/workload evaluation
Submitting organisations
DataCove : Kathi Schleidt kathi@datacove.eu
Geosolutions it : Nuno Oliveira nuno.oliveira@geo-solutions.it; Simone Giannecchini simone.giannecchini@geo-solutions.it
Fraunhofer IOSB : Hylke van der Schaaf hylke.vanderschaaf@iosb.fraunhofer.de
Summary (~100 words)
The publication of INSPIRE data sets in the environmental domain usually involves the exposition of real world features, observation generated by monitoring activities and the associated codeLists.
This activity involves mapping the source of the data, for example a database, to the target schema(s). The INSPIRE recommended pattern involves OGC WFS service in its version 2 and SOS.
Then some software, for example GeoServer App-Schema, are responsible to understand those mappings and produce the final GML document as well to support querying on those GML documents.
After INSPIRE data sets have been published and used in real applications, some common requirements have started to emerge:
Recent OGC APIs work is following an interesting approach: JSON has the core format, REST like API and basically build on top of modern Web technologies. Core example are WFS 3.0 and Sensorthings API.
BRGM has been caring on some experiments, deploying these APIs on top of its Ground Water Information System (GIN) Linking those data as much as possible. Also taking into account recent OGC work on this aspect in its Environmental Linked Features Interoperability Experiment - and follow-up IE (ELFIE & SELFIE).
BRGM GIN has been presented in OGC and INSPIRE gathering many times; for example in the OGC HydroDWG.
Chosen implementations are:
Key issues to questions to answer/investigate
This shift to modern Web technologies and JSON like formats bring several challenges and raise several questions:
Required knowledge and skills
Offered datasets
Other relevant datasets
New technologies to test or evaluate
Offered personal resources
Offered or suggested tools
Desired outcome and presentation
Offered benefits for the teams
Background & context
Cooperation with other Challenge Partners
Yes
Yes, after impact/workload evaluation
Submitting organisations