I suppose it depends on what you mean by consume, certainly there are clients that can consume WCS 2.0 services, but if you want to query the services, especially the GeoSciML then you are looking at writing your own, that's what we did as part of the EarthServer project.  

Not so good, but at least some elements can be encoded in the rangeType element.

I am not sure how to use swe:Category and not to sure how to declare a swe:CodeSpace in order to be clear that the value 1 represent that the species is present http://inspire.ec.europa.eu/codelist/OccurrenceCategoryValue/present.

Still inspireId would need to be indicated in the metadata element for each ”band”.

Not sure at all if such a data can be exposed with existing SW :

Hi all,

Kathi, I would like to comment on one of your sentences to see if somebody has some info.

Few days ago you mentioned ”First off, as gml coverages are also gml featureTypes, one could provide them via WFS.”.

We investigated and did not found any software that is able to serve a coverage as a WFS. Even Deegree that is able to publish a WFS based on a GML file is trowing an error ”Parsing of gml:RectifiedGrid is not supported” if the GML has an RectifiedGrid element.

So does anyone knows any software solution or any WFS service endpoint that is serving a Rectified Grid Coverage ?

As existing XSD schemas are not compatible with WCS download service and if no solution exist to serve rectified grid coverages via WFS, it means that the only solution remaining for download service is the Atom.

Therefore there is a strong need to change the XSD schemas that contains elements from coverages, in order to encode the suplementary data in the metadata element as described above by Kathi and James. For data themes that contains O&M (EF, AC, MF, OF) it would be necessary as well to move from GMLCOV/CIS 1.0 to CIS 1.1.

If this will not happen everybody should stick to Atom for providing RectifiedGrid coverage data and therefore interoperability will not be ensured. We will face problems of data usability and data testing (ETF).

If we would chose either to encode the data (the gridded data) in GML format or to provide it in a file and make a reference to it in the GML that is exposed via Atom, then no software would be able to consume/display the data provided trough Atom if maintaining the current XSD schemas.

The solution to serve the grid in a WCS and the rest of the element in a WFS does not allow a user to download the dataset.

Therefore the only solution to serve coverages is trough WCS and in order to do this some XSD schemas should be changed and we should adopt CIS 1.1 (for O&M). The XSD schemas for coverages were designed in a period when the standardisation of coverages was undeveloped and the TGs were drafted only at the conceptual model and therefore the schemas should be adapted to the existing OGC standards and to the existing services and software capabilities.

Is my understanding correct ?

Iurie

The solution to serve the grid in a WCS and the rest of the element in a WFS does not allow a user to download the dataset.

I'm not sure where that suggestion comes from though,  In a WCS  the GetCoverage response is multi-part so you get the grid, and the GML in the response.

The XSD schemas for coverages were designed in a period when the standardisation of coverages was undeveloped and the TGs were drafted only at the conceptual model and therefore the schemas should be adapted to the existing OGC standards and to the existing services and software capabilities.

Is my understanding correct ?

There is some element of truth in that for certain; many of the conceptual models were designed with WFS in mind as the delivery mechanism, and this has caused problems not just for coverage data but also for view/portrayal services.  This thinking even made its way into the legislation...

Hi Iurie,

As Kathi already mentioned, providing INSPIRE coverage data is possible via WFS, such services have been in existence for years. Now that the INSPIRE WCS Download Service guidelines are in place, this is however probably no longer recommended for most use cases.

As an example The Finnish Meteorological Institute is publishing gridded weather model data as omso:GridSeriesObservations with gmlcov:RectifiedGridCoverage and out-of-band rangeSet values: http://data.fmi.fi/fmi-apikey/ffc6c172-4fc3-4b9e-bdc4-7c1031bb5b90/wfs?request=getFeature&storedquery_id=fmi::forecast::harmonie::hybrid::grid

The FMI service is implemented using the Open Source SmartMet Server software (https://github.com/fmidev/smartmet-server), but I think you could implement the same kind on mapping with GeoServer AppSchema or similar.

Hi ,

From the example provided by Ilkka, the rangeSet (the actual data of the grid) is provided trough a file reference. Therefore the rectifiedGridCoverage data is not served by the WFS.

If someone would download the dataset trough WFS he will not download the rectifiedGridCoverage data, so actually the most important part of the dataset will be missing.

As Kathi mentioned that ”First off, as gml coverages are also gml featureTypes, one could provide them via WFS.”.I come to the conclusin that actually it is not possible to provide the coverages trough a WFS. I tried with several software and even if the element exist in the GML it is not possible to serve something like this trough WFS:

Hi Iurie,

I choose the the first example, because it uses RectifiedGridCoverage, which you mentioned. There are other FMI services with other coverage types with inlined rangeSet, such as MultiPointCoverage: http://data.fmi.fi/fmi-apikey/ffc6c172-4fc3-4b9e-bdc4-7c1031bb5b90/wfs?request=getFeature&storedquery_id=fmi::forecast::harmonie::hybrid::point::multipointcoverage&place=helsinki

However, I think you are completely right in your original point that there are probably use cases for  alternative INSPIRE encodings using pure CIS based coverage model for certain data themes. If defined so, these could (but would not have to) be made available through a WCS.

Hi all,

Indeed the second example provided is fine, just that it has a major problem, usability: With what software it is possible to view such data ?

Second problem is that the service indicated is not providing data based on an INSPIRE schema, but based on a schema that is not endorsed by INSPIRE. Instead of https://inspire.ec.europa.eu/schemas/ac-mf/4.0/AtmosphericConditionsandMeteorologicalGeographicalFeatures.xsd (that is the official INSPIRE XSD schema even if it is empty) the dataset is made based on http://xml.fmi.fi/schema/om/atmosphericfeatures/1.0/atmosphericfeatures.xsd. So even these examples from Finland shows that the XSD schemas should be changed. At least an empty schema should be changed with a schema.

But because I see that the examples are provided from O&M (Data themes: EF, AC, MF, OF) for which I said that CIS 1.1 should be adopted, I want to be more clear about what I wanted to say trough the sentence ”Therefore there is a strong need to change the XSD schemas that contains elements from coverages”.

Maybe my words were not so well chosen, but "the XSD schemas that contains elements from coverages" are those that include a reference to the GMLCOV 1.0 (xmlns:gmlcov=http://www.opengis.net/gmlcov/1.0) and they are:

Hiya,

following up on this topic, I'd like announce that we have been making progress on the general coverage issues within INSPIRE. At the Helsinki Event next week, we (Jordi Escriu, Peter Baumann, Kathi Schleidt) will be running a workshop on our progress to date, providing demonstration WCS services pertaining to the INSPIRE Themes OI, EL and LC, and showing how these can be processed server side via WCPS.

As the underlying technical issues have now been mostly resolved, we'd be quite interested in resurrecting the currently deprecated coverage based models for SD and HB. To our understanding of the IRs, it should be possible to show compliance of a coverage model with the existing specifications. If data providers are interested in this option, please get in touch!

:)

Kathi & Stefania