search

openmobilityfoundation / mobility-data-specification

A data standard to enable right-of-way regulation and two-way communication between mobility companies and local governments.
https://www.openmobilityfoundation.org/about-mds/
Other
676 stars 232 forks source link

Reports - Add provider_id and adaptive_scooter as a special group type #804

Closed alexdemisch closed 1 year ago

alexdemisch commented 1 year ago

Explain pull request

Following the discussion and meeting earlier this year on #672, add 'adaptive_scooter' as a special_group_type to reflect SFMTA's use of this in the Reports endpoint for its scooter program.

Also, in our use of Reports, we've found that adding provider_id is necessary so we know which company the report is from. It would be better if the providers included this directly.

Is this a breaking change

A breaking change would require consumers or implementors of the API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).

Impacted Spec

Which spec(s) will this pull request impact?

schnuerle commented 1 year ago

We had provider_id initially, then removed it thinking that you'd know the provider ID from the http link to the report itself coming from a specific provider! Are you saying you'd still like to see this in the CSV file because it's easier, or is there a scenario where one provider could be sending multiple provider_id in the same file (which may be the case with taxis or other modes/scenarios).

The adaptive_scooter option seems good. I'm wondering if there is a better defintion of this though or a link to some sort of canonical description/page since I think some people (in Europe in particular) aren't sure what this is. Is there something to note about this being 'handicap accessible'?

alexdemisch commented 1 year ago

We had provider_id initially, then removed it thinking that you'd know the provider ID from the http link to the report itself coming from a specific provider! Are you saying you'd still like to see this in the CSV file because it's easier, or is there a scenario where one provider could be sending multiple provider_id in the same file (which may be the case with taxis or other modes/scenarios).

Yes, you're right that we'd know which provider each report is coming from. We haven't run into any situation where there would be multiple provider_ids in the same report. It's just easier to also have it in the data since it saves a step downstream when you're combining the data. We could leave it as it is, but perhaps we should include it to future proof it against the examples you raised. I could see that coming up. There could also be a third party provider creating the reports for multiple providers operating in the same jurisdiction.

The adaptive_scooter option seems good. I'm wondering if there is a better defintion of this though or a link to some sort of canonical description/page since I think some people (in Europe in particular) aren't sure what this is. Is there something to note about this being 'handicap accessible'?

Hmm I don't know of anything canonical. There's been some work done on the GBFS side to describe all the different types of vehicles based on their characteristics, hasn't there? Maybe there's something we could use from that work? Otherwise, maybe we could modify the description to say something like "Trips taken on a scooter with features to improve accessibility for people with disabilities, e.g., scooter with a seat or wider base"

schnuerle commented 1 year ago

Those ideas make sense to me. I modified your PR to reflect them, and added the UUID to the examples.

schnuerle commented 1 year ago

What do you think about #809 for removing both start_date and duration from reports?

alexdemisch commented 1 year ago

What do you think about #809 for removing both start_date and duration from reports?

I think we should keep both concepts somehow. The current need for micromobility reports is monthly, but other frequencies could come up, especially for other modes as noted in the comments for #672. I understand the complexity around UTC and timestamps for start_date... is there some other way to address it? I know the date period is described in the path, but like we're doing with provider_id, it'd be good if the date range is also reflected in the data somehow.

wellorder commented 1 year ago

I'm fine putting the the date string, like 2022-11-01, but putting a time with offset is fundamentally misguided (there are months with more than one UTC offset). Another possibility would be to include the time zone as its own column, rather than the offset. (That was actually in the initial commit for that PR :) ) Then you have two columns with identical values in each report, and you're reporting to the city their own time zone (which, uh, they know), but I'm not against it. (One could consider it evidence that the provider has followed the spec with regard to counting in the local time zone I suppose.) I am against the UTC offset.

This discussion really should be a part of the other PR, so I will be including it there.

I have no strong feelings regarding including the provider_id or not.