[Bug]: Various errors in definitions of classes, attributes and enumerations values for location referencing

[LBlaive]

What happened?

Comment reported during the Formal Vote in 2018 by FR (no FR107, FR118, FR120, FR121, FR122, FR123, FR124, FR 125, FR126, FR132, FR133, FR141, FR146, FR147, FR148, FR149, FR150, FR151, FR152, FR153, FR154, FR155, FR156, FR157, FR158, FR159, FR160, FR161, FR163, FR166, FR167, FR168, FR169, FR170, FR171, FR172, FR175 FR177, FR178, FR180, FR182, FR183). See attached document. FprEN 16157-2 Collated Comments_extract_Dictionary_2024-07-23.docx

Version

3

Code of Conduct

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

[iancornwell1]

I have checked all the details and I agree with all except the following (which means that I agree with over 30 comments and resolutions). FR 122 – by resolving FR 124, we may or may not find an improvement for FR 122 which is about naming and defining the SupplementaryPositionalDescription for a NetworkLocation. Today I don’t see what this would say except “supplementaryPositionalDescription” and “Supplementary positional description for the NetworkLocation”, and that is not worth adding. However, if a more specific semantic is agreed I would be happy to add it. FR 124 – about “secondary” in the LinearLocation association secondarySupplementaryDescription - I agree with the issue, but I cannot provide a resolution either. We need to raise this to colleagues to find who understands it. FR 132 – I agree with the issue but I suspect the resolution is not to name an enum because I think the description is simply wrong and there is no enum, and the reference to an enum can be deleted – we should check with the original modeller. FR 150 – I don’t see the issue, so I would need a more specific proposal to consider. FR 153 – I won’t oppose this if others agree, but I sense a risk that others might not. It seeks to define lanes beyond the central axis – is that generally desired? FR 159 – I don’t see the problem FR 160 – I don’t fully understand the comment and why it leads to the proposed resolution FR 168 – the definition already seems to clearly indicate the latter. I also noticed that there are a small number of differences between the FRXX numbers in the issue text above and those in the attached document. I have looked at all in the document.

[LBlaive]

@iancornwellmottmac There were two number errors in the comment text (it was correct on the joined table). Now corrected.

[LBlaive]

This list of issues needs to be considered carefully. For most of them the modification is rather obvious and can be made directly. For a subset, a more detailed analysis can be undertaken before decision: • FR118 & FR125: the requested move of the “OffsetDistance” class seems logic. • FR120 & FR121: the requested additions make sense. • FR122 & FR124: see proposal for issue no 509. • FR141: see proposal for issue no 508. • FR150: possible proposal; “Collection of supplementary information that improves the location definition.”. “Precision” in this case is too limitative as stated in ISO/IEC Guide 99. • FR151: possible proposal: “Information on a set of one or more roads sections. This information shall not be presented when it is already present with the considered location referencing system” • FR152 to FR160: see proposals for issue no 510, • FR168: to solve (no current proposal as the comment provides two possible interpretations). • FR171: delete the entry for emergency lane. • FR177: the change of the “roadway” instances by “carriageway”. It is to note the comments FR152 to FR160 are closely linked with the issue no 510.

[iancornwell1]

FR150 – OK FR151 – OK FR159-160 – I now understand better from issue #510 where we discuss these points.

[LBlaive]

Issue 132:

I agree with Ian Corwell. There is no enumeration targeted. Indeed, the definition is an approximate copy of the OpenLR White Paper stating DNP: "The distance to next point (DNP) field describes the distance to the next LRP in the topological connection of the LRPs. The distance is measured in meters and is calculated along the location reference path between two subsequent LR-points." (logical format) or later in the physical format: "The DNP attribute measures the distance between two consecutive LR-points along the location reference path as described in the logical format." Proposed new text: "The DNP attribute measures the distance in metres between two consecutive LR-points along the location reference path." (remaining text deleted).

Issue 168:

To decide between both possible interpretations (and then improve the current definition), I have checked in the French Code of highways: it is stated (Art. R422-1) vehicles are considered as slow if their current speed is below 60 km/h for any reasons ( (longitudinal gradient, weight, engine power...). It is a dedicated lane. The speed limit for using this lane very probably varies among countries. Thus my proposal (modifications in bold): "In a lane dedicated to vehicles the current speed is below a limit fixed by regulations."

[iancornwell1]

132 OK. 168 (slowVehicleLane) Re-reading this I now can see the ambiguity in the original, which I did not spot on my first reading ("In a lane dedicated to vehicles that are not permitted to exceed a fixed slow speed.") I agree that the proposal removes the ambiguity. Does everybody agree that the proposed interpretation is the desired one in all cases though? (A minor comment is that to preserve the grammatical effect of the definition we should change "the" to "whose" in the new proposal, and I would also change "is" to "remains". So: "In a lane dedicated to vehicles whose current speed remains below a limit fixed by regulations.")