Support #3588

NL: link to download dataset via WFS uses incorrect CRS code

Added by Thijs Brentjens over 1 year ago. Updated about 1 year ago.

Status:FeedbackStart date:06 May 2019
Priority:NormalDue date:
Assignee:Angelo Quaglia% Done:


Category:Harvesting results
Target version:-
Submitting Organisation:Geonovum Knowledge-Base relevant?:No
Proactive:No Keyword #1:
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:


The first downlink link points to this GeTFeature  request:


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


#1 Updated by Angelo Quaglia over 1 year ago

  • Category set to Harvesting results
  • Status changed from New to Assigned
  • Assignee set to Angelo Quaglia

#2 Updated by Angelo Quaglia over 1 year ago

  • Status changed from Assigned to Feedback

Dear Thijs,

that is taken from the dataset metadata:






Best regards,


#3 Updated by Thijs Brentjens about 1 year ago

Dear Angelo,

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

Dear Thijs,

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 

Short name 

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

2) EPSG:28992


4) urn:ogc:def:crs:EPSG::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?


Best regards,


#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.


Best regards,


#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

Dear Thijs,

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".

Best regards,


#8 Updated by Thijs Brentjens about 1 year ago

Dear Angelo,

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

Dear Thierry,

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.


Best regards,


P.S.: May I ask you to have a look at NL Issue #3597 opened this morning by Wideke?

Also available in: Atom PDF