Conversation
Converted from the SSIM schedule on transport.data.gouv.fr and airport/ airline data from Wikidata, using https://github.com/public-transport/ssim-converter/. Depends on public-transport/gtfsclean#18. Implements #619.
|
Have we verified that this doesn't dominate too many train trips or leads to considerably longer query times? Should we disable the airplane mode by default before merging this? |
|
It could be great to differentiate public service from purely economical one, so for example in Norway the itinerary could still show some flights that were not made strictly to compete with land transport. This requires some (probably extensive) manual work... Take notice that the same situation happens at railways - let's take Poland as an example, where there are IC and EIC trains. The first category is financed by state, the second is run at financial risk. Both are intercities and in most cases have generally the same travel times, even if EIC is "express". But IC is available at reasonable price and EIC is ridiculously expensive. Then there are coaches - let's say we disable them in the itinerary because we hate ALSA/Blablacar/Flixbus/etc. Some regional feeds however have their local lines classified as coaches (like Volánbusz), so this affects reaching the destination. One of the solutions can be agency/line filtering in MOTIS, which has been mentioned a couple of times already... |
|
Should we disable the airplane mode by default before merging this? IMO yes |
for the MOTIS Debug UI we can do this for the API it would be a breaking change that requires API versioning but waiting for clients to switch to a new API version doesn't really make sense because then they could also disable airplane mode if they don't want flights |
|
I think the web interface should be good enough as long as we notify maintainers of the relevant apps. |
|
Disabling flights by default makes sense IMHO, we already have the case in Norway with flights dominating everything else. Our clients actually do that already. The other problem is connectivity between the flight and ground networks. That's also not new, but becomes more apparent the more flights are added. I was hoping that the terminal-accurate data would help with this (e.g. CDG T2 flights are now practically on the same location as the CDG railway station), and if so we could apply e.g. the entrance heuristics we have in KDE's code already to the airport locations here as well. However, Marcus' test results on Matrix from yesterday suggest that this even still fails for CDG, so this needs further investigation. I'm relying on the test instance for this though, as given the global scope you basically need all ground transport and full OSM data to properly test things. |
|
Some observations from the test instance:
|
|
There's a new version now that uses the improved airport coordinates we use in KDE Iitnerary, which attempt to find the "entrance" with OSM-based heuristics, in places where we don't have terminal-accurate data. This should significantly improve e.g. Amsterdam, Gdańsk and Stockholm. Also, https://public-transport.github.io/ssim-converter/ now has a debug view for all the stop points. Click on them to see multiple overlapping points as well as links to the Wikidata items providing the terminal location (if any). |
|
Deployed on test instance now, connectivity on many airports significantly improved (routed transfers are still mandatory though), flights dominating other alternatives starts to be the dominating problem now. Another issue becoming more prominent now are creative solutions to bypass the 1h minimum transfer times, such as leaving the airport for a quick trip around the parking lot with a local bus. The screenshot above shows this in AMS, to allow a 15min connection there. |
|
Would it be possible to add a one hour buffer every time when entering an airport and a connecting minimum time when staying in it? This might partially fix the dominance issue |
Check-in times are currently not possible, but are on the roadmap for MOTIS, as e.g. Eurostar has the same need. Minimum transfer times are in the generated GTFS feed here already, but the router has found a way around them unfortunately. But yes, that would certainly help with some of the dominance issues, especially on shorter distances. |
|
related motis-project/nigiri#339 |

Converted from the SSIM schedule on transport.data.gouv.fr and airport/ airline data from Wikidata, using https://github.com/public-transport/ssim-converter/.
Depends on public-transport/gtfsclean#18.
Implements #619.