Open hbruch opened 11 months ago
Doesn't sound like an unreasonable thing to support. The implementation is not trivial, since it requires aggregating data on the operator level, which we currently don't do elsewhere. Is this something you would like to contribute on?
I'd give it a try. I see two options, a) aggregating (and probably storing) it at the operator's level or b) just implement a dynamic filter iterating over the operator's vehicle types, without returning the formFactors explicitly. b) seems to be a simpler approach and IMHO sufficient for now. WDYT?
The problem in both cases is that the "operator's vehicle types" is spread across all the operator's GBFS feeds - and right now we don't have a way to iterate over them, because we don't store any references to GBFS feeds per operator. It's not 100% clear how this feature should work. Should it consider only available vehicle types, or any vehicle type listed in vehicle_types.json. Should it update when vehicle_types.json changes? Should it be the union of all vehicle types in all vehicle_types.json files of that operator, also considering changes over time?
Not sure if I am too optimistic, but please check the PR if I misinterpreted something. IMHO, the FeedProviderService
allows iterating feeds and provides access to the operator(?).
I'd consider any vehicle type and as FeedProviderService
accesses the most recent feed, it would always be up-to-date (respecting currently rented vehicle types, though they might not be available at the moment).
We ingest feeds of various providers, which offer cars, bikes, cargo bikes, scooters etc. We'd like to be able to group them by formFactor of the vehicle types they offer (accepting that some offer more than one).
I suggest to enhance the
GraphQLQueryController.getOperators()
by an optional formFactor filter. Providing specific formFactors only those operators are returned, which offer this kind of vehicles.