Provider Vehicles - Beta 0.4.1 - Feedback

[schnuerle]

Gather real world feedback to see how we can move the beta feature Vehicles out of beta.

Describe the solution you'd like

From the MDS Survey, about half of agencies are using Vehicles, most providers are, and almost all companies support it. Seems to have good real world usage. We need feedback here from those that are using it to know what may need to change before it becomes a stable part of MDS.

Is this a breaking change

• I'm 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

Reviewed as part of the MDS 1.2.0 release review Midway Checkpoint by the Working Group Steering Committees.

[dirkdk]

I think soon Vehicles will be a core part of deployment cap enforcement so I think it is a good idea.

[dirkdk]

Related, I am wondering if the requirement to also have a GBFS API should be dropped. https://github.com/openmobilityfoundation/mobility-data-specification#gbfs-requirement

If the main reason is compliance checks, I would say the Vehicles endpoint replaces this need and we can drop it. We would like this very much as a provider. This would enable us to use different Quality of Service levels for MDS vs GBFS. For instance, as GBFS is public, we rate limit it but run into problems with data aggregators (@jiffyclub can attest to this) sometimes. If GBFS is not used for compliance anymore we can safely adjust our levels without running the risk of making compliance checks more fragile.

[schnuerle]

Thank you for the feedback on Vehicles Dirk.

@dirkdk per your question about GBFS, could you please put that into a new issue for a deeper discussion there?

[schnuerle]

See new issue #641 for discussion around GBFS and MDS, and this issue plus the new issue will be the topics at tomorrow's working group meeting.

[jiffyclub]

We at Populus are now consuming /vehicles and have found it useful in its current spec, so I think it's ready to move out of beta.

[luisjavierbautista]

Great idea! In bogota we are starting now with 1.1 version, but put out of beta vehicles endpoint would be great!

[margodawes]

In Seattle, we are requiring vendors to use the vehicles endpoint and finding it a helpful alternative to constructing fleet totals from the status_changes API.

One issue we've encountered recently is a lack of clarity around whether vendors should return data about vehicle_states not in the public right-of-way. The intro text to the endpoint says vendors should only return data about vehicles in the PROW, but the list of vehicle_states that could/should be included in the payload include states not in the PROW. Clarifying this when moving the endpoint out of beta would be helpful.

[schnuerle]

Hi @margodawes thank you for the feedback. You raise a good point. The vehicles endpoint is clear it's just PROW, but there are states and events than can be outside of the PROW or unknown.

Other endpoints use the same state machine and states/events, like status_changes, events, and Agency endpoints too. So I believe the intention here is that the description is correct, and it's just PROW. If so maybe we can add some text like "Note this a subset of all possible vehicle states and events, and this endpoint is only focused on the PROW states."

However, I could see scenarios where an agency may want to also know unknown states (which should then be clarified here) in addition, or those out of the PROW (though this may include charger locations which could be private).

Does anyone have some feedback on how they think this should be worded and if it should include unknown or outside PROW states?

[marie-x]

It should be all states. Knowing when and where a vehicle either was picked up, or left the PROW, is important for multiple use-cases including cap-counts.

[jiffyclub]

@Karcass I think that would then require some guidance on how long vehicles should remain in the vehicles feed after being removed from the PROW. We would find it useful to get an update in the vehicles feed about vehicles that have left the PROW, but of course it's not practical to keep all vehicles in there forever. Maybe something like an hour?

[marie-x]

@jiffyclub good point. I would propose a uniform timeout for the latest-event-per-vehicle, perhaps longer than 1h.

[schnuerle]

Hi all, we had a productive Working Group meeting about this yesterday. Here are the full meeting notes.

The ending suggestion is to:

1. Add a definition for 'Jurisdiction' in the general information definitions area of the spec
2. Update vehicles to say "Jurisdiction and/or area of agency responsibility" instead of just PROW.

@dirkdk I know you had to drop off and thought it could just stay as PROW. But we discussed lots of examples where PROW is not adequate (private parking garages, national park areas in a city, just outside of jurisdictions or PROW, within interior sub-cities, etc from notes). What do you think?

@margodawes To clarify your initial concern, do you think that 1) it should be just the PROW as stated, or 2) be larger like the agency jurisdiction and area of responsibility, or 3) do you not care one way or the other and just want it to be more clear?