Skip to content

Add Air France/KLM flight schedule#2090

Open
vkrause wants to merge 1 commit intomainfrom
work/vkrause/add-airfrance-klm-ssim-schedule
Open

Add Air France/KLM flight schedule#2090
vkrause wants to merge 1 commit intomainfrom
work/vkrause/add-airfrance-klm-ssim-schedule

Conversation

@vkrause
Copy link
Copy Markdown
Member

@vkrause vkrause commented Apr 17, 2026

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.

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.
@traines-source
Copy link
Copy Markdown
Member

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?

@Lach-anonym
Copy link
Copy Markdown
Contributor

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

@jbruechert
Copy link
Copy Markdown
Collaborator

Should we disable the airplane mode by default before merging this?

IMO yes

@felixguendling
Copy link
Copy Markdown
Contributor

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

@jbruechert
Copy link
Copy Markdown
Collaborator

I think the web interface should be good enough as long as we notify maintainers of the relevant apps.

@vkrause
Copy link
Copy Markdown
Member Author

vkrause commented Apr 18, 2026

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.

@vkrause
Copy link
Copy Markdown
Member Author

vkrause commented Apr 20, 2026

Some observations from the test instance:

  • performance does not seem to have degraded by the global connectivity, and e.g. Berlin <-> Tokyo door to door routing actually works, with the results not being completely off (within the below limits)
  • routed transfers must be on for anything to work even half-way properly
  • routed transfers do not seem to eliminate the minimum transfer times between flights (good)
  • lack of flight network <-> ground network connectivity is the biggest problem by far, and the main reason for weird results
  • the terminal-accurate positions help with connecting to the ground transport network, but are not enough to connect neighboring terminals (e.g. CDG 2E > 2F isn't done as a walk but a CDG > AMS > LHR > CDG flight loop). Extra entries in transfers.txt might help with that?
  • moving the airport center coordinates to the assumed airport entrance will be necessary for airports without terminal-accurate data to have a chance of working at all
  • dominating ground transport is a problem, but currently you need to try hard to actually trigger this given the above issues

@Lach-anonym
Copy link
Copy Markdown
Contributor

@vkrause
Copy link
Copy Markdown
Member Author

vkrause commented Apr 22, 2026

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

@vkrause
Copy link
Copy Markdown
Member Author

vkrause commented Apr 24, 2026

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.

@Lach-anonym
Copy link
Copy Markdown
Contributor

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

@vkrause
Copy link
Copy Markdown
Member Author

vkrause commented Apr 25, 2026

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.

@felixguendling
Copy link
Copy Markdown
Contributor

related motis-project/nigiri#339
I think the fix mentioned there might work

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

5 participants