Retrieve operational zones from operators

[tybaltspark]

Is your feature request related to a problem? Please describe.

Some permits contain defined operational zone (i.e. London), some others don't (i.e. Milan). In the case where cities dont impose an operational zone, then it's up to the provider to propose one (if at all).
In most cases, cities are in the dark to know exactly what is the operational zone of each operator. One can guess it using vehicles positioning. However this only remains a guess and it is then difficult to track how these operational zones are evolving.
The objective for cities is to better understand the coverage of each operator, and why some parts of the city do not show strong activities. Is it because the need is simply not there or because the vehicles are restricted from going in this part of town.

Describe the solution you'd like

We would propose that provider give their operational zone within the Provider API as part of an info endpoint.
This information should be updated on a daily basis.

Is this a breaking change

No, it's not a breaking change. It's additive

Impacted Spec

• provider

Describe alternatives you've considered

What we have done so far is asking the geographies directly from the providers to expose that on the Vianova platform.
So this is done manually and needs recurrent updates.

Additional context

Three European cities have asked for this feature (Italy, UK and Germany).

[schnuerle]

The way this is currently handled in MDS is the agency dictates this to the providers using the Policy API. You are proposing that the providers send back a geojson boundary as part of one of the Provider APIs, so that the city/third parties can confirm that these align?

I have noticed in my city that opening an operator app will show the operating boundaries, and they are 1) different for each operator and 2) do not align to the operating areas in our city policy permit document. I know our city's coordinator has tried to have operators update this but is not always successful, and it's not egregious enough to withdraw their permit. Do you think this could help solve for an issue like this?

[tybaltspark]

Some European cities (and probably US, and others) do not provide operational zones as part of the permit. Hence there is no communication through the Policy API to be done, as there is no enforcement as part of the permit.

Operators do have different operating zones whether there is an operational zone provided by the authority as part of the permit or not. Four cities have expressed strong desire to know what these operational zones are in order for them to better understand service coverage & devices deployment.
We see operators providing the operational zones to cities and local authorities as part of the provider API. Please let me know if you see any counter-indication or other experiences to complement this thread.

[tybaltspark]

@schnuerle Is there a possibility that this could be discussed at the next meeting ?
Do you see any roadblock on this item ? It is something that has been widely asked by European cities and cities are very keen for us to push this forward so that it becomes a norm. Thank you

[schnuerle]

We may be able to discuss at a meeting soon. I will bring to the WGSC.

I don't see any roadblocks, just work to be done on 1) understanding the need and 2) deciding how to implement and 3) some consensus.

For 1) understanding the need, what are other solutions that could handle this in a less complex way? For instance, I know in Louisville our coordinator just opens the operator app and the boundaries are shown there. Then he can contact them about it.

Could this be solved by an agency asking the provider for this file or info, since it should not change much?

Is there a barrier for the agencies to either a) communicate the operating area in their operating permit (see page 10 of this doc) or b) serving the Policy API to communicate this?

For 2) deciding how to implement, we'd need to think about where this would go in MDS. Maybe in an optional new operating_area field at the top of the Provider Trips endpoint (any other endpoints?) and in Agency (though I'm not sure where it would fit here).

Would this field contain the entire GeoJSON of a polygon around the city operating area each time the endpoint is served? That could add a lot to the file size. It could instead be a link to the operating area on an operator site, but the spec would have to specify whether that link is a GeoJSON file, image, GIS page, webpage, etc.

For 3) consensus, are there other software companies, cities, and operators who think this could solve a problem for them? Chime in here or look for a discussion on a WG call.

May 26: Edited to included a link

[tybaltspark]

Thank you for your response. Please let me know when I could bring the subject up in the next couple of weeks.

For 1)
A city official could indeed open the 6-7 apps and then print them in their head and compare them. But this would be quite cumbersome specifically with the rate of change that we see. Operating zones are changing every 2-3 weeks at the moment.

Is there a barrier for the agencies to either a) communicate the operating area in their operating permit (see page of this doc) or b) serving the Policy API to communicate this?
a) most cities don't have operating zones in their permit and do not wish (or cannot) set operating zones as part of their permit
b) serving the policy API means the city sets the operating zones, which is not the case in most European cities

For 2)
Having the optional field operating_area as part of the trips endpoint sounds like a good idea

For 3)
I understand. We should bear in mind here that operating zones may have different policy implications between the US and other markets.

