Feature request: Better support for public transport stop searches

[hbruch]

Intermodal trip planners depend heavily on support for searching public transit stops. Though many public transport stops are already available in OSM (and often with better location precision than the agency data), support in photon currently is somewhat limited:

• Photon already does a deduplication, so only on quay of serveral quaies of the same station is returned, but this is not necessarily the most representative
• For stops, the IFOPT ID is not returned, which would allow trip planners to search for trips starting not only from the returned quay, but all quaies of the associated parent stop
• I'm unsure if nominatim and hence photon has a concept of a stations importance so more important stops are better ranked(?)
• Some stops are still missing in OSM

I see two options:

1. improve OSM stop handling in nominatim/photon by including additional attributes and relations like ref:IFOPTID and railway:station_category and stop_area relation
2. Support import of GTFS data (it contains stops.txt CSV file, importance could be estimated by taking into account number of routes served at a (parent) stop)

I personally tend to option 2. @lonvia @karussell what do you think?

[lonvia]

Public transport data in OSM is tricky. I've largely ignored that so far in Nominatim apart from the simple name search that just works like others. The PT mapping schema in OSM is fairly complex which would in theory allow to do clever merges and stuff. In practice, the mapping is very heterogenous, so that you'd need a lot of fallback and special casing to get something reasonable to work.

Importing the GTFS stops as external data would in theory be possible. You'd still need a Nominatim database for it to enrich the data with address information (if that is even wanted). It really boils down to the general problem of adding external data.

I'm not even entirely convinced that you get the best solution when mixing the stop data with general search. You might be better off with setting up a simplified stop-search-only API and then query that and the generic photon instance in parallel, mixing the results as required in the browser directly.

[2martens]

A first step in that direction would be to allow better filtering of search results. For example, the query "Roßmarkt, Schweinfurt" returns a bus station in the result. It has the tag amenity with value bus_station. Yet I cannot filter by osm_tag contrary to the documentation. If this filtering would work correctly, I could modify an adapter for Digitransit, for example, to translate GTFS stop requests to ordinary Photon requests limited by certain tags.