[Bug]: Issues in the "SupplementaryPositionalDescription" package

[LBlaive]

What happened?

Comment reported during the Formal Vote ballot in 2018 by FR (no FR072, FR073, FR076 and FR077). Besides the issue already reported as no 509, the corresponding package raises several issues:

• The "directionPurpose" attribute of the "SupplementaryPositionalDescription" class duplicates somehow the attributes "directionAtPoint", "directionOnLinearSection" and "tpegDirection" (using "DirectionEnum" ). Especially it is unclear how to distinguish the similar values like e.g. "inbound" vs. "inboundTowardsTown" whereas the provided definitions look very similar. Solution: remove the attribute and the corresponding enumeration.

• The information provided by the "RoadInformation" class seems redundant with some other classes. E.g. "roadDestination" seems to duplicate the "Destination" class of "NetworkElement" and "roadNumber"/"roadName" is also provided for linear referencing methods. On another hand the information is also available for ALERT-C coding (in the location table) and for TPEG (through the descriptors). Each time the same information can be defined in several places it complicates the decoding process and may introduce inconsistencies in data. Solution; Remove the "RoadInformation" class.

• A new class ("NamedArea") has been added to this class diagram without explaining its interest and its usage. Especially the association with "SupplementaryPositionalDescription" is not named nor defined.

• In the "SupplementaryPositionalDescription" class the "sequentialRampNumber" attribute is typified to be a "NonNegativeInteger". There are cases in France where the corresponding junction number is not an integer number (e.g. "10.1") or includes a letter (e.g. "10a"). Solution: Replace the "NonNegativeInteger" data type by a "String".

• The attribute "positionOnCarriageway" defines a position on the carriageway although it is present in the class "SupplementaryPositionalDescription" class. This can work fine in case of a single carriageway road but may become much more difficult to interpret for a multiple carriageway road (especially if both traffic directions are impacted). To solve this issue the best is to move this attribute in the "Carriageway" class or to consider it for roadways.

• As well, the definition of the "LengthAffected" seems too restrictive as it is applied to carriageway (and not to roadways") and it is related to traffic element, which prevents its use for other usage types.

Version

3

Code of Conduct

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

[iancornwell1]

• A question of approach arises here. We try to respect external location referencing systems, modelling them in a DATEX II approach. We also add optional things like SupplementaryPositionalDescription at a more general level so they can be attached to any kind of NetworkLocation, for specific DATEX II requirements not covered by the external location referencing systems. A feature like direction purpose may or may not be clear from the directions in some of our specific location referencing models, but anyway it is not in all of them, and there was a requirement to add it. I think it would be useful to recap on the location referencing model approach to use of external methods vs using our own, and ideally write it down, before we decide on this issue.
• RoadInformation allows associated road information to be specified for a point as well as for a linear. But I agree that roadDestination seems to be duplicated given you can have destination.areaLocation.areaName in NetworkLocation. Some may think that the potential duplication is worthwhile to get the information about a road entity in one object.
• I agree that naming and defining the NamedArea associated with SupplementaryPositionalDescription would be an improvement. I assume that the intention is that it is the area that the location is contained in.
• The proposal for sequentionRampNumber changes the semantics as well as the type. I wonder if the originators of the feature depend on this being a number.
• I see the minor issue stated, but I just want to check that moving to Carriageway is acceptable - Carriageway is used when you know and supply the kind of carriageway. Is there any scenario where you want to give the relative position without the kind of carriageway? Hopefully not, in which case I support the proposed move.
• lengthAffected - I agree we should modify the definition to address both parts of the issue.

[LBlaive]

There are a lot of issues raised in this comment and related to the package itself. However the “Lane” class is not considered here. • Issue on “directionPurpose”: the overlap with “DirectionEnum” is obvious since its two values are also present (with slightly different names). Moreover, most of location referencing systems has got a direction attribute (differently featured). Moreover, the possibility to associate a “Destination” instance to a “NetworkElement” allows for such a use. It is suggested to purely remove it. • Issue on “RoadInformation”: the contained attributes duplicate more or less attributes present in other parts of the data model. E.g. “roadName” and “roadNumber” are also present in “PointAlongLinearElement” and “TpegDescriptor”. “roadDestination” duplicates the “Destination” class in every case and should be removed. There is therefore a risk of redundancy/inconsistency. Its use should be strictly limited to location referencing systems where the information is not already present (directly or indirectly: e.g. "GmlLineString"). • Issue on “NamedArea”: in absence of any explanation/example it is impossible to assess the interest of such an addition. If kept after considering Ian’s comment, it is necessary to improve the definition of the corresponding association (redundant). • Issue on “sequentialRampNumber”: the data type modification seems necessary to accommodate some specificities in France. Moreover, the attribute name may be challenged as this number is not always local. Alternative proposal: “exitName” or “junctionNumber” or “junctionSlipRoad”. • Issue on “positionOnCarriageway”: although its name it is located in the “SupplementaryPositionalDescription”. Its natural place should be in the “Carriageway” class. It specially makes sense in case of multiple carriageway roads as suggested in the comment. • Issue of “lengthAffected”: a possible definition could be: “Length (measured in metres) of roadway affected by the associated feature.”. Another solution could consist in moving it to the “Carriageway” class but a possible drawback is to lose a global perception of the impact (intention to clarify).

Note: it is important to make a clear distinction between the notions of "orientation" of the geographic linear feature representing the road element, and the "traffic direction(s)" (or direction(s) of traffic flow) applicable to this road element.