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
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. |
Correct a typo and make documentation clearer
TuThoThai
left a comment
TuThoThai
left a comment
There was a problem hiding this comment.
LGTM after a tiny documentation correction
skinkie
added
the
needs documentation update
|
@ue71603 @TuThoThai @duexw for documentation perspective there is an implication with addition. This means that a TimeDemandType gets closely coupled with one (or more) ServiceJourneyPatterns, while there hasn't been an explicit relation before. The only relation existed because a ServiceJourney would specify a ServiceJourneyPattern and a TimeDemandType. Technically the relationship between ServiceJourneyPattern and TimeDemandType does not have to exist. Nothing would stop you to model the entire timing model for all links in the network in one TimeDemandType. That this in practise never happens has to do with the fact that transit modellers don't publish true timing but a percentille with respect to the start of the trip. |
|
@skinkie I agree that these only should be used when it is absolutely necessary (e.g. when there are two visits). Do I need to make the documentation comment clearer in that respect? |
|
I don't really care that there is an alternative way to model it. What we need to clear about is how the relation between ServiceJourneyPattern and TimeDemandType should work. That is a bigger topic than this pull request. |
|
@ue71603 the point being ;-) you are at an earlier commit than I am now. I updated to v2.0. |
|
I understand. I will use the latest as well and commit the new one to the branch. |
6 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?