Agency PUT Stops payload about mobility-data-specification HOT 7 CLOSED

Agreed, I think that we should broaden the umbrella of things that can be updated. IIRC, in the initial drafts I don't think that I even included PUT methods, because I figured that the Stop management could be handled outside of the spec, and the spec would only handle reading of Stops. I think that by expanding the properties that can be updated via a PUT, we can better support provider-managed Stops.

from mobility-data-specification.

So to wrap up, these items should now be allowed to be changed via PUT within Stops:

• last_updated
• num_vehicles_available
• num_vehicles_disabled
• rental_methods
• num_places_available
• num_places_disabled
• devices

from mobility-data-specification.

The original intent was for the regulating body to collect and publish that data through whatever mechanisms, and publish it read-only via the Stops endpoint, but if it's a Provider-maintained and -monitored Stop, then yeah, those fields should be mutable. More likely scenario is Provider-maintained Stops will use the Provider API.

from mobility-data-specification.

I agree it seems like a lot of these fields should be allowed to be updated via Put for stops.

It looks like a lot of this Stops work was done by you @thekaveman along with @marie-x and @avatarneil about 3-4 years ago, around the time I was starting. I don't recall the intention around this for Stops, do any of you have context and thoughts?

from mobility-data-specification.

Yeah I'm not super happy with having a single object for Stop that is mutated frequently (y'all know me, I'm stuck on immutable data whenever possible to make Policy measurements maximally reproducible) - in my perfect world, there'd be a separation between immutable Stops (e.g. the address and lat/lon) and mutable Stop Status. But we're not applying Policy to Stops (yet), so I think PUT should be allowed to update any Stop field where it makes sense to do so (e.g. num_places_available but NOT stop_id).

from mobility-data-specification.

OK check out the difference in OpenAPI and LMK if this looks good:

• POST: https://openmobilityfnd.stoplight.io/docs/mds-openapi/b3ea061e37756-stops#request-body
• PUT: https://openmobilityfnd.stoplight.io/docs/mds-openapi/362ec313b670d-stops#request-body
• GET: https://openmobilityfnd.stoplight.io/docs/mds-openapi/bd99c2440acf4-stops#response-body

from mobility-data-specification.

Looks correct! Updated with commits here and here.

from mobility-data-specification.