Wish: support for private feeds

[markstos]

For our use case, we have a number of customers in California. A number of them have public GTFS feeds, but several of have private GTFS feeds. For example, corporate shuttles only the employees to go to work, or a shuttle only to travel around within a particular campus.

Without support for these built into a routing engine, we rebuild several graphs for California: one with all the public feeds and then several additional ones that contain all the public feeds plus the one or two private feeds for each customer.

To support this use case, we are interested what might be called "Provate data sets".

Configuration

The configuration would include a data model maybe like this:

private_datasets:
    cust1:
        api_key: 'WE-CHOOSE'
        path: cust1.gtfs.zip

Or:

# If a private_api_key is defined, it's private.
datasets:
    cust1:
        private_api_key: 'WE-CHOOSE'
        path: cust1.gtfs.zip

Some customers have more than one private feed. For example, they have two campuses.

Building private feeds

• Private feeds would have the private_api_key added to their metadata.

Serving Private feeds

• By default, routing ignores feeds marked as private.
• If an API key is provided, it's validated against the configuration, then routing considers those feeds plus all public feeds.

(We are not currently using Motis, but it seems to support the other features we need. Support for this might be the tipping point to switch).

[felixguendling]

I guess this is just an additional hash_set<source_idx_t> allowed_sources_ for the query struct and a vector_map<route_idx_t, source_idx_t> in the nigiri RAPTOR implementation and for each route first check if it's in one of the query.allowed_sources_ set. Probably an additional template parameter bool LimitSources makes sense to generate different variants of the algorithm (with check and without check) at compile time. This makes sure that the base version stays as fast as it is now.

However, I would probably not have API key management be part of MOTIS because everyone has their own solutions with middleware in front of MOTIS anyway. So from an architecture perspective I think MOTIS would always operate behind some kind of reverse-proxy/middleware that can make sure that specific query settings are only allowed from specific clients (which might require database / Redis lookups, etc.). So as a MOTIS API parameter I would just propose to have an optional parameter allowedTags=cust1,cust2 without any API key checks as those are done outside (to keep MOTIS simple and targeted towards the job of computing responses).

[markstos]

It's true we would be running MOTIS behind an app server and we could validate that requests from customers only requested their valid private feeds. A good idea for simplification!

Then you right then then that we only need a way cause feeds to be inactivate unless the allowedTags param activates them.