search

DATEX-II-EU / DatexII

Main repository for issues and bugs for the DATEXII standard
0 stars 0 forks source link

Lexical space of D2Attribute srsName is not well defined #492

Open JosefKaltwasser opened 4 months ago

JosefKaltwasser commented 4 months ago

What happened?

DATEX II allows specifying coordinates which are not ETRS89 in several places:

  1. Attribute srsName in class PointCoordinatesExtended in Level B Extension in Namespace GnssExtension
  2. Attribute srsName in class GmlLineString in Namespace LocationReference They do have slightly different definitions, and none of them clearly specifies the expected lexical space for the String content. Attribute 2 is clearly taken over from GML, and the lexical space is heavily debated on platforms like StackOverflow. Whether Attribute 1 was intended to by a copy from Attribute 2 is not clear, since this class is not tied at all to GML. From interoperability perspective it seems unacceptable to allow modellers to write whatever they want. Would we see "GPS", "WGS84", "EPSG:4326", "http://www.opengis.net/def/crs/EPSG/0/4326" all as valid values (all with the same meaning)? I propose to change both definitions to specify clearly the expected (possibly, not necessarily the same) lexical space. If the agreed definitions allow, this space should be reflected in an according facet.

Version

3

Code of Conduct

LBlaive commented 2 months ago

This issue can be considered as related to issue 438. It is also to note all the definition in the OpenLR™ package are based on WGS 84 (without specifying which realisation). The proposal sketched for Issue no 438 is able to solve this issue as well.

paalaas commented 2 months ago

There is a best practice proposal on using srsName by the OGC consortium attached, but I have see both of these representations URI or EPSG code used and they are valid as I understand as long as the client can uniquely identify the CRS. Looking at the GML schemas both srsName and srsID are defined in GML 3.x 11-135r2_Name_Type_Specification_for_CRSs.pdf

LBlaive commented 1 month ago

The document provided by Paal Aaserud is of high interest. It defines the OGC mechanism for defining such CRSs and is mainly centred on URI that can define any type of CRS, including compound CRSs and parameterised CRSs. I think this objective of Datex II is to remain simpler by only referencing simple CRS (bi- or tri-dimensional) without adding any time reference system. When defining a URI it implies to determine the authority code, the version number and the CRS code (using keys or a path format).

It seems difficult to impose a unique mean to identify the used CRS. At least a reference/code to one of the three authoritative sources should be accepted (ISO code, OGC URI or EPSG code) if they are clearly identified

Additional comment: srsID and srsName are not totally interchangeable: srsID is an ID and as such needs to be defined beforehand with an srsName.