[alexdemisch]

This would be nice to have, and if it’s been requested by a few European cities, then we'd presumably have some adoption.

Like some other cities, SF doesn’t dictate or really monitor the operating zone geographies. Rather, we indicate the neighborhoods that are important to serve, and these areas are where we focus our metrics. But we have had requests from researchers for the operating zones for each provider over time, so it could be helpful for providers to make that available. Perhaps an endpoint with this info wouldn’t need to be authenticated.

Does GBFS have any similar functionality?

[schnuerle]

Thank you Alex.

In GBFS, geofencing zones added recently in v2.1 can handle this (eg, operating area, no ride/park, ride through, speed). Kind of a lite version of MDS Policy /policies. To your point, it is published by providers.

This may be the start of a case for an endpoint in Provider that does something similar to the GBFS endpoint, published by Providers.

But now I am wondering if it's duplicative of this GBFS endpoint, eg, why not use that GBFS file that is public already? Since GBFS is required as part of using MDS, and the geofencing_zones.json file is required as part of GBFS, then doesn't it make this required to be published by providers already? I don't want to be duplicative here with MDS + GBFS.

One issue here is that while geofencing_zones.json is required, the zones within it are not required, so a provider may not publish and operating area with it. I'm not sure about this, reading the spec, what zones are required to be published. Maybe @mplsmitch could help clarify.

[mplsmitch]

geofencing_zones.json is an optional GBFS endpoint. If a provider elects to, or is required by a city or agency to publish geofencing_zones.json its recommended (SHOULD) that they define the service area outside of which vehicles are not permitted to operate. Zones are modeled according to restrictions (rules). Currently there three rules defined:

1. are rentals allowed to start or end in the zone
2. are rides through the zone allowed
3. maximum speed allowed within the zone

We expect more rules will be defined in the future as use cases are identified. Alex's example of researchers wanting operating zones over time could be supported if someone is capturing the data over time.

[schnuerle]

Thank you for the clarification and details Mitch. I do see it's marked as optional now in the files list; I was looking at the geofencing_zones field name in the JSON file area. But agencies could require it as part of their GBFS operating requirements.

We will be discussing this idea on tomorrow's Working Group call.

[schnuerle]

It looks like a solution in to this in the next release 1.2 could be the inclusion of GBFS information within the Policy Requirements API. We discussed this at the WG meeting (see notes) and there was good consensus around the idea. Likely it would enumerate which version of MDS agencies would like providers to publish to the public, and what optional endpoints would be required by the agency (like geofencing_zones).

We also talked of a larger idea for a future release of the idea of a Manifest file for providers, including operating area, endpoint urls, other details, which could be in a minor or major MDS release. This new Manifest seemed preferable to everyone than sending back this data piecemeal as part of existing endpoints, which would require endpoints to potentially be overloaded with large or duplicative data.

[tybaltspark]

The geofencing zones provided by the providers through the GBFS endpoint would work well for the operational zones and the following use cases I described earlier. I understand that we would just not be able to retrieve historically the operational zones and how they might have evolved before collecting the data.

The question will be about making it mandatory for operators to share the operational zones through the optional GBFS endpoint. And as it was shown in the Requirements API, it is perfectly possible to do so with the enhancement proposed by @quicklywilliam.
It seems that we answer quite well the use cases, minus the historical part that we would be missing.

[mplsmitch]

Zones described in GBFS geofencing_zones.json have an optional start and end POSIX timestamp. These could be used to indicate dates when an operational zone was in place. When changes are made, the end would be set on the current zone and a new zone would be published with start timestamp.

[quicklywilliam]

@mplsmitch is there any guidance in the spec on what should happen to a geofencing_zone once it is updated/removed? I'm not clear on how a City would explicitly require historical operational zones like @tybaltspark describes.

[mplsmitch]

@quicklywilliam - there's no guidance in the spec on what happens when zones get updated since this was never an intended use. I'm not sure how a city would require it and if there were a case where the zones changed frequently the files could get pretty large.

[schnuerle]

This should be solved when we include specifying optional GBFS endpoints in the new program requirements API #646. I think this is the best solution for now, relying on something that already exists, avoid duplication, and aligns to work being done on this 1.2 release item. A future idea is to have a Provider Manifest file that includes information like this and Requirements, a parallel feature from the provider perspective.

[schnuerle]

Completed with #646!