Feature idea: Filter stops by the transport modes they are served by (and more)

[schaerfo]

Let's see if Github discussions are a good place to discuss feature ideas instead of the matrix channel 😃

I think it would be useful for the geocoding endpoint to be able to filter stops for the transport modes that serve it. For example, it is annoying to search through all the bus stops of a city when you are only searching for train journeys in the first place.

Since we would be storing which transport modes serve each stop, this information could then also be used to show the available transport modes for each stop, e.g. in the trip endpoint. The v6.db.transport.rest API of old also offered this.

When briefly looking into how to implement this, I noticed that the adr module would need a new dependency on nigiri, mainly for the clasz enum and associated functions. Since I was hesitant to add this dependency, I wanted to discuss the implementation first.

[felixguendling]

Since clasz_mask_t is only an alias to std::uin16_t and probably the only thing we need in adr, I would just use std::uint16_t. Maybe we will have to change it to std::uint32_t at one point, but that's also doable. I think that's less effort than introducing a whole new dependency in adr. As I would like to introduce amenity types in adr anyway, the fields could probably be shared: in case of an extra/extension place it's a clasz_mask_t, otherwise it's a amenity_idx_t.

[schaerfo]

OK, so as of now the available modes per stop are stored, but not in adr. So how can we filter them in get_scored_matches? Maybe with a callback that is supplied from geocode::operator()? Or do you already have something else in mind?

[felixguendling]

For example, it is annoying to search through all the bus stops of a city when you are only searching for train journeys in the first place.

Wouldn't it make sense in this case to load the timetable without the claszes you're not interested in? This would also speedup the routing.

[schaerfo]

Implemented in #1152