Add StopPointInServiceJourneyPatternRef to JourneyWaitTime for stops visited 2 times in the same ServiceJourney with different wait times#1031
Conversation
ue71603
added
the
enhancement
ue71603
changed the title
|
Do you really have 2 WaitingTimes at the same stop in one journey? Can you give an example from Switzerland? In NL we have 2 or more TimeDemandTypes, but this is not on the same journey. |
|
Wilfried's example: The journeys visit "Avenches, Gare" twice, obviously the vehicle does a loop. For whatever reason they do not have a waiting time at the first visit, but at the second visit they wait for 4 minutes. This situation occurs quite often in regional bus services. How do you express this using time demand type? In VDV 462 it works, because we put the waitTimes Element below StopPointInJourneyPattern. |
|
In the Netherlands we solved this exact case by requiring two disctinct ScheduledStopPoints A and B linked to the same Quay in their respective PassengerStopAssignments. In that case, you can link a WaitTime X to SSP A and a WaitTime Y to SSP B. |
|
@duexw Whatdoyou think? I don't think it should be done that way. All other attributes are not in ScheduledStopPoint that are relevant for single journeys. |
|
I had a discussion with @skinkie and he thinks we should it do as proposed here and not with two different ScheduledStopPoints. |
|
We have the same issue in VDV 452, and up to now it is often solved by creating a "virtual" stop point for the second visit. However, this introduces follow up problems, as in reality there is only one stop point. For instance, in AVM systems you have to assign a different stop id to the virtual stop point, this again does not match anything found in the central stop register and so on. I therefore approve of the solution proposed here. |
…correct element type
| </xsd:annotation> | ||
| <xsd:sequence> | ||
| <xsd:element ref="TimingPointRef" minOccurs="0"/> | ||
| <xsd:element ref="StopPointInJourneyPatternRef" minOccurs="0"> |
There was a problem hiding this comment.
I don't think this should be a sequence. I think it should be a choice. I think I can also make an argument for TimingPointInJourneyPatternRef.
There was a problem hiding this comment.
@skinkie TimingPointRef is always present. This is in our examples a ScheduledStopPoint (as that's the level where the TimingLinks are described mostly. Borderpoint is also possible. So this allows us for the WaitTime to anchored to something that remains mostly static.
For JourneyPattern variations we need an additional element. I modeled it now as a choice.
Indirectly one could go to the ScheduledStopPoint also thought those structures. However, if somebody has not implemented this edge case, then they are lost. So I prefer to have to have the TimingPointRef separatly.
Can you live with that? PR updated.
skinkie
left a comment
skinkie
left a comment
There was a problem hiding this comment.
I would want a small example here too.
|
Hi Stefan, However, I would not allow for wait times at any type of point, as it would open quite a few issues. |
5 participants
In some cases the WaitTime is different if a stop is visited multiple times within a ServiceJourney. When modeled with TimeDemandType then two WaitTimes are needed e.g. first visit 1 minute and second visit 4 minutes, because change of driver.
In those cases (and only those) a StopPointInServiceJourneyPatternRef should be filled in.
Is this ok? Other ideas?