[Bug]: Class "PointCoordinates" and 3rd dimension

[LBlaive]

What happened?

Comment reported during the Formal Vote ballot in 2018 by FR (no FR069).

There seems to be an error in data modelling of the "PointCoordinates" package: the "HeightCoordinate" class needs to be associated with "PointByCoordinates" (not present currently) because it does not comply with the current definition of these classes: there is no meaning to associate height coordinate with "PointCoordinates" that represents a pair of planar coordinates. Moreover, in several class diagrams where the "PointCoordinates" class is used (e.g. in the "LocationReference" package where "PointCoordinates" are introduced as "coordinateForDisplay" or in the different sub-models for TPEG-Loc, OpenLR™, … ) the fact of associatiing the "HeightCoordinate" class introduces this third coordinate whereas only planar coordinates are expected by definition.

Solution: Delete the association between "PointCoordinates" and "HeightCoordinate" and create an association between "PointByCoordinates" and "HeightCoordinate" (same multiplicity). Rename the package "PointByCoordinates" when moving the class of the same name inside.

Remark: it is also possible to overhaul the package more in depth by adopting the corresponding definition from GML (GM_Point) that will improve the consistency with the other classes of the "Gml" package.

Version

3

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[iancornwell1]

I agree that the addition of HeightCoordinate to PointCoordinates broke its definition. Whether we expand the definition of move HeightCoordinate could depend on other usage of PointCoordinates outside PointByCoordinates. The other uses are: locations for display (which do not need height), and specific places in OpenLR, TPEG, and linear referencing. If it would be consistent with OpenLR, TPEG, and linear referencing to allow height at those places, then we should just expand the definition. On the other hand of OpenLR, TPEG, and linear referencing explicitly only have lat & long at those specific places, then I agree we should move Height to PointByCoordinates, and keep PointCoordinates as planar coordinates as its definition currently says.

[LBlaive]

This issue needs to be considered. The two ways to solve this issue are the following: • If the current model is confirmed, i.e. the “HeightCoordinate” class continues being associated with “PointCoordinates”, it implies to review the “OpenLR” and “TpegLoc” packages to allow for a potential third coordinate and especially the different definitions. An important consequence is also to diverge from the original sources for the location referencing systems, i.e. the OpenLR™ White paper (version 1.5) and CEN ISO/TS 18234-6 where all the coordinates are planar; • If the “HeightCoordinate” class is therefore associated with “PointByCoordinates”, there is quite nothing else to change and it is the recommendation.

The other proposed solution represents a bigger change in modelling but has some advantages, including a better consistency with ISO/TC 211 standards.

Note 1: it would be wise to transform the current “PointCoordinates” package into a “PointByCoordinates” package (with the “PointByCoordinates” class as top class).

Note 2: it does not seem incompatible with EN ISO 19148 to add a third coordinate to the points used with linear referencing.

[LBlaive]

Hereafter the corresponding updated sub-model:

[LBlaive]

Another possible sub-model (closer to GML):

It implies the creation of a new data type (GmlPos). It would also be possible to name the "PointCoordinates" class as "GmlPoint" but it would imply to propagate this modification in several class diagrams.

[iancornwell1]

Our call showed a variant where gmlPos above was replaced by coordinates : Decimal [2..3], which had support. It dawned on me (after Josef's remark) that with this model you can have an SRS of OSGR (the most common in UK) and have coordinates that are are not latitude and longitude but easting and northing. That is very useful (although also has drawbacks of divergence).

[LBlaive]

Here is the variant mentioned by Ian Cornwell:

A modification proposed could consist in grouping the two classes "PositionConfidenceEllipse" and "AltitudeConfidence" as they stem from ETSI CDD (ETSI TS 102 894-2) so they are managed together. This change allows an independence from the "PositionAccuracy" class (that stems from EN 16803-1).

Open questions:

• Regarding the type of the "coordinate" attribute it is not clear if the data type is better "Decimal" or "Float";
• Is there a need to introduce an exclusion (XOR) between the "PositionAccuracy" and "ConfidenceInformation" classes?
• Regarding the "PositionAccuracy" class it is not obvious if there is still a need to keep "accuracyPercentile50" and "accuracyPercentile75".

[iancornwell1]

Usually the answer for Decimal or Float is obvious, but here it's perhaps not so obvious. And there is a 3rd possibility: Double. One way of answering is to say that we are replacing the old structure where latitude and longitude were Float, and so in the scope of this issue here we do not have any reason to change, and we keep Float. But as a separate issue it is interesting. It depends on the use case of course. There might be use cases where exact reproduction of a finite set of digits is important, but unless there are strong views about this I think we should use Double, which is much more efficient and sufficiently accurate, rather than letting those very rare use cases spoil the efficiency for everyone else. Although we used to use Float, I think it is not accurate enough for some coordinates use cases, and despite what I just said I think those are likely enough to warrant the change which has very low cost. If you stay always in lexical mappings like XML then Float may seem fine, but at some stage you may convert into programming language types and then float is limiting. Double is twice the size of Float, but very efficient because it is very standard and well optimised. Comparing Decimal, if we consider C# it is twice the size of Double but more complex and not so well optimised, so quite a bit more to process; with Java (BigDecimal) it is worse again because the size is variable and much bigger. A quick check of coordinate processing libraries suggests that Double is the most common type for individual coordinate components.

[LBlaive]

@iancornwell1 Your explanation sounds well. As regards geographic coordinates the integer part of a value is limited to 180 for longitude and 90 for latitude but the mantissa needs to allow for seven decimals to obtain a centimetre accuracy (it is the choice made by ETSI TC ITS and it looks fine considering the needs of automated driving systems). As regards map coordinates (or projected) usually the unit is "metre" (for UK I do not know the practice). That implies to theoretically be able to represent values until 20 000 km for easting (or 2 x 10^7 in metres) and again to obtain centimetres 2 decimals. For northing it is the half. A quick computation shows 2^28 is enough to represent the maximal value in centimetres of easting. If nobody complains I will change for "Double".

[iancornwell1]

That further analysis reminded me to check whether Float resolution for lat/long is really an issue. The smallest amount that a float representing latitude can reliably distinguish seems to be 1.7m (according to a source, I haven't checked the maths myself). That is sufficient for most use cases, but not for all, and the cost of moving from Float to Double is low.

[LBlaive]

The value of 1.7 m for longitude represents 10^-5 degree at the equator ( the same angle intersect an arc of 1.1 m at latitude 45°). It was the accuracy considered as sufficient for applications like navigation or traffic information. It is not sufficient for more advanced applications like C-ITS or automation; it is the reason why e.g. ETSI TC ITS considers an accuracy of 10^-7 degree (tenth of microdegree), i.e. 1.7 cm at the equator or 1.1 cm at latitude 45°.