schnuerle
commented
10 months ago Agree and this was a known complexity/limitation going into the launch of the Reports beta feature (we made changes and took it out of beta for 2.0). It's time we addressed this in the next release, and I also think Policy Requirements in the best place to enumerate the relevant geographies. For now you could publish a list of geography IDs to the operators that are relevant to Reports.
The Reports endpoint provides a useful way to aggregate information that otherwise shouldn’t be provided in a raw form. This has been a helpful way for SFMTA to gather information about scooter trips taken by users on a low-income plan and trips on adaptive devices.
To make the Reports endpoint data more useful, we added a set of neighborhoods to our Geographies endpoint that are helpful analytical zones for which we want to see aggregated data. However, our Geographies endpoint also contains equity neighborhoods used for distribution requirements and a no parking zone. We really don’t need aggregated data for these “operational” geographies, but the spec requires operators to aggregate data for all geographies anyway (even geographies that may no longer have any use because all data is immutable).
This can be overly burdensome for operators, and will only get more complex as more geographies are added, especially because the geographies are immutable. Having a method to flag which geographies should be returned in a reports endpoint would be helpful. I could see this going into Policy Requirements, Geographies, or Reports. But Policy Requirements might make the most sense.