European Commission logo
INSPIRE Community Forum

What CRSs to document in metadata when serving a dataset through a WFS

The IRs for data interoperability require metadata to be provided with a "Description of the coordinate reference system(s) used in the data set" (Art. 13(1)) and that "Spatial data sets shall be made available using at least one of the coordinate reference systems specified in sections 1.3.1, 1.3.2 and 1.3.3, unless one of the conditions specified in section 1.3.4 holds" (Annex II, 1.3).

This is relatively straightforward if data are being transformed according to the IR requirements offline and provided through an Atom download service as individual files (the download service TGs describe how to serve different files for different CRSs).

When using a WFS to serve the data, these usually can perform CRS transformations on-the-fly, i.e. they will return the data in whatever CRS is requested by the user. In this case, what CRS should be documented in the metadata? The source CRS or all CRSs that can be provided by the WFS that serves that data (this would potentially be a very long list). 

If it is the former, how do we determine during validation that the obligation to provide the data set in one of the required CRSs is met? This would have to be done through the service, and could not be done through the metadata.

  • Peter STROBL

    I would say it depends, because the data and the service are two entirely different and largely independent issues:

    • To characterise the data you must state the native CRS of the data.
    • To describe the capability of the service you should specify which transformations it supports.

    To the client this makes a difference depending on the type of data requested. While vector data can be converted from one CRS to another more or less loss free and in no time, the same is NOT true for raster data and a conversion might result in unwanted artifacts.

  • Jordi ESCRIU

    Dear Michael,

    Not sure if I am misinterpreting the question...

    In my view, we have to differenciate between the data set and the service.

    1) If we are speaking about the WFS service:

    In my opinion the GetCapabilities request should return the list of ALL CRSs for which data can be offered by the service - even being a long list. And also to document this list in the service metadata.


    For validating that the service at least provides data in one of the CRSs allowed by INSPIRE, we should be checking that any of these EPSG codes is returned by the GetCapabilities. If this is successful, as a doublecheck we could request a GetFeature operation according the specific INSPIRE-allowed EPSG code and wait for a succesful response.

    2) If we are speaking about the data set:

    If the data set is supossed to be INSPIRE-compliant, therefore I guess that the data set metadata should document an INSPIRE-allowed CRS through its corresponding EPSG code.

    The data set metadata should be also providing access to the WFS service (Case 1).

    In my view, the concept of source CRS makes more sense for existing national data sets (usually not compliant to INSPIRE). In the case of INSPIRE data sets, should not the source CRS be an INSPIRE-allowed CRS?


  • Michael LUTZ

    Jordi, Peter,

    thanks for the quick feedback. It's clear that the data and service are distinct entities; however they are closely related. Maybe I didn't explain the issue very well - I'll try agin... 

    You can make available a data set in conformity with the IRs for data interoperability either through the adaptation of existing spatial data sets or through transformation services (Art. 7(3) of the INSPIRE Directive).

    One scenario (mainly applicable to vector data) is that you do all required schema transformations for your data set, but keep the source (non-INSPIRE) CRS. Then you publish this transformed data set through a WFS, which can provide the data set in any CRS supported by the WFS software. If these include at least one of the INSPIRE CRS, I would argue that you have met your INSPIRE obligations (using a combination of adaptation and transformation service). In this case, what CRS would you put in the data set metadata?

  • Peter STROBL

    to me there's only one logic solution:

    The "data set metadata" describe the data set and therefore must refer to the CRS the data set is (orginally) produced in.

    This does of course not preempt the fulfillment of the obligation to "make available" INSPIRE conformant data through a transformation service which is capable to do a respective conversion.

    While to the users of vector data this does not make a big difference (for the reasons stated above), for raster data it does. A user of raster data should be informed and eventually even have a choice regarding the kind of transformation applied to data made available.

    BTW: Is there somewhere in INSPIRE a generic (mathematical) definition (i.e. not based on examples) for raster and for vector data? Should maybe become a different thread...

  • Jordi ESCRIU

    Hi Michael,

    In the case a MS decides applying the scenario you described, I do not specifically catch why you argue about the fulfilment of the obligations by the MS:

    - Does the data set (and CRS) need to be adapted at the source necessarily? - I would say no, since the transformation service option is available - Art. 7 (3).

    - Is it not allowed to combine the "adaptation at source" option with the "transformation service" option?

    My try...

    In the case you described the use of a WFS is obviously a download service, but can be seen in part as a transformation service (WPS) - as far as the CRS offerings is concerned.

    The data offered by the WFS could be seen as belonging to a "virtual INSPIRE data set", which may have their own metadata - having documented one INSPIRE-allowed CRS.

    In my opinion, the "real data set" (at source) should have documented the original CRS in its corresponding metadata (if the original CRS is mantained at source).  this is also in line with Peter's suggestion.

    Please, let me know what you think.


  • Michael LUTZ

    Hi Jordi,

    I agree that the "adaptation at source" option with the "transformation service" option can be combined and that, broadly speaking, a WFS provides both functionalities of a download a transformation service (note that, strictly speaking, a mapping from the WFS operations & parameters to the transformation service IR would need to be defined). On the other hand, the download service IRs already require support for a CRS request parameter for the Get Spatial Dataset and get Spatial Object operations, i.e. the download service is already required to provide coordinate transformation capabilities.

    It also requires that, for each Spatial Data Set, the list of those Coordinate Reference Systems referred to in Regulation (EU) No 1089/2010 which are available shall be provided in the Download service metadata. In the TGs for WFS, this is mapped to the WFS capabilities response, which includes for each feature type the

    • DefaultCRS: The wfs:DefaultCRS elementindicates which coordinate reference system shall be used by a WFS to express the state of a spatial feature,if not otherwise explicitly identified within a query or transaction request. For example, if a GetFeature request specifies no CRS value for thewfs:Query srsName attribute, any spatial properties of feature data satisfying the request shall be expressed using the wfs:DefaultCRS value. The CRS shall be encoded using the URL format defined in "Definition Identifier URNs in the OGC namespace" (see OGC 07-092r2). The wfs:DefaultCRS shall not necessarily be the internal storage CRS used for the feature data, and therefore should not be interpreted as such. If the wfs:DefaultCRS is different from the internal storage CRS, then the WFS shall support a transformation between the wfs:DefaultCRS and the internal storage CRS. The effects of such a transformation shall be considered when determining and declaring the guaranteed data accuracy.
    • OtherCRS: The wfs:OtherCRS element shall be used to indicate other supported CRSs within transaction and query requests. A 'supported CRS' means that the WFS supports the transformation of spatial properties between the wfs:OtherCRS and the internal storage CRS. The effects of such a transformation shall be considered whendetermining and declaring the guaranteed data accuracy.

    The question is: what should be put in the dataset metadata element "CRS" (defined as: Description of the coordinate reference system(s) used in the data set.)? The same CRSs that are listed in the WFS capabilities (this would be redundant information) or just the "internal storage CRS"? The latter could be useful to evaluate whether there may be any quality issues due to transformations when requesting the dataset in another CRS (in particular for raster datasets as pointed out by Peter).

  • Henrique SILVA

    By Henrique SILVA

    I think that the internal dataset has is own dataset metadata with the native CRS.
    This dataset metadata are related with the service metadata trough the coupled resource.

    The CRS that should be reported in the service metadata are the most important CRS that the service applys and the mandatory CRS.

  • Jordi ESCRIU

    Dear Michael,

    My answer to your question would be that the "internal storage CRS" (native or source CRS) shall be the one documented in the data set metadata - Also as Henrique spotted.

    The obligation to provide the data set in one of the CRSs required by INSPIRE (from those listed in Regulation (EU) No 1089/2010) should be validated though the WFS service metadata: Step 1) checking the available CRSs returned by the GetCapabilities + Step 2) doublechecking with GetFeature request operations with the CRS parameter equal to each CRS resulting from Step 1 give us successful responses.

    In my view...

    * In the data set metadata, the link to the WFS service from the data set metadata shall be provided by the "Resource locator" metadata element. This link is needed to perform the mentioned validation.

    * Additionally - In the service metadata, the "Coupled resource" metadata element shall provide acess to the data set on which the WFS service operates.



  • Jordi ESCRIU

    Dear Michael,

    I have recently received new views on this question / topic.

    There is also the possibility to conceive the INSPIRE data set offered by the WFS as a "virtual" data set - This may be reasonable in cases where the data set is only offered by this means, i.e. it does not exist physically, but ionly offered by the WFS.

    If this reasoning is applied, the data set metadata would inform about the applicable INSPIRE CRSs (those supported and offered by the WFS), e.g. probably EPSG:4258 as the main one.

    If I am not wrong, the current INSPIRE Validator (in accordance to the TG MD) always requires to inform in the data set metadata at least one of the CRSs allowed by INSPIRE - Otherwise, it throws non-conformance results.

    We have recently started to apply this approach in our regional SDI (Catalonia), in agreement with the IDEE Team (Spanish SDI).

    Please, let me know what you think.



  • Jordi ESCRIU

    Given the absence of more views on this thread I proceed to close it.

    Please send me a message through the Forum if anyone is willing to open the discussion again.


This discussion is closed.

This discussion is closed and is not accepting new comments.

Elevation, Ortho & Grids

Elevation, Ortho & Grids

INSPIRE Thematic Cluster Elevation, Orthoimagery, Reference systems, Geographical grids - Join this group to share your knowkledge, learn and collaborate in solving issues related to the Elevation, Orthoimagery, Reference systems and Geographical grids themes