NL: link to download dataset via WFS uses incorrect CRS code
|Status:||Feedback||Start date:||06 May 2019|
|Assignee:||Angelo Quaglia||% Done:|
|Submitting Organisation:||Geonovum||Knowledge-Base relevant?:||No|
|Country:||NL - The Netherlands||Keyword #2:|
|Originating UI:||Thematic Viewer||Keyword #3:|
In the download options of a dataset on the geoportal, we see that the Get Data Set button sometimes uses incorrect CRS codes in the WFS requests to get the data.
Take for example this dataset in the geoportal: http://inspire-geoportal.ec.europa.eu/download_details.html?view=downloadDetails&resourceId=%2FINSPIRE-8c93a17a-05f4-11e1-b7de-52540004b857_20190429-092242%2Fservices%2F1%2FPullResults%2F241-260%2Fdatasets%2F16&expandedSection=metadata
The first downlink link points to this GeTFeature request: https://geodata.nationaalgeoregister.nl/natura2000/wfs?request=GetFeature&Language=eng&CRS=28992&DataSetIdNamespace=&service=WFS&count=10&STOREDQUERY_ID=urn:x-inspire:storedQuery:natura2000:FullDataset&version=2.0.0&DataSetIdCode=4bbfdba2-7687-4393-9192-35ff89e6dfd0
The CRS param is invalid. It uses the EPSG code alone, without the prefix "EPSG:". How is this request constructed? The WFS advertizes as Default CRS: "urn:ogc:def:crs:EPSG::28992".
So somehow a different CRS is used. Could you please help identifying the issue? Thanks in advance
#2 Updated by Angelo Quaglia over 1 year ago
- Status changed from Assigned to Feedback
that is taken from the dataset metadata:
#3 Updated by Thijs Brentjens about 1 year ago
To me it does not make sense to use a CRS from the dataset metadata to request a service. But okay, even if so, then the correct notation should be used, including the namespace, EPSG:28992, and not only the code (28992).
But still I think the geoportal should request data from a service based on the capabilities of a service. For OGC services there have been several notations of CRS codes, with important differences not only in the notation but also in the definition. Like axis order for example. So the exact notation is relevant. And because Stored Queries are tight to the service (not to ISO metadata), I'd say that the notation of the service is leading.
Shortly: the service advertizes the default CRS as "urn:ogc:def:crs:EPSG::28992", for a valid WFS request this should be used as I see it.
If you disagree, could you please explain why the dataset metadata notation is more important?
#4 Updated by Angelo Quaglia about 1 year ago
There is an additional aspect that we need to take into account.
The Technical Guidance documents for Data Specifications contains the following requirement:
TG Requirement 2 The identifiers listed in Table 2 shall be used for referring to the coordinate reference systems used in a data set.
NOTE CRS identifiers may be used e.g. in:
– data encoding,
– data set and service metadata, and
– requests to INSPIRE network services.
Table 2. http URIs for the default coordinate reference systems Coordinate reference system
http URI identifier
3D Cartesian in ETRS89
3D geodetic in ETRS89 on GRS80
So, for the same CRS we would have to deal with four different notations:
1) Namespace: EPSG, Code: 28992
The INSPIRE Geoportal assumes that:
- dataset and series metadata contain each CRS in the agreed notation (please note that you can add as many "aliases" you need in your metadata for each CRS);
- the INSPIRE Clients need to understand only the agreed notation;
- Network Services understand the agreed notation;
Of course, the INSPIRE Geoportal can implement any additional mapping but the same will have to be implemented by any other INSPIRE Client, which is rather detrimental to interoperability.
Perhaps this topic should be raised in the MIG-T?
#5 Updated by Angelo Quaglia about 1 year ago
From WFS 2.0 I read that:
The CRS shall be encoded using the URL format defined in "Definition Identifier URNs in the OGC namespace" (see OGC 07-092r2).
So, what I would need is a mapping between 1,2,3 to 4.
However, for notation 1, the namespace used in metadata is not alway EPSG.
Also notation 2 is not very reliable as far as I can see from existing metadata.
If I could rely on notation 3, that would simplify the matter.
I believe that the Data Specifications team opted for the http uri notation well after the Download Service Guidelines were redacted.
In any case, I will certainly enhance the INSPIRE Geoportal so that if it cannot use the CRS taken from the metadata, it will try the WFS default and the advertised ones.
#6 Updated by Angelo Quaglia about 1 year ago
There is an additional argument, though:
The INSPIRE Geoportal uses the dataset metadata CRS only when invoking the mandatory INSPIRE Stored Query.
The CRS parameter is an INSPIRE custom one, so, technically, it is not subject to the WFS requirements.
For all other getFeature requests, the INSPIRE Geoportal used the WFS default.
#7 Updated by Angelo Quaglia about 1 year ago
I am trying to add some reasonable defaulting for the CRS to overcome this problem.
One would expect that stored queries for INSPIRE Predefined Data Sets woud support an empty or missing CRS parameter, but this is not the case since it has not been explicitly required, so some might support it but some other definitely do not.
In addition, the defaultCRS is expressed at the FeatureType level and often a data set comprises more than one feature type.
All defaulting seems quite arbitrary at some point.
I am testing the apporach of always adding a test with no CRS and one with "urn:ogc:def:crs:EPSG::4326".
#8 Updated by Thijs Brentjens about 1 year ago
Thanks for all your efforts and trying a different approach, very much appreciated.
Regarding choosing a CRS (if your apporach won't work): maybe a good first guess would be the DefaultSRS of the first FeatureType in the Capabilities document? (You could also check all DefaultSRSes and if these are the same, use the DefaultSRS, otherwise try another one, but it is becoming quite cumbersome). I think the chance that a WFS does not support "urn:ogc:def:crs:EPSG::4326" is a bigger (although still small) than that the DefaultSRS is not supported for other FeatureTypes in the same WFS. But this is an assumption...
I think in most cases the DefaultSRS is supported for all Featuretypes of a WFS. But indeed, in theory the WFS could use different CRSes for different featuretypes that don't overlap. Based on your clarifications I've also come to the conclusion that the TG needs more guidance / explanation how to deal with the CRS parameter in StoredQueries (for GetSpatialDataset). For a client using the StoredQuery there is no clear way to know which CRS to use.
Hopefully you get good results with the new approach.
#9 Updated by Angelo Quaglia about 1 year ago
I am still working on this issue.
I am considering the following approach:
1) Try with the CRSs in the dataset metadata (as it is today)
I have to try them since I have no guarantee about what CRS notations the Stored Query supports
If I do not get back anything good:
2) Try with all the urn-like CRS as they are advertised by the WFS for that feature type starting witht the "INSPIRE ones", then the default CRS.
P.S.: May I ask you to have a look at NL Issue #3597 opened this morning by Wideke?