European Commission logo
INSPIRE Community Forum

Serving data in multiple CRS using ATOM services

Dear colleagues,

Find below the following questions from Oscar Diago (published in a comment here)

"Can the same ATOM offer data in INSPIRE-approved CRS and non-INSPIRE-approved CRS? The only thing I have found about that in the Technical Guides is this:

This Technical Guidance places no requirements on the coordinate reference systems in which data should be made available. Guidance and requirements for coordinate reference systems is given in the thematic Data Specifications and the regulation on the interoperability of spatial datasets and services [INS SDS].

Should I have a different ATOM service to offer my data in non-approved-INSPIRE CRS? "

 

  • Jordi ESCRIU

    This is an interesting technical question.

    WFS services may have re-projecting capabilities if they are supporting different CRSs.

    But not sure about ATOM services, which serve just predefined tiles of the data sets.

    Any experience on this within the cluster?

  • Peter PARSLOW

    TG Requirement 20 of the Download Technical Guidance says

    "Each feed entry shall contain an Atom 'category‘ element for each CRS in which the pre-defined dataset is available. This category element shall refer to a well-known definition of a coordinate reference system."

    The Atom service doesn't do any transformation, but a dataset Atom feed can contain sections for different 'versions' of the same dataset.

    Personally, I think that clause 5.1.21, Example 21, and Requirement 20 look out of place where they are, and actually apply to clause 5.2. The first sentence of clause 5.2 says "The following ―Dataset feed example contains the description of the spatial objects in the pre-defined dataset and entries, which point to the pre-defined dataset in a variety of CRS and format combinations." & example 22 shows how it can be done.

    Perhaps the example doesn't include a "non-INSPIRE-approved CRS", but the text & technology don't limit that. I had hoped to show you an example at https://os.uk/xml/atom/OSOpenNames.xml, as that's the only one we've done in two CRSs (yet) - but I've just discovered the Atom feed doesn't say so - I'll look to get that fixed!

  • Mirosław MIGACZ

    By Mirosław MIGACZ

    In Poland we published one ATOM service for the theme SU and one for the theme PD. Both of these services have datasets in different formats and CRS:

    - INSPIRE compliant GMLs in WGS 84 (EPSG: 4258)

    - not INSPIRE compliant SHPs in our national CS92 (EPSG: 2180)

    - statistical grids and population grids (both in compliant GML and non-compliant SHP) in the ETRS LAEA CRS (EPSG: 3035).

    Not sure if it's OK but we think that the ATOM service should foremost provide INSPIRE compliant data. However, if there are other non-compliant datasets published "aside" it should not be a problem.

    Links to our services below. The descriptions are in Polish but if you know your way around the ATOM config, you'll see references to different CRS.

    https://geo.stat.gov.pl/atom_web-0.1.0/atom/SU

    https://geo.stat.gov.pl/atom_web-0.1.0/atom/PD

  • Jordi ESCRIU

    Hi Peter,

    Thank your for your input.

    You are right - The exemple seems to have only 1 category for http://www.opengis.net/def/crs/EPSG/0/27700

  • Jordi ESCRIU

    Hi Miroslaw,

    I totally agree with you. It should not be a problem to have other non-compliant datasets published "aside".

    Jordi

  • Michael LUTZ

    Dear all,

    I completely agree that it is fine to have othe representations of the data set in the atom feed than the ones conformant with the INSPIRE requirements, e.g. in other formats and/or other CRSs.

    Best, Michael

  • Iurie MAXIM

    Hello everybody,

    I. Regarding the topic "Serving data in multiple CRS using ATOM services" ....

    The TG for INSPIRE Download Services available here is providing several Requirements regarding ATOM and CRS.

    See chapter 5 Atom Implementation of Pre-defined Dataset Download Service​ (starting from page 34):

    A. At page 48 Section 5.1.20 Download Service Feed: entry „category‟ element – CRSs there are some details and a requirement

    TG Requirement 20 Each feed entry shall contain an Atom ‗category‘ element for each CRS in which the pre-defined dataset is available. This category element shall refer to a well-known definition of a coordinate reference system

    This Technical Guidance places no requirements on the coordinate reference systems in which data should be made available. Guidance and requirements for coordinate reference systems is given in the thematic Data Specifications and the regulation on the interoperability of spatial datasets and services [INS SDS].

    B. Shortly, how to implement ATOM feeds (with one or more CRSs) is described at page 35:

    <<This Technical Guidance recommends using Atom feeds to make available pre-defined datasets in a consistent manner. The guidance in this chapter can be summarised at a high-level as follows:

    - A single Atom feed is published as a top-level ―Download Service Feed

    - This feed contains a link to an OpenSearch description document which provides operations metadata for the Download Service. The OpenSearch description document provides information about the operations implemented by the download service.

    - This feed contains one or more Atom entries: one per pre-defined data set. Each of these Atom entries shall contain a link to another Atom Feed (a ―Dataset Feed‖) that describes the particular pre-defined data set.

    - Each of these ―Dataset Feeds‖ shall contain Atom Entries with links to download the predefined dataset in different formats (e.g. in GML, ShapeFile, etc.) and in different Coordinate Reference Systems. One link shall be provided for each format/CRS combination.

    - Feeds may be provided in multiple languages (as described in Section 5.3)

    This pattern is illustrated further in Figure 5.>>

    Reading entire chapter is necessary in order to understand how to implement ATOM

    II. As regards the conclusion <<It should not be a problem to have other non-compliant datasets published "aside">> this is not true. All non compliant datasets will be treated as such by EC Vakidator. All non compliant datasets will create problems to both human users and machines. If it will become a common practice to provide non-compliant datasets, than finding compliant datasets will nbe a difficult process for users looking for compliant data. If the majority of datasets will be non-compliant as it is the case now with most of the datasets, then Idata provided within NSPIRE is not usable.

    It is not too difficult to put non-compliant datasets outside INSPIRE. It is enough just not to include their metadata in the CSW services that are indexed at the national level and then in the EC Geoportal or to create separate download services (INSPIRE compliant and INSPIRE non-compliant)

    Best regards,

    Iurie Maxim

  • Michael LUTZ

    Dear Iurie, all,

    thanks for the detailed summary and pointers to the Atom TG requirements.

    However, I beg to disagree with your conclusions. It is perfectly fine to publish several representations (or distributions) of a data set (it is even a best practice in the "Data on the Web" best practices of W3C - see https://www.w3.org/TR/dwbp/#MultipleFormats), to reduce the cost of transformations at the user end. Some of these representations can of course be not fully INSPIRE-compliant (e.g. be in a different CRS), as long as there is one INSPIRE-compliant representation.

    What we carefully have to avoid is that implementers end up doing one implementation "inside INSPIRE" and a separate one "outside INSPIRE".

    Best regards, Michael

  • Iurie MAXIM

    Then we should understand than both the Technical Guidelines and Abstract Test Suite for INSPIRE data specifications that were made according to TGs, must be changed to include these aspects that are not inline with the TGs.

    Regarding data transformation, these services are covered in article 11 of the Directive and are a Network Service ("transformation services, enabling spatial data sets to be transformed with a view to achieving interoperability").

    Having in mind the EC Regulations and EU Pilots (Infringements) we should be very careful when touching legal aspects.

  • Iurie MAXIM

    Hello,

    The Note:

    This Technical Guidance places no requirements on the coordinate reference systems in which data should be made available. Guidance and requirements for coordinate reference systems is given in the thematic Data Specifications and the regulation on the interoperability of spatial datasets and services [INS SDS].

    is indicating the fact that the:

    1) The Requirements for CRS (for ATOM) are provided in:

    Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services

    In annex II, at page 24 of the Commission Regulation (http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L:2010:323:FULL&from=EN​)  is written:

    <<For the three-dimensional and two-dimensional coordinate reference systems and the horizontal component of compound coordinate reference systems used for making spatial data sets available, the datum shall be the datum of the European Terrestrial Reference System 1989 (ETRS89) in areas within its geographical scope, or the datum of the International Terrestrial Reference System (ITRS) or other geodetic coordinate reference systems compliant with ITRS in areas that are outside the geographical scope of ETRS89. Compliant with the ITRS means that the system definition is based on the definition of the ITRS and there is a well documented relationship between both systems, according to EN ISO 19111.>>

    <<Two-dimensional Coordinate Reference Systems

    — Two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.

    — Plane coordinates using the ETRS89 Lambert Azimuthal Equal Area coordinate reference system.

    — Plane coordinates using the ETRS89 Lambert Conformal Conic coordinate reference system.

    — Plane coordinates using the ETRS89 Transverse Mercator coordinate reference system.>>

     

    2) The "Guidance  ... for coordinate reference systems is given in the thematic Data Specifications" is provided in the INSPIRE Data Specification on Coordinate Reference Systems – Technical Guidelines available here: https://inspire.ec.europa.eu/id/document/tg/rs 

    In this guideline at page 24 in PDF (page 15 in right upper corner) it can be found the TG Requirement 1 "The identifiers listed in Table 1 shall be used for referring to the coordinate reference systems used in a data set. "

    These URIs listed in Table 1, such as for example http://www.opengis.net/def/crs/EPSG/0/3035 should be used for retrieving the corresponding file from ATOM download services, as covered by Requirement 20 from the TG for INSPIRE Download Services available here that states:

    <<Each feed entry shall contain an Atom ‗category‘ element for each CRS in which the pre-defined dataset is available. This category element shall refer to a well-known definition of a coordinate reference system>>

    Therefore,

    The only solution to provide spatial datasets in other coordinate reference system than those listed in the Commision Regulation 1089/2010 is not to implement ATOM, but WFS (for features) because WFS is integrating as well the data transformation network services (for CRS) as described by the INSPIRE Directive and users can request the data in any CRS that is supported by the server.

    Therefore if the question is how to provide the spatial datasets in multiple CRS, including non-INSPIRE CRSs, strictly from the legal point of view the only solution is not to implement ATOM, but to implement WFS (for features), WCS (for coverages) or SOS (for sensor data).

    Another legal solution to provide ATOM in other CRS non INSPIRE (even if INSPIRE CRSs are provided as well) could be to implement Transformation Network Services to allow users to transform the INSPIRE non-compliant data in INSPIRE compliant data.

    Best regards,

    Iurie Maxim

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