[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).

[werkenr]

We want to be able to describe the location in multiple ways, so the {xor} solution won't suffice. In a single message we want to use both a single gml-linestring to describe the location for service-providers and the alertc description for the road operators.

Example below: The road-segment in red is closed from the south, the rerouting is described in both alertc itineraries (orange) and a single gml linestrings (purple).

[iancornwell1]

Now understood, so while you can express one LinearLocation with different multiple alternative location referencing methods, today you can't express one Itinerary with multiple different alternative location referencing methods.

[JosefKaltwasser]

Let's be more precise: with the proposed change of multiplicity you can express an Itinerary with one LinearLocation, and you can express this in different ways, e.g. a GmlLineString and a OpenlrLinear are possiblr. BUT - the definition of class SingleRoadLinearLocation says "Location representing a linear section along a single road with optional directionality defined ...". Hence, those systems - including AlertC - are not supporting linears that change roads. You could wonder whether the problem of the NL colleagues is really a problem of the Itinerary or whether it is more a problem of how the LinearLocation is specified. Note that the multiplicity for AlertCLinear components is 0..*. You could actually create an Itinerary with a GmlLineString and a SingleRoadLineraLocation containing three AlertCLinears. It would just violate the naming and the definition.

[iancornwell1]

With this issue better understood, the call 21/11 looked again at Loïc’s model proposal above. A refinement offered by Loïc was that what is called “LocationSet” above would be better as “LocationSequence”. If the locations contained in sequence are to be physically distinct locations then I see hardly any semantic difference between the concepts of LocationSequence and Itinerary. If all other aspects were to remain as shown above, I don’t think that could represent the example given to clarify the Dutch requirement, but further changes were mentioned in the call. Near the end of the discussion, removing the constraint was mentioned, and if this meant removing the {xor} then I can see that would then allow representation of the 2 AlertC + 1 GML example (but the remark might have been talking about the original constraint on Itinerary). Changing multiplicity from 0..1 to 0..* was also mentioned, I think for Itinerary to LocationSequence, maybe for Itinerary to Location as well, and that would also support the multi-method requirement. If we were doing that, the associations should get a new comment like the ones in LinearLocation etc, saying that the multiples are for different representations of the same physical locations.

Given #546, and the support for the idea that it is useful and semantically valid to have an Itinerary consisting of one linear location, that suggests that in the proposed design above we should change locationContainedInSequence (set) from 2.. to 1.., and then we don’t even need the Itinerary to Location association, if we just change the 2.. to 1...

Then we would have a design where Itinerary (which is not itself a LocationReference so is used only by Rerouting) is allowed to be a special case that can use multiple heterogeneous location referencing methods, while a LocationSequence is not and can only use a single method. That seems a bit arbitrary to me. This fact that some linear location methods can express using 1 while others need many: doesn’t that potentially have impact everywhere we want to use locations? I would have thought the fact would lead us to want to support multi-method location sequences anywhere we use LocationReference.

Following that thought, we might keep Itinerary as a specialisation of LocationReference like today, with its “ByReference” and “ByIndexedLocations” subclasses, but a mechanism added so that ByIndexedLocations can somehow support heterogeneous multi-method specification of the same physical route. I will stop short of taking the final step to propose exactly how to do that, because Josef’s latest comment contemplates an alternative solution where we change LinearLocation instead...

[LBlaive]

The NDW example above confirmed with their need as it was expressed and not directly from this issue (it goes beyond). Starting from the model presented this morning and amended like I suggested, it is possible for a given itinerary (or journey) to:

• express it as single location let's say as a GML line string (the purple line of the example); AND/OR
• express it as a sequence of three locations using e.g. Alert-C. It is also possible to together define the single location by using a GML line string and an OpenLR linear location. As well, each location of the sequence can be represented as e.g. an Alert-C linear location and a linear location defined by a Linear referencing system. What is not possible currently is to represent an Itinerary instance by two different sequences, one of e.g. three Alert-C locations and the other of two linear location using linear referencing, because there is 1 for 1 correspondence between each instance of Location. The following diagram summarises the new proposal:

All the child classes of Location, LocationGroupe and LocationSequence are not presented here to clarity reasons. Another advantage is to keep the model of Part 3 unmodified and there is no need to change the LinearLocation package. The two association names have been also shortened (independent proposal).

[LBlaive]

Let's be more precise: with the proposed change of multiplicity you can express an Itinerary with one LinearLocation, and you can express this in different ways, e.g. a GmlLineString and a OpenlrLinear are possiblr. BUT - the definition of class SingleRoadLinearLocation says "Location representing a linear section along a single road with optional directionality defined ...". Hence, those systems - including AlertC - are not supporting linears that change roads. You could wonder whether the problem of the NL colleagues is really a problem of the Itinerary or whether it is more a problem of how the LinearLocation is specified. Note that the multiplicity for AlertCLinear components is 0..*. You could actually create an Itinerary with a GmlLineString and a SingleRoadLineraLocation containing three AlertCLinears. It would just violate the naming and the definition.

Not only the naming and the definition but also the constraint applied the different assoctions: "Any LinearLocation must have an instance of at least one of these classes. If using multiple instances, producers must take care to ensure they represent the same location." By construction, the different systems associated to "SingleRoadLinearLocation" are by construction/definition based on the fact there is a single road associated (cf. e.g. EN ISO 14819-3 for Alert-C). The "0..*" for Alert-C and "LinearWithinLinearElement" are only due to the possibility to use different Alert-C location tables or different linear referencing systems for the same geographic feature. I do not advocate to modify the "LinearLocation" package to keep consistency with other two ones and because the added value would be limited compared to the drawback of a too huge modification.

[iancornwell1]

In a multi-road route example, the most recent version of the proposal would allow one Itinerary to offer any number of alternative multi-road linear methods (in practice up to 2 because there are only GML and OpenLR available), via one LinearLocation, and at the same time any number of linear methods via one LocationSequence with multiple LinearLocation, but only if those linear methods used exactly the same boundaries for every individual LinearLocation making up the route. Is that constraint something that we are happy with?

Anyway, I still have the concern I expressed above - why allow this multi-method flexibility for rerouting and not other uses of location sequences? If we liked the idea of having 1 sequence and/or 1 Location, I would just move the proposed new Itinerary-Location association from the proposed new Itinerary class to the ..ByIndexedLocations class. Then the new extra class called Itinerary could disappear, and we could decide to keep the current Itinerary naming or rename to LocationSequence. (Aside - In English an "itinerary" normally has times as well as activities or locations, but it is well established in DATEX so I think that's not really important.)

[iancornwell1]

We'd need some renaming, something like this. I'm not sure I would have proposed this model from scratch but it is what I would favour if we liked the 1 sequence and/or 1 Location idea as I currently understand it. Hopefully this at least helps further clarify the intentions above.