Prefer GTFS entrances for footpath generation

[DomeQdev]

This PR adds a prefer_gtfs_entrances config option. When enabled, MOTIS will use station entrances from GTFS (location_type=2) for generating pedestrian footpaths, falling back to OSM only if GTFS entrances are not available for a station.

This improves intermodal routing accuracy in areas where GTFS entrance data is more reliable than OSM. To ensure good performance, the implementation routes from the single closest entrance to a neighboring station, avoiding a costly computation from all possible entrances.

Fixes #919

[felixguendling]

There's no real value in routing to entrances if there's no support for pathways.txt for in-station routing.

Additionally, this seems to only deal with compute_footpaths in the preprocessing which is not sufficient as first and last mile footpaths will still behave like before.

I'm also not sure if only routing to a closest entry based on distance is a good choice.

Overall I would not like to tackle this problem this way as as long as we do not have a proper modeling of pathways.txt in nigiri.

I would also recommend to discuss your approach before starting to work on something for several reasons:

• what's the best way to implement it?
• who else might already be working on something in the same direction?
• does this have chances to be merged at all?

As @traines-source mentioned, the preferred way is to fix the modeling in OSM. OSM is way more precise and enables seamless routing between first/last mile and transit and in/outdoor.

[DomeQdev]

I definitely see your point about the architectural purity and the long-term goal of having full pathways.txt support. That would be the ideal solution.

However, I'd like to argue for the immediate practical value of this feature from a user's perspective, especially for underground stations like metros.

You're right that we lose detailed in-station routing. But once a passenger goes underground, they lose their GPS signal anyway. At that point, they stop relying on their phone for turn-by-turn navigation and start following the signs inside the station. The most critical piece of information the app can provide is which entrance to use to get to the station in the first place, and then maybe a general direction towards their platform.

For a passenger, the routing from the entrance to the platform can be a simple straight line on the map. They won't complain, because they understand it's an abstract representation of an underground path. Apps like Citymapper do this all the time – they guide you to the correct entrance, and the rest is up to station signage.

The problem with the current OSM-based approach is that for many stations, it can't even tell the user which entrance to head for. As in the Warsaw example, if OSM data is poor, MOTIS might not find any entrance, leaving the user completely lost on the surface. Guiding them to the correct GTFS-provided entrance coordinates is a huge improvement over guiding them to a generic station center point, or not finding a path at all.

Regarding the first/last mile inconsistency, that's a fair point. I'd be willing to look into extending the logic to cover that as well if we could agree that the general approach has merit.

What do you think? Isn't providing the correct entrance information a significant enough user benefit to justify this step, even before full pathways.txt support is available?

[felixguendling]

I agree that for a user it's probably better to be routed to the entry if we compare it to the "dummy leg" case where there's no route found at all.

However, I would distinguish here between

• Routing: here only two questions need to be answered -> what should be connected with which transfer time? The exact path is not really relevant. Since walking speeds differ too much from person to person and under different circumstances like crowdedness of a station, these times can only be a rough estimate at best. For this purpose, routing to the entrances or to the track location doesn't really matter as we only store transfer times for each profile, not the exact route.
• Navigation: guiding the user when she/he is walking around, trying to find the place where to enter the next/first trip. Here, it really matters to tell the user which entrance to use.

The code changed in this PR at the moment deals with the first case (and specifically only the transfer case, not first/last mile). So the route shown to the user will still not be the one leading to the entrance.

The code you adapted in the your other PR (to ignore level information if the first try with exact levels didn't work) seems a way better place to do this as those are the routes actually shown to the user. Then maybe the better fallback order would be:

• routing with exact levels to the track
• routing to entrances without levels (level wildcard)

Currently, entrances are not extracted in nigiri. So anything you want to do with entrances will not work unless this check in nigiri is removed:
https://github.com/motis-project/nigiri/blob/c1c639aee3ba83af56474f938a120895aad0eefa/src/loader/gtfs/stop.cc#L224