European Commission logo
INSPIRE Community Forum

Dataset identification in HY-Network application schema?

Hi,

I'm working with publishing INSPIRE Hydrography/Network datasets via a WFS, and, yet again, stumbled into the infamous question of defining an INSPIRE dataset: Is it the intention of the HY Data Specification that a net:Network consisting of a number of hy-n:WatercourseNode and hy-n:WatercourseLink features would form an identifiable INSPIRE data set? And if so, how to assign an INSPIRE dataset ID (inspireID) to it, as the net:Network does not have inspireID property? Individual HydroObjects (link or node) do have hydroID but this is for the particular feature, not the entire dataset.

In metadata, ew can of course give INSPIRE dataset identifiers to datasets, but if they are not visible in the features as properties, one cannot create the mandatory WFS INSPIRE stored query GetSpatialDataset.

Any thoughts and implementation experiences welcome,

Ilkka

 

    • Peter PARSLOW

      In Ordnance Survey, we haven't yet made the data available via an WFS, but we have decided to always wrap our datasets in a FeatureCollection.

      Curiously, the OGC WFS FeatureCollection doesn't actually pass OGC's own rules to be a GML feature collection, so we created our own (in the 'OS' namespace: https://os.uk/xml/schema/product/1.0/OSProduct.xsd; some reasons in https://os.uk/docs/policies/gml-design-policy.pdf clause 3.2).

      Yet to check how that fares with the INSPIRE validation suite!

      Actually, slightly earlier, we created an INSPIRE base (3.2) SpatialDataSet and put all the HY members in there. That works, but has been deprecated at 3.3.

      In my understanding of the OGC schemas, WFS 1.0 and 1.1 FeatureCollections had identifiers, but the recommendation now is to use OGC WFS2.0 wfs:FeatureCollection as the root of your datasets, which doesn't!

      • Thijs BRENTJENS

        By Thijs BRENTJENS

        Hi Ilkke,

        Without knowing the details of Hydrography and Network datasets, what might be a solution for the WFS implementation, is to offer a service that offers data of only one dataset (whatever a dataset exactly is of course).

        This is also in line with the TG Download Services:

        TG Requirement 52
        A separate WFS endpoint shall be provided for each INSPIRE dataset thus
        providing one dataset per GetCapabilities response.

        The stored query GetSpatialDataset should then return a FeatureCollection with all feature types of the WFS. There is no need to use the dataset identifier in processing the request of the stored query then: just return all data of the endpoint (and ignore the dataset identifier).

        Hope this helps.

        Thijs

         

        • Sorin RUSU

          Hi Ilka,

          As far as I am aware there is no limitation within INSPIRE that equates a specific data theme with one or several feature types to a single dataset. A dataset might be composed of multiple feature types spanning multiple data themes if the responsible organization deems it so, and also only a subsection of feature types within a data theme might form a dataset if the responsible organization sees it that way.

          There is an underlying question regarding whether or not responsible organizations should strive to transform the functional models they have (I am unsure if you can build a functional hidrological model using just the hy-n:WatercourseNode and hy-n:WatercourseLink features), and if additional features are required they should be part of the transformed dataset, if they are available/in the jurisdiction of the responsible party.

          Regardless there should be nothing stopping you creating a MD file for this dataset (comprising hy-n:WatercourseNode and hy-n:WatercourseLink features) that might have an INSPIRE ID and codespace assigned.

          I am unsure what exactly you are meaning by hy-n:WatercourseNode (I am unable to see elements in the XSD for hy-n v4 with that name, only hy-n:HidroNode, which does have INSPIRE ID element).

          You can however publish the two features in a WFS as distinct features and get them with a stored query that just does multiple queries in the same SQ to get all the features from a specific WFS endpoint