Provider Reports - Beta 1.1.0 - Feedback

[schnuerle]

Gather feedback to see how we can move Provider Reports out of beta.

Describe the solution you'd like

Collect enough feedback, real-world usage, and requested updates/improvements to move this feature out of beta in a future release

Is this a breaking change

• Not sure yet

Impacted Spec

For which spec is this feature being requested?

• Provider

Describe alternatives you've considered

Leave as a beta feature for longer until we have feedback.

Additional context

All beta features once part of an official release receive an Issue like this to gather feedback.

[ViennaMike]

Likely minor: The current definition states "The authenticated reports are monthly, historic flat files that may be pre-generated by the provider." Is there a reason these are specified as monthly? Could / should this not be variable, such as weekly, bi-monthly, etc.?

[wellorder]

• It's a bit strange that the Accept header for this endpoint is still something like Accept: application/vnd.mds+json;version=1.2.0, since this endpoint does not return JSON. If I understand correctly, +csv would not be valid since csv is not part of the IANA list of acceptable suffixes, so I believe the "correct" thing would be to have no +foo suffix at all. (Accept headers are not my area of expertise though!) This would mean this is the only /provider endpoint that has a different media type, but that would reflect the actual response type better.
• Counts are calculated based the agency's local time zone, and this time zone is returned within the StartDate value. For months where there is a Daylight Saving Time change, use the timezone that is in the majority of the month. This seems a bit strange to me. This would mean our counts would say timezones that did not apply to many of the rides aggregated. It also means we'll have StartDates listed with timezones they didn't actually have (the first of the month often has a different timezone from the majority of the month when Daylight Savings occurs). I guess the thinking is this is a double-check that we are returning results based on local timezones, but fundamentally there can be multiple timezones in a given month so a monthly report is going to have a hard time conveying that as a single piece of information. It's not clear to me that it's worth the confusion, I doubt cities will be checking that we put the "right" timezone string in that field. I'm not a city though, maybe I'm not thinking of some use case.
• *data* Filename: monthly file named by year and month, e.g. /reports/YYYY-MM.csv This is different from all other Provider endpoints, where query parameters are used to indicate desired data time frames. It's workable, but it also means this is presented in the docs differently from all the other Provider endpoints when it comes to how users should structure their requests. The *data* format is only ever used elsewhere in the Provider spec to indicate payload schemas.

[dirkdk]

Reports allows to group trips and therefore users by Geography ID. Question is, what geography linked to a trip should be used? I can come up with 4 possible values:

1. start trip geography
2. end trip geography
3. both start and end trip geography
4. any geography a trip crossed through, including start and end geography

1 and 2 would render a single value, 3 and 4 have the potential to surface multiple geographies per trip. With multiple geographies, statistics become tricky. This would lead to overall statistics being lower than the sum of the statistics per geography, as a single trip could be linked to multiple geographies.

I would propose we use start trip geography. If agreed upon, we should be more explicit in our current documentation:

All geography IDs included in the city published Geography API endpoint are included in the report results. In lieu of serving an API, this can alternately be a flat file created by the city and sent to the provider via link. If there is no /geography available, then counts are for the entire agency operating area, and null is returned for each Geography ID.

https://github.com/openmobilityfoundation/mobility-data-specification/tree/main/provider#data-notes

[wellorder]

I also question if we really want all geography IDs to be included in the report results. Because geographies are also used for MDS Policy purposes, there are many very small geographies that correspond to, say, low speed areas or no ride areas. Do cities really care about the number of trips that start in such geographies? (In the case of no ride areas one would expect the numbers to always be under the k-anonymization threshold, so the row is telling you nothing at all really.) It seems to me that they are more interested in neighborhood or city level statistics.

On a related note, many cities do not bother to provide a geography corresponding to the whole city, since they generally don't publish city-wide policies that way, but presumably they would generally want counts related to the whole city.

I think it would make the most sense for geographies to somehow be explicitly indicated as being used for reports if desired, and if not explicitly indicated then left out.

[alexdemisch]

I agree that start trip geography makes sense for now. As my SFMTA colleagues and I start to work with the data, we might have other opinions, but that can inform any changes as Reports gets moved out of beta.

[schnuerle]

We will be talking about beta feedback for this issue on next week's WG call.

[alexdemisch]

Since SFMTA is interested in trips taken on adaptive scooters, we added adaptive_scooters as a special_group_type in our implementation. Since there may be similar interest in adaptive scooters in other areas, I'd propose we add adaptive_scooters to the enumerated list of possible values in MDS and define it as “Trips taken on a scooter designed to be more accessible to people with disabilities”.

A little background: As part of SFMTA’s Powered Scooter Share Program, permittees are required to develop scooters that are more accessible to people with disabilities. SFMTA isn’t prescriptive about the particular design -- permittees were instructed to develop vehicles and corresponding services that are based on input from people with disabilities. More info about the program and what our permittes Lime, Spin, and Scoot have developed can be found here. This is part of a pilot that could inform future requirements. As such, SFMTA is interested in the usage of these adaptive scooters relative to the rest of the fleet. But since the total number of these adaptive scooters is relatively small, using identifiers in /trips for adaptive scooters presents re-identification concerns. Using the Reports endpoint to aggregate information about this subfleet is a better way to meet our reporting needs while protecting the privacy of the users of adaptive scooters.

Adding adaptive_scooters as a special_group_type would formalize what SFMTA is doing in the MDS spec now. But it also makes me think about other ways to describe adaptive scooters. “Adaptive scooters” can describe a variety of devices with different characteristics that we may also want to include in MDS (e.g., how many wheels does it have, does it have a seat?). I believe MobilityData is currently considering these kind of descriptive elements in GBFS since people may want to search for devices based on these kinds of parameters, and we might want to mirror this in how MDS describes vehicles in /trips, /status_changes, and other endpoints. But if the total number of these devices remains small, then we run into the same privacy concerns that we have now during our adaptive scooter pilot. So sticking with adaptive_scooter as a special_group_type for now might just make sense.

[alexdemisch]

Adding provider_id as a field in the CSV would be helpful since data from multiple providers is very likely to be combined.

[schnuerle]

Likely minor: The current definition states "The authenticated reports are monthly, historic flat files that may be pre-generated by the provider." Is there a reason these are specified as monthly? Could / should this not be variable, such as weekly, bi-monthly, etc.?

They could be variable, which is why the duration column is there. Do you have a use case or needs for other time periods @ViennaMike? It was certainly built to support this, but we kept it as monthly only while in beta. See #809 for a proposal to remove it entirely if is to remain monthly only.

[ViennaMike]

I'm not directly involved in any current micromobility operations, and don't know, for micromobility, of reporting needed other than monthly, and this report data is limited to micromobility services, so I can't cite an example where other periods are needed for that. That said, as the broader standard expands to include share mobility services, there are a number of jurisdictions that require regular reporting on an other than monthly basis. Indianapolis, last I looked into it, required quarterly reporting for shared mobility providers. Seattle requires quarterly reporting for share mobility and taxi providers. I believe the California Public Utilities Commission requires annual reporting from TNCs.

[schnuerle]

Requirements are moving out of beta in 2.0 with #813 based on review by steering committee and working group.