European Commission logo
INSPIRE Community Forum

FYI: interpreted coordinate order flipped in GML files with URI format srsName

Hi,

This is not specific to the Biodiversity and Management Area Cluster, but it seems I have to choose one the themes to post:

I found out that when using the INSPIRE-compliant URI-format coordinate reference system names (like "http://www.opengis.net/def/crs/EPSG/0/3035) in the GML files, the GDAL library (before the currently unreleased version 2.1.2) does not respect the coordinate order of the EPSG:3035 (northing, easting), but instead uses the order (easting, northing). This obviously create problems for the users using previous versions of GDAL either directly or indirectly (through QGIS for example) for reading GML INSPIRE datasets.

If one uses the URN format srsName (urn:ogc:def:crs:EPSG::3035) the coordinates are interpreted in the official EPSG axis order, but using the URN CRS IDs are not allowed by the INSPIRE Data Specifications.

Based on the discussion on the QGIS user mailing list there seems to by no workaround available, except using the URN format srsNames.

This has been identified as a bug in GDAL GML Driver, and the fix has already been done in code scheduled to be released as GDAL 2.1.2: https://trac.osgeo.org/gdal/ticket/6678

 

  • Stefania MORRONE

    By Stefania MORRONE

    Hi all,

    I would like to share another issue related to the 'use of the INSPIRE-compliant URI-format coordinate reference system names (like "http://www.opengis.net/def/crs/EPSG/0/3035) in the GML files': the http URI encoding for CRS is currently not supported by deegree. Therefore you are not able to ingest a GML which conforms to INSPIRE TG requirement for CRS encoding and serve it by means of deegree WFS.

    For more details you can read the issue reported to deegree developers.

  • Iurie MAXIM

    Hi Ilkka and all,

    I found here this information that may help because it describes how to configure GDAL starting from version 1.8.0 (released in January 2011, so yesterday) in order to deal with the axis order & with CRS provided as URN vs URL.

    To work properly users must make some configurations explained in the document. As most if not even all GIS software are using GDAL it is necessary to find which GDAL version is installed and to configure GDAL. See https://trac.osgeo.org/gdal/wiki/ConfigOptions

    Starting with version 2.1.2 (just released yesterday, on 21 October 2016) GDAL works without any configuration, most probably because the default value for GML_SWAP_COORDINATES is set to AUTO.

    And here is the text:

    <<Since OGR 1.8.0, the GML driver has coordinate system support. This is only reported when all the geometries of a layer have a srsName attribute, whose value is the same for all geometries. For srsName such as "urn:ogc:def:crs:EPSG:" (or "http://www.opengis.net/def/crs/EPSG/0/&quot; starting with GDAL 2.1.2), for geographic coordinate systems (as returned by WFS 1.1.0 for example), the axis order should be (latitude, longitude) as required by the standards, but this is unusual and can cause issues with applications unaware of axis order. So by default, the driver will swap the coordinates so that they are in the (longitude, latitude) order and report a SRS without axis order specified. It is possible to get the original (latitude, longitude) order and SRS with axis order by setting the configuration option GML_INVERT_AXIS_ORDER_IF_LAT_LONG to NO.

    There also situations where the srsName is of the form "EPSG:XXXX" (whereas "urn:ogc:def:crs:EPSG::XXXX" would have been more explicit on the intent) and the coordinates in the file are in (latitude, longitude) order. By default, OGR will not consider the EPSG axis order and will report the coordinates in (latitude,longitude) order. However, if you set the configuration option GML_CONSIDER_EPSG_AS_URN to YES, the rules explained in the previous paragraph will be applied.

    Since OGR 1.10, the above also applied for projected coordinate systems whose EPSG preferred axis order is (northing, easting).

    Starting with GDAL 2.1.2, the SWAP_COORDINATES open option (or GML_SWAP_COORDINATES configuration option) can be set to AUTO/YES/NO. It controls whether the order of the x/y or long/lat coordinates should be swapped. In AUTO mode, the driver will determine if swapping must be done from the srsName and value of other options like CONSIDER_EPSG_AS_URN and INVERT_AXIS_ORDER_IF_LAT_LONG. When SWAP_COORDINATES is set to YES, coordinates will be always swapped regarding the order they appear in the GML, and when it set to NO, they will be kept in the same order. The default is AUTO.>>

    Best regards,

    Iurie Maxim

  • Iurie MAXIM

    Hi Stefania and all,

    As far as we know, Deegree accept CRS declared as URN (i.e.: urn:ogc:def:crs:EPSG::3035) while OGC and INSPIRE is requiring CRS to be declared as URL. I am not sure if this is due to an older version of GDAL or not, bust most probably is linked with the issue pointed by Ilkka Rhine, threfore maybe it is possible to configure GDAL as I explained in the previous post, We did not insisted to work with Deegree for implementing INSPIRE as I explained here.

    We identified in the past these three endpoints that are providing the CRS information within a GML Registry. Different software are using one of these endpoints, I think that usually the second or the third. The first two are providing the CRS encoded as GML 3.2, while the third is missing the declaration of the version of the GML encoding:

    1. In epsg-registry.org URI are encoded as URN:
    <gml:identifier codeSpace="OGP">urn:ogc:def:crs:EPSG::3035</gml:identifier> 
    CRS is provided as a URN encoded in the value of the gml:identifier element, within the "OGP" codeSpace.

    2. In opengis.net URI are encoded as URL:
    <gml:identifier codeSpace="OGP">http://www.opengis.net/def/crs/EPSG/0/3035</gml:identifier&gt;
    CRS is provided as a URL encoded in the value of the gml:identifier element, within the "OGP" codeSpace.

    3. In spatialreference.org URI are encoded as URN codeSpace + value:
    <gml:name gml:codeSpace="urn:ogc:def:crs:EPSG::">3035</gml:name>
    CRS is provided as a NUMBER encoded in the value of the gml:name element, within the "urn:ogc:def:crs:EPSG::" codeSpace.

    In the opengis.net the xlinks are even further remote resolved.
    All the xlinks listed below are remote resolved by using the epsg-registry.org GML Registry:
    <gml:domainOfValidity xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="urn:ogc:def:area:EPSG::1298"/&gt;
    <gml:conversion xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="urn:ogc:def:coordinateOperation:EPSG::19986"/&gt;
    <gml:baseGeodeticCRS xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="urn:ogc:def:crs:EPSG::4258"/&gt;
    <gml:cartesianCS xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="urn:ogc:def:cs:EPSG::4532"/&gt;

    The fact that the xlinks are remote resolved can be verified by making the following requests:
    http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:area:EPSG::1298
    http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:coordinateOperation:EPSG::19986
    http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:crs:EPSG::4258
    http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:cs:EPSG::4532

    The resolve has a resolveDepth > 1 because the URNs are further resolved.

    This is a very good example (for the EC INSPIRE Registry) on how a registry must function in order to ensure that the xlinks are resolved in the GML.

    Any of the xlinks to epsg-registry.org can be transformed automaticaly in xlinks that are pointing to opengis.net and viceversa:
    first part = "http://www.epsg-registry.org/export.htm?gml=urn:ogc&quot; = "http://www.opengis.net/&quot;
    any ":" after the first part = "/"

    In this way: 
    http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:crs:EPSG::3035 = http://www.opengis.net/def/crs/EPSG/0/3035

    http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:coordinateOperation:EPSG::19986 = http://www.opengis.net/def/coordinateOperation/EPSG/0/19986
    and so on.

    URI = Unioform Resource Identifier (https://en.wikipedia.org/wiki/Uniform_Resource_Identifier)
    URL = Uniform Resource Locator (https://en.wikipedia.org/wiki/Uniform_Resource_Locator)
    URN = Uniform Resource Name (https://en.wikipedia.org/wiki/Uniform_Resource_Name)
    EPSG = European Petroleum Survey Group absorbed by IOGP (See OGP)
    OGP = Oil and Gas Producers (https://en.wikipedia.org/wiki/International_Association_of_Oil_%26_Gas_Producers#European_Petroleum_Survey_Group)

    Best regards,

    Iurie Maxim

  • Iurie MAXIM

    Hi,

    Just to notice that GDAL 2.1.2. was released Friday 21 November 2016 (two days ago).

    See http://download.osgeo.org/gdal/

    Iurie 

  • Iurie MAXIM

    Hi all,

    I checked the ENVPlus validator including skipping and not skipping Schematron Test and the OGC GML Validator and the following forms for providing srsName are validated in the GML files:

    srsName="urn:ogc:def:crs:EPSG::3035"

    srsName="http://www.opengis.net/def/crs/EPSG/0/3035"

    If any other form is provided (i.e.:EPSG::3035, EPSG:3035) the error message is indicating the OGC 09-048r3 document (31/3/2010), that can be found at https://portal.opengeospatial.org/files/?artifact_id=37802

    According to Annex A (informative) of OGC 09-048r3:

    <<When using an XML attribute or element with the type anyURI to reference a CRS, CRSrelated, or other object, that URI shall have a value which uses one of two alternative URI formats:

    a) Universal Resource Locator (URL), with standard form. The URL format should be used whenever the referenced definition is known to be electronically available using this standard URL.

    b) Universal Resource Name (URN), with a specified form. The URN format shall be used whenever the referenced definition is not, or might not be, available using a URL. This URN shall reference data that is specified by some ―authority‖ and is ―well-known‖ to both client and server software, including multiple clients and multiple servers.>>

    It should be mentioned as well the OGC 11-135 that "establishes a Name Type Specification (NTS) for Coordinate Reference Systems (CRSs), beeing based on the Name Type Specification – definitions – part 1 – basic name [OGC 09- 048r3] and supersedes OGC document ―Definition identifier URNs in OGC namespace‖ [OGC 07- 092r3]."

    I assume then that  taking into consideration that for EPSG 3035 it exist a URL, the OGC documents and the INSPIRE DS for CRS must be interpreted in the way that providing the CRS as srsName="urn:ogc:def:crs:EPSG::3035" in the GML is incorrect.

     

    @Stefania: Should the ENVPlus Validator trigger an error if the CRS of the geometry features in the GML is provided in URN form ?

    @All: How should the Requirement 1 and its Note from the TG for CRS be interpreted having in mind the words SHALL and MAY ?

    <<The identifiers listed in Table 1 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 1 is listing CRSs provided as URL, such as http://www.opengis.net/def/crs/EPSG/0/3035

    In  INSPIRE Documents is written:

    <<In accordance with the ISO rules for drafting, the following verbal forms shall be interpreted in the given way:

    • “shall” / “shall not”: a requirement, mandatory to comply with the technical guidance
    • “should” / “should not”: a recommendation, but an alternative approach may be chosen for a specific case if there are reasons to do so
    • “may” / “need not”: a permission>>

    Shall we read the Note of the Requirement 1 as follows?

    CRS identifiers listed in table 1 (as URLs) shall be used in :

    - spatial datasets and data series provided trough data services
    - metadata of the spatial datasets, spatial data series and spatial data services and in GetCapabilities documents
    - requests to INSPIRE network services.

    Having in mind the network services, it should be taken into consideration that WFS 2.0.0 standard (See document at page 49) has the following requirement:

    <<Servers that implement this International Standard shall be able to process srsName attribute values using the following format model: urn:ogc:def:objectType:authority:version: (see OGC 07-092r2) In this format model, objectType shall have the value of "crs", authority shall have the value "crs" and the value is a placeholder for the actual EPSG code value. EXAMPLE srsName="urn:ogc:def:crs:EPSG::26986”. >>

    This was changed in WFS version 2.0.2, so in order to comply MS must implement WFS 2.0.2 and not WFS 2.0.0.

    In WFS 2.0.2 standard is mentioned:

    Servers that implement this International Standard shall be able to process srsName attribute values using the following format model:

    urn:ogc:def:objectType:authority:version:<EPSG code>(see OGC 07-092r2)

    http://www.opengis.net/def/crs/[epsg|ogc]/0/{code}

    In this format model, objectType shall have the value of "crs", authority shall have the value "crs" and the valuetoken "{code}"<EPSG Code>iis a placeholder for the actualEPSG crs code value as defined by the authority "epsg" or "ogc".

    EXAMPLE srsName="urn:ogc:def:crs:EPSG::26986http://www.opengis.net/def/crs/epsg/0/26986".

    The format model from the previous version of this standard:

    urn:ogc:def:objectType:authority:version:<EPSG code> (see OGC 07-092r2)

    where objectType shall have the value "crs", authorify shall have the value "EPSG" and the value <EPSG Code> is a placeholder for the actual EPSG code is still allowed but is deprecated[11].

    @All: Should it be interpreted that WFS 2.0.2 (10/07/2014) must be implemented instead of WFS 2.0.0 (02/11/2010) or should be interpreted something else ?

    Best regards,

    Iurie Maxim

  • Stefania MORRONE

    By Stefania MORRONE

    Hi Iurie,

    the OGC 09-048r3 specifies that “The URN format shall be used whenever the referenced definition is not, or might not be, available using a URL”. Conversely, for cases in which the URL exists (e.g.http://www.opengis.net/def/crs/EPSG/0/3035), the OGC requires that "the URI shall have a value which uses one of two alternative URI formats: URL or URN". The URL format should be preferred (The URL format should be used whenever the referenced definition is known to be electronically available using this standard URL).

    Regarding the INSPIRE Data Specifications, the difference between IR requirement (i.e. must be implemented) and TG Requirement (i.e. must be implemented to conform to the TG specific technical solution) has to be considered.

    In all the INSPIRE DS (therefore also in the DS on Coordinate Reference Systems) the use of http URIs is a TG requirement and it’s stated that “ These Technical Guidelines propose to use the http URIs provided by the Open Geospatial Consortium as coordinate reference system identifiers”

    To answer your question, my opinion is that the ENVPlus Validator correctly

    1. does not report any error if the CRS is provided in URN form (the data provider could conform to IR requirement on identifiers using an alternative approach to the one proposed in TG. One reason to use URNs instead of URLs could be -for example- that currently some software does not correctly handle CRS in URL form)
    2. throws an exeption when no URN nor URL form is provided (e.g. EPSG: 3035 form, which violates OGC requirement for URL or URN encoding).

    Best Regards

    Stefania 

  • Iurie MAXIM

    Hi Stefania,

    I understand your point of view regarding IRs and TGs, but I think that the EnvPlus validator is checking against TGs as well and not only against IRs. Of course we both know that there are some mistakes either in the IRs or either in the TGs and that the EnvPlus validator is allowing both interpretations

    But as far as the ENVPlus is validating against a schema it means that it validates against the TGs. I do not remember where in the IRs is written that a certain XSD must be used, or that even where in the IRs is written that GML 3.2 must be used for encoding spatial data. But if the GML is not 3.2 version or is not validating against a XSD version 3 or 4, the validator throws an error, which is totaly understandable.

    Therefore I do not understand why some TGs requirements are implemented in the EnvPlus validator and some others are should not be implemented, or maybe I am missing something.

    Namely if many requirements from TGs are implemnted in the validator (i.e.: Requirement 4 and 5 from D2.7) why the TG Requirement 1 from DS on CRS should not be implemented ?

    Even if it exist the sentence "These Technical Guidelines propose to use the http URIs provided by the Open Geospatial Consortium as coordinate reference system identifiers" in the TG, it exist as well the Requirement 1:

    <<The identifiers listed in Table 1 shall be used for referring to the coordinate reference systems used in a data set.>>

    Table 1 is listing CRSs provided as URL, such as http://www.opengis.net/def/crs/EPSG/0/3035

    We both already know that ATS are prepared for each Requirement and Recommadation and even the EC Metadata validator is cheking against the TGs, not against the IRs.

    To not be wrongly understood, I just pointed an issue/topic for discution in relation to the URN versus URI, becsue personally I expected a data validator to indicate all Requirements and reccomandations that are not fulfiled.

    For a better understanding, the EnvPlus is a very useful tool for to alow MSs to make "valid" datasets. Without EnVPlus we were not able to make a "valid" dataset, but just a dataset. 

    Therefore we wrote about any issue that we found in the validator and we indicated even what is missing (i.e.: no validation of codeliists xlinks) to be helpful for other data providers to create valid datasets.

    Best regards,

    Iurie Maxim

     

  • Stefania MORRONE

    By Stefania MORRONE

    Hi Iurie,

    I fully agree with you that a validator, providing an executable test suite , ‘de facto’ selects  a technical solution for implementing the IRs and validates against it, and this technical solution should be (I would like I can write 'shall 'be) the one proposed in the TG.

    This is a very important aspect to take into consideration when implementing INSPIRE (so thank you for pointing out): technical choices affect the true interoperability/usability of datasets and therefore there’s the need to conform to the Technical Guidelines as a whole.

    That said, it must be acknowledged that technical choices do not always correspond to mature technical software solutions and this is a thing that must be taken into account as well.

    For those cases, I think that it can be of help for the INSPIRE implementers that a validator (which provides executable tests for the ATS) takes into consideration the difference between Part 1 (normative- Conformity with Commission Regulation No 1089/2010) and Part 2 (informative - Conformity with the technical guideline (TG) Requirements ) of the ATS

    i.e.

    considers that that “TG requirements are technical provisions that need to be fulfilled in order to be conformant with the corresponding IR requirement when the specific technical implementation proposed in this document [the TG] is used “, and therefore conformity to the TG requirements included into ATS-Part 2 (such as the ‘CRS http URI test’) is not formally required to be conformant to ISDSS Regulation.

    Maybe just reporting the following will clarify my thought better.

    The first release of the eENVplus validator allowed only the URL encoding for Coordinate Reference Systems. Feedbacks we had from the users – not able to display their TG conformant datasets correctly in QGIS or not able to ingest their GML in deegree because of  the http encoding in srsName attribute- made us apply the consideration that forcing the users to have ‘fully TG conformant but unusable dataset’ would maybe not be worth the candle.  And that’s why currently the eENVplus validator allows the use of both URLs and URNs for CRS specification.

    Best Regards

    Stefania

  • Iurie MAXIM

    Hi Stefanie,

    1. Really appreciate your last post. Therefore we can conclude that REQ 1 from CRS Data specification was removed from the validation because of the missing technical solutions to display correctly valid datasets. As from 21 October GDAL resolved this issue it is possible to re-include this requirement in the near future ?

    2. Should we indicate as well to the JRC that REQ 1 is confusing as it is using the words shall and may, where 

    • “shall”: a requirement, mandatory to comply with the technical guidance
    • “may”: a permission>>

    <<The identifiers listed in Table 1 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.>>

    Probably "CRS identifiers are used e.g. in" can be used instead of the formulation with "may be".

    3. Should we conclude that actually the data providers must implement WFS 2.0.2 that is the WFS 2.0 standard with corrigendum (one of the most important corrigendum being exactly the change of CRS from URI to URL) See http://docs.opengeospatial.org/is/09-025r2/09-025r2.html

    Best regards,

    Iurie Maxim

     

  • Stefania MORRONE

    By Stefania MORRONE

    Hi Iurie,

    start answering from last question: “Should data providers implement WFS 2.0.2? “

    WFS 2.0 requires an ability to process srsName values provided as OGC URNs, while does not foresee any obligation to be able to process srsName values provided as OGC URLs. Conversely the WFS 2.0.2 has such an obligation (note: in WFS 2.0.2 URN encoding is still allowed but is deprecated).

    Since conformity to TG requirement for CRS identifiers implies the use of URLs, the data providers should implement WFS 2.0.2 .

    However, a problem still has to be faced: how could data providers test conformance to WFS 2.0.2 ?

    I do not know about the existence of a relevant test, at least an official OGC CITE Test Suite is not yet available. So it seems to me that, again, we must still wait for mature technical software solutions.

    To come to other questions in your post:

    1)    next release of the eENVplus Validation Service will report non-conformities to TG requirement for CRS identifiers (i.e. re-include the ‘CRS http URI test’).

    2)     I agree with you that rephrasing the NOTE according to your suggestion would better clarify the intention of the note itself i.e. to provide examples of where CRS identifiers are typically used. Anyway I think that the use of “may” in the NOTE could not properly be considered an issue for the comprehension of requirement itself.

    Best Regards

    Stefania

This discussion is closed.

This discussion is closed and is not accepting new comments.

Biodiversity & Area Management

Biodiversity & Area Management

If themes like Protected Sites, Area Management/Restriction/Regulation Zones and Reporting Units, Habitats and Biotopes, Species Distribution, Bio-geographical Regions matters to you, join these groups!