[Bug]: Itinerary description by single geometry

[werkenr]

Bug description?

When using an itinerary it requires multiple locationContainedInItinerary. It is not possible to have a single gmlLineString describing all used itineraries at the level where you expect it. Currently index=0 is abused to describe all itineraries with the gmlLineString. However, this means the gmlLineString of the first itinerary describes the entire route and not only the first itinerary.

Possible solution: Make it possible to have a complete "description" of all the itineraries using a single gmlLineString or OpenlrBinary at the level of ItineraryByIndexedLocations.

Version

3

[LBlaive]

When considering the only Part 2, it seems important to keep the distinction between “Location”, “Itinerary” and “LocationGroup”. As regards “Itinerary” the definition is “Multiple (i.e. more than one) physically separate locations arranged as an ordered set that defines an itinerary or route.” This definition is consistent with the associated note and seems logic when considering the three child classes of “LocationGroup”: if an “Itinerary” could only contain a “Location” what would be the interest to make such a distinction? A possible solution would consist in splitting up the GML line string instance into two to comply with the existing rules. Another solution (in Part 3) would consist in allowing either an “itinerary” or (XOR) a “Location” as entity associated to “RouteDescription”. Since the DATEX II methodology does not propose the “Union” stereotype (unlike EN ISO 19103) the only way to copy the behaviour is to use “D2Relations” between these classes.

Note: this issue goes beyond the only Part 2 of the CEN 16157 series and should be resolved in conjunction with the considered Part 3 (or Part 8) (see issue no 546).

[iancornwell1]

I think I prefer Rob's proposal to resolve both this issue and #546 by removing the constraint "There must be at least two locations" on the UML comment in the LocationReference diagram.

(Academically then, because then the alternative resolution proposed above wouldn't be needed - that resolution only resolves #546 and not this more general request #545, and I can imagine there could be a small reason to use an Itinerary even with one location, to express the semantics that the location is an itinerary and not just an atomic linear location for example. If however we were considering the solution above then it would be more appropriate to put the constraint on the two relations, not the two classes, and simply have the text "{xor}", the curly brackets expressing that this is a UML constraint, and "xor" (lower-case) being a built-in constraint in UML. Even more academically, I disagree this is "the only way" because one can also aggregate an abstract class with 2 subclasses, but here that would mean 3 new classes and an extra nesting level in the data, so I would not propose that.)

[LBlaive]

@iancornwell1 : totally right your remark about the note links (I cannot explain this choice - my intention was to attach the constraint to the relations). I also thought to use inheritances but with only one intermediate class it would imply multiple inheritances for the "Itinerary" and "Location" classes.

General: I agree with Ian Cornwell the proposed solutions do solve the issue no 546 without solving this issue itself. If we relax the multiplicity between "ItineraryByIndexedLocations" and "Location" to "1..*" I can see some drawbacks in terms of semantics and imbrication. What is the difference between a single-location itinerary and an atomic location? At the beginning, the "Itinerary" and "LocationGroup" classes were created to go beyond the atomic location reference (corresponding respectively to the notion of "set" and "bag" of ISO 19103). A check in the current data model only two shows two packages where this class is used (besides "LocationReferencing"):

• In situation (package "NetworkManagement") associated with "RouteDecription";
• In "ReroutingManagementEnhanced" (package "Classes") associated with "RouteDescription". In case we agree to relax this multiplicity it implies to review the definition ("Multiple (i.e. more than one) physically separate locations arranged as an ordered set that defines an itinerary or route.") and it will imply to add an extra level of imbrication since the "ItineraryByIndexedLocations" class instance contains one "Location" class instance. Another idea to explore is to distinguish between the concepts of "Itinerary" (or route for a diversion = traffic purpose) and the notion of "LocationSet" that would consist of two or more ordered locations (geographic concept).