Coordinate System for Point Coordinates (Bugzilla Bug 438)

[datexii]

This issue was created automatically with bugzilla2github.py

Bugzilla Bug 438

Date: 2023-03-16T09:39:33+01:00 From: @JoergFst To: Jean-Philippe Mechine <Jean-Philippe.Mechin@cerema.fr> CC: @iancornwellmottmac, @JosefKaltwasser

Last updated: 2024-03-15T09:38:09+01:00

[datexii]

Comment 1816

Date: 2023-03-16 09:39:33 +0100 From: @JoergFst

For GML Line Strings we have the attributes "srsName" and "srsDimension". However, those two attributes are interesting for all kind of coordinates, thus especially for the PointByCoordinates model. Data suppliers need a possiblity to specify, whther ETRS or WGS84 coordinates are used, and which UTM zone.

[datexii]

Comment 1855

Date: 2023-08-29 10:23:20 +0200 From: @iancornwellmottmac

Josef and Ian had a related discussion - Josef knowing that the GNSS extension included srsName for point coordinates asked the status of the GNSS extension. Since it was published in v3.3 the implication is that is approved, but I don't think that it was ever said that we would definitely bring the contents into LocationReferencing, because most of GNSS is for specialist use cases.

Josef then effectively suggested that the srsName in coordinates should be promoted in v4; Ian said that it seems preferable to have an attribute at publication level; Josef agreed, suggesting an effectively global attribute in PayloadPublication and suggested it that the attribute could also be in point coordinates as optional.

[datexii]

Comment 1856

Date: 2023-09-04 11:17:01 +0200 From: @JosefKaltwasser

Before including this in a v4 update of 16157-2, it would be needed to consider the requirements carefully. srsName in GML Line String has definition: "Specifies the Coordinate Reference System (CRS) used to interpret the coordinates in this GmlLineString" srsName in GNSS extensions has defintion: "Specifies the Coordinate Reference System (CRS) used to interpret the point coordinates.(by default: ETR89-LatLonh)." We can safely assume Lonh to be a typo and supposed to be Long. Both talk about CRS and a name, without any structure requirements. Many users would rather phrase their requirements as providing the EPSG code. If that was agreed to be supported, it should not be modeled as a free text string. As a string it could be modeled by a pattern facet [0-9]{4,5}. Alternatively it could be a NoneNegativeInteger in a suitable range. I know that the EPSG codes are unique only in their category, so the definition would need to clarify that the code is given for a CRS. In all case this is a non-trivial matter and should be verified by experts. It could be an option to have srsName and srsCode in parallel as optional attributes, so users could profile what they prefer.

[datexii]

Comment 1862

Date: 2023-09-26 12:06:18 +0200 From: @iancornwellmottmac

This was discussed at Sep TB meeting. It was agreed that we should add an optional attribute to an extension of HeaderInformation, in CommonExtension. It was also said that we may additionally add the same attribute for each PointCoordinates object, in LocationExtension. For details of how that attribute should be modelled, as inspiration see both ISO 5206 and TPEG, which have both made a similar attribute.

[datexii]

Comment 1922

Date: 2024-03-15 09:38:09 +0100 From: @iancornwellmottmac

We must remember to update the definition of PointCoordinates as part of this issue. In fact it is already inconsistent in v3 because the definition doesn't seem to admit the optional height data we have added.

[LBlaive]

The possibility to go beyond the only CRS based on ETRS89 seems very important. Therefore, it is necessary to find one or several possibilities in the data model to identify the coordinate reference system to use for interpreting the coordinates of the different features (point, linear, area). The “srsName” attribute is tailored for this use. However, the current model (v3) does not specify it. Therefore, there are several possibilities of codification.

ISO/TC 211 has set up a database registering different CRS, and other resources for geodetics (ISO Geodetic Registry or ISOGR). In June 2022, ISO/TC 211, OGC and IOGP jointly published the “Guide to Coordinate Reference System (CRS) Resources” where the different available resources are presented. That means the EPSG codes are found in the IOGP registry (https://epsg.org/) whereas the ISO/TC 211 codes can be found on https://geodetic.isotc211.org/. The OGC resource concentrates on providing a machine-readable interface through a URI resolver and therefore could seem less interesting for this topic. Both resources can be used but there is a need to identified which one is used. A possible solution could consist in prefixing the code by “ISOGR:” and “EPSG:” respectively. A third possibility is to use the corresponding name. A fourth is to use a URI. For example, if we want to encode ETRS89 as stated in DATEX II: • IOGP: EPSG:1178 • ISO/TC 211: ISOGR:217 • Name: ETRF89-LatLonEHt • URI: "http://www.opengis.net/def/crs/EPSG/0/1178">

To deal with this issue, one can define a three-levelled approach:

1. For each geographic feature (point, linear or area) an SRS name (or code) is provided (the most flexible way);
2. For each publication the Header class contains a new attribute “srsName” which is applicable to all the geographic features, except if for one of them the “srsName” attribute is explicitly filled in and, in this case, it overrides the publication default value;
3. If nothing is specified either for the geographic feature or at the publication level, a by default value is applied: “ETRS89-LatLonh”.

Note 1: the “ETRS89-LatLonh” CRS name is correct and it represents a three-dimensional CRS based on (in this order) latitude, longitude and (any type) height.

Note 2: strictly speaking a CRS is not based on a reference system but on a reference frame i.e. here on ETRF89 (and not ETRS89). However, in practice both are used as synonyms.

Note 3: According to the description in ISOGR, ETRS89 covers all the countries of EEA plus the United Kingdom and candidate states in the Balkan peninsula. It does not include Türkeye, however member of CEN.

Note 4: this would imply to completely overhaul the “PointCoordinate” package (through the creation of a GmlPoint?).

Note 5: a specific attention is to pay for some location referencing systems that embed a given CRS: e.g. OpenLR™ states to use WGS 84 as CRS (without indicating which realisation). Is it desirable in such cases to override what is specified by th LRS?