Provider/Agency Stops - Beta 1.0.0 - Feedback

[schnuerle]

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

Describe the solution you'd like

From the MDS Survey, about a third of agencies are using Stops, almost no providers are, and most companies support it. Moderate usage, but companies are supporting it well. 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
• agency

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.

[sven4all]

I am exploring the usage of this api for regulatory purposes by municipalities.

Some things that are not really clear to me is the link between /stops and /policies. In my opinion /stops created by municipalities are also a policy. At this moment there are two different ways to model this, via /stops and via https://github.com/openmobilityfoundation/mobility-data-specification/blob/main/policy/examples/required-parking.json. It would be nice if you can link from required-parking to /stops in my opinion. What do you think?

The system we work on can be used by all municipalities in the Netherlands. What is the recommended way to communicate stops? Should we consider every municipality as a agency and add something to the endpoint before /stops or should we put all stops of the whole country into one endpoint. I think the same question applies to the policies apis. Would like to hear your opinion on this as well.

[sven4all]

Also, when the city is managing the /stops endpoint the GET can be a public endpoint right? (that is not explicitely stated in this documentation as in the policies, geographies and jurisdictions apis).

[sven4all]

Another thing we find during implementing is how can we specify a capacity that can be shared between multiple modalities? So for example there are 40 places that can be used by mopeds or cargo bicycles?

[schnuerle]

Hi @sven4all I like some of your thoughts and comments here. I'd love to work to incorporate them into MDS 2.0 which is the next release with the help of the Working Group.

Stops and Policy conceptually was a big topic when making Stops. Can you give an example of what you are thinking around "link from required-parking to /stops"? I do think this was something discussed.

For the scope question of stops and policies, usually it's the jurisdiction presiding over the geographic area and the program operation that makes a single policy file. For something as big a country though, that jurisdiction may choose to serve up individual files by state/province, or by city. These could be documented and reference in the Policy Requirements file.

The spec now explicitly states that stops should be authenticated (see here). I think the intention is that it's used for regulatory bodies to track, measure, and understand usage at stops, and not for the public. The idea is that if it should be public, one could use GBFS station status, which is required as part of MDS Provider. but if that is not adequate, I'd love to hear your thoughts on why this should be public (and maybe what should be added to make it more useful to the public, like GBFS?). We do reference GBFS with region_id and rental_methods.

For capacity between multiple vehicle types or modes, I think you can specify vehicle_type_counts by vehicle_type per the schema. Maybe it needs clarification in the spec or an example. Also note the parent_stop field where you can create a hierarchy of stops types within an area, for example a parking lot stop could have children with a stop for docked bikes, a stop for a scooter corral, and a stop for a scooter charging station.

[schnuerle]

Also, when the city is managing the /stops endpoint the GET can be a public endpoint right? (that is not explicitely stated in this documentation as in the policies, geographies and jurisdictions apis).

We had not thought of Stops being public, but maybe they could or some version of them could if incorporated into Policy.

[sven4all]

I think it's interesting to give some insights into our implementation. In the Netherlands the municipalities have the jursdiction to make the policies within their boundaries. We decided to create one endpoint that returns all policies within the Netherlands but has filters to filter out data for a certain jurisdiction.

For example:
// all stops in the Netherlands
https://mds.dashboarddeelmobiliteit.nl/stops
// all stops within the municipality of the Hague
https://mds.dashboarddeelmobiliteit.nl/stops?municipality=GM0518
// and Rotterdam
https://mds.dashboarddeelmobiliteit.nl/stops?municipality=GM0599

// all policies within the Netherlands
https://mds.dashboarddeelmobiliteit.nl/policies
// all policies within the municipality of the Hague
https://mds.dashboarddeelmobiliteit.nl/policies?municipality=GM0518
// all policies within the municipality of Rotterdam
https://mds.dashboarddeelmobiliteit.nl/policies?municipality=GM0599

geographies referenced in /stops or /policies can be retreived from the /geographies endpoint.
https://mds.dashboarddeelmobiliteit.nl/geographies/6c2f08d4-5070-11ed-94a7-22d0d35466d6

At this moment /stops takes precedence over /policies this means if you define a no parking policy with a stop within it, it's allowed to park your bicycle ion the stop altough it's within a no parking zone (see picture below, the red dotted line is the border of the no parking zone, the green zones within the no parking zones are stops).

The endpoints I implemented are part of MDS Agency, Policy and Geography and not MDS Provider. They are meant to integrate the data of multiple providers and make it possible for providers and travel information to indicate to their users how much places are available for parking on every stop.

[schnuerle]

Hi @sven4all this is amazing to see and good work on your end. Thank you for sharing the public links, details, and screenshots.

Now that for MDS 2.0 Agency and Provider will share the same data object structures in #796, it makes even more sense to discuss Stops being added as an option to Policy and share that same data object in the next MDS release.

Issue #818 also has some thoughts on this.

[sven4all]

Another thing we find during implementing is how can we specify a capacity that can be shared between multiple modalities? So for example there are 40 places that can be used by mopeds or cargo bicycles?

I think this issue is still relevant. I cross link this ticket MobilityData/gbfs#547.

This is how it looks like now in our implementation. But capacity is not according the official MDS spec.

{
            "stop_id":"c9d8a20e-e6f5-11ec-bdc7-8685b45d2670",
            "name":"Strandslag 12",
            "last_reported":1695870722683,
            "location":{
               "type":"Feature",
               "geometry":{
                  "coordinates":[
                     4.25748941743733,
                     52.097210199407
                  ],
                  "type":"Point"
               },
               "properties":{
               },
               "id":null,
               "bbox":null
            },
            "status":{
               "is_renting":false,
               "is_installed":false,
               "is_returning":true,
               "control_automatic":true
            },
            "capacity":{
               "combined":62
            },
            "num_vehicles_available":{
               "moped":2,
               "cargo_bicycle":0,
               "bicycle":0,
               "car":0,
               "other":0
            },
            "num_vehicles_disabled":{
               
            },
            "num_places_available":{
               "moped":60,
               "cargo_bicycle":60,
               "bicycle":60,
               "car":0,
               "other":60
            },
            "geography_id":"e4cfb752-fa0c-11ed-b914-96cdaf8f7240"
}