Open t2gran opened 10 months ago
Are you aware of the feature flag ConsiderPatternsForDirectTransfers
. It does something similar to what you need.
The ConsiderPatternsForDirectTransfers : false
will make OTP work (I have tested it). But, this is not a good solution. Having features witch does not support RT updates are probably not a good idea.
We are going to do a performance test to see the effect of turning ConsiderPatternsForDirectTransfers
off. The real fix to this problem is to generate transfers if change in a pattern visit a new stop and that stop is not serving any other patterns/does not have any transers.
This is related to issue #4040 and PR #4421. The ConsiderPatternsForDirectTransfers
was added in this PR and the logic was improved. But, if this is not improving the performance, then it is probably not worth it.
The number of stops/transfers after building with ConsiderPatternsForDirectTransfers
turned off/on:
"ConsiderPatternsForDirectTransfers" : true
DirectTransferGenerator: 1m16s
Transfers: 598 436
Stops: 95 268
"ConsiderPatternsForDirectTransfers" : false
DirectTransferGenerator: 24s
Transfers: 2 642 715
Stops: 99 198
I also run 5000 requests for each of the configurations, but the results wary too much to be useful. When turned on, it is faster but not by much.
@t2gran it's interesting how the feature seems to affect the number of stops, but I guess it's the number of stops related to a transfer that is displayed?
In general the transfer "pruning" has some edge cases that aren't properly working (potentially excluding optimal solution) even without realtime, if the patterns have some kind of geographical loop.
I recall from my experimentation that it impacts performance, with the default transfer maximum duration of roughly 45mn, all stops likely connect to all stops in a city. Keeping the "best" transfers between patterns can really reduce transfer expansion and the transfer optimisation step eventually helps picking the best transfer point.
I feel that adapting relevant transfer when processing realtime shouldn't be too hard also, aren't we already doing it for realtime added pattern (gtfs timetable snapshot source)? The list of patterns added by realtime is known.
Maybe instead of pruning transfer at build time, a subset of all transfers could be selected for a given day of operation in the transit layer and updated depending on realtime data.
Maybe instead of pruning transfer at build time, a subset of all transfers could be selected for a given day of operation in the transit layer and updated depending on realtime data.
Yes, this one possibility, not sure if keeping this for each day will be necessary. But, we can do this is steps. The first step will be to add transfers for realtime changes. If this is inefficient we can cashe the transfers from build-time.
The last publication here is also relevant to this question (Delay-Robustness shortcuts (e.g. transfers pruning/constraint)) https://github.com/kit-algo/ULTRA
This use case will likely happen in ferry traffic due to weather conditions or closed roads. The ferry operator will cancel the planned services, and new extraCalls will be sent in SIRI ET. The new ones can include new stopPlaces/quays that are not in any planned data.
Norled is working to send this correctly in SIRI.
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days
Description
A normal use-case is that a train changes platform(stop) using a real-time update. This works fine, normally. But, if the new stop does not have any trips using it, a problem occurs. OTP pre-compute transfers before starting the router. But, only transfers witch is "optimal" is added to the list of regular transfers. So, when the update happens the new stop is an island - with no transfers in/out of it. In the test data below this happens at "Arna" railway station. The new stop("NSR:Quay:107764") is not used by any other trip in the system. The trip search from Bergen to Voss works fine until the update and platform change is applied. Then, no results are found.
Version of OTP used (exact commit hash or JAR name)
dev-2.x
with #5460 - The file loader is needed to load the Siri ET update.Data sets in use (links to GTFS and OSM PBF files)
The dataset is edited to a minimum, this make it easier to debug what is happening.
Transit data: netex.zip
Update: et-update-arna-platform1-to-3.xml.zip
No OSM data required to test this.
Router config and graph build config JSON
OTP Config
OTP Build Config
OTP Router Config
Steps to reproduce the problem
realtime=false
.Query
VYG_VYG-Line-45_R40_Bergen-Voss-Myrdal-Al.xml
file, by including the last commented out ServiceJourneyid="SJ-1"
.realtime=true
.