Proposal: Geofencing, virtual station, and dockless support #175
Conversation
This branch and associated pull request is to discuss (a proposal)[https://docs.google.com/document/d/1po4tlv5p7jXB6KQYohLAIS0qKJfxI1e-EH3JjiyUWoc/edit] to add support for dockless, geofencing, and virtual stations.
|
I made the following modifications to the linked Google Doc:
|
|
#89 Discusses cases where station docks fill and then an area around the station becomes available for returns (overflow). As of today, I believe this proposal could serve that case in this way: When overflow is allowed, an element in
Would this serve the use case fully or do we need to modify/clarify the current proposal? |
I think changing the |
|
Hi, Keith Siilats, CTO of Bolt here. I read through the proposal and it maps pretty well to what Bolt is doing. We base our geofence information on open source traccar: https://www.traccar.org/documentation/geofences/ We keep the polygon in WKT instead of GeoJSON but I think either works. Instead of boolean is_ride_through_allowed we use a string based type field, but that is fine too. The main additions I propose is
For example, we show our Ft Lauderdale which is in South Florida and has a restriction of no scooters on the beach (no ride through) Area: City: |
|
Hi @siilats! Thanks for sharing these great ideas. Responses inline below (and in the Google Doc).
This would make it possible to specify default rules for an area, and then override or add rules in the child areas. Do feed consumers want to implement this? Options:
How about changing I've set up a Google Spreadsheet that lists possible parameters, based on your list in the proposal. Let's all discuss these parameters to figure out what would be implemented in consuming applications.
This is served by GBFS's current localization approach: https://github.com/NABSA/gbfs/blob/master/gbfs.md#localization. To change this, open a separate issue or pull request. It would be useful to do a survey of current practice. I'm not sure how many feeds are available in multiple localizations.
In this case (iii), I think the bike/scooter would just not be shown in the public GBFS.
|
|
The current Dockless & Geofencing Minimum Viable Proposal proposes two files
I speculated that it might be useful for consumers and producers for areas to be defined in a file that doesn't change much. That assumption might be false. From the perspectives of GBFS producers and consuming applications -- would it be useful or useless for those to be distinct files? |
For debugging though it will drive people crazy that the scooter will disappear. Things like you want to stop a ride go to store and then take the same scooter again. I think Google Maps might want to know where our hidden areas are. |
|
@antrim The MDS Policy file-based flavor uses two files based on the same broad rationale. |
|
Sorry to reply after a while. I left comments in the spredsheet on Keith's geofencing attributes. I think most of them are already covered by one of the existing or coming proposals (vehicle attributes, deep links, pricing), others can be modelled with this geofencing proposal and the rest Maps wouldn't use. I'd prefer geofencing_zone_information and geofencing_zone_status to be one file. Keen to hear others' opinions. On parent-child zone relationship: would prefer to keep it simple and have non-overlapping areas, each specifying their complete set of rules. It seems simpler to implement and reason about. |
|
Thanks for the comments. This earlier question may have gotten buried, so I'm repeating it. Reactions to the below idea?
|
|
I think that a GeoJSON is a very good idea. Main content of the file is the geofence, therefore a geoJSON seems to be appropriate. |
antrim
changed the title
|
Update: Here's a version 2 proposal (Google Doc). This is intended as a minimum viable proposal candidate for implementation. Please indicate your organization's readiness or lack of readiness to implement this scheme, and request changes if necessary to make it implementation-ready. |
|
Based on stakeholder comments (in the doc and via email), I made the following changes:
|
antrim
changed the title
|
I don't completely agree with removing the is_virtual_station field, why could a station area not be described in case of physical docking stations? |
|
Hi @sven4all, I see what you're saying about describing dock facility footprint. But I haven't heard of applications that want to consume a polygon of a dock facility polygon and show it in a map yet. To all: are there applications that would want to add this functionality? We're trying to develop a minimum viable proposal and discourage speculative changes. |
|
Can I go ahead and call a vote on this proposal? |
|
Hi Jens Frandsen, CTO of Donkey Republic here We welcome this change of adding virtual stations to the spec as our system is build up of that. |
|
@jensfrandsen I believe that is correct - in GeoJSON you can't represent a circle as a point and a radius. You instead have to create a polygon that approximates a circle. |
|
@jensfrandsen : Would it work for you to describe virtual stations by a polygon? A concise spec is good, but if there is a technical necessity to add the capability to describe virtual stations by radius, let's explore and consider that now. Can you share more about Donkey Republic's use cases and needs?
Adding features for dockless, virtual stations, and geofencing is urgent. After a bit more deliberation and comment, I propose to call the vote on this at the end of Monday, November 25 -- unless anyone raises objections(?). I hope that's enough time to make any changes we deem necessary. |
|
To help this discussion forward, I can elaborate a little bit further on Donkey's use case.
The virtual stations are just pin/points for the users. , I assume internally a range is used but that is not visible for the users of the system.
Thinking it through, this was exactly the reason why I wanted a "is_virtual_station" field in the standard. When this field is included you can create a virtual stations as point without having to specifying a station_area. When for example multiple bike-sharing/scooter operators are operating in a city the preferred way to show virtual stations is pins because station_area's are overlapping between different operators and that will be chaos for the customer. Only when a station is selected for example you can show all the station_area's of that operator in your app. |
|
Since the display is a point, it sounds like we could accommodate that by adding back in the 'is_virtual_station' field, as @sven4all suggests. I'll make that change. |
Added necessary geofence language
format updates
|
After seeing the diff, I think it'd make sense to be more specific with how to define the fields Perhaps this could use some kind of guide on what to do and what not to do. For example:
It'd also really help to have example JSON included for all these changes. |
Add geofencing_zones.json example: GeoJSON FeatureCollection. Example gives a v 2.X. station_information.json: lat, lon, and station_area are "Conditionally required".
|
Hi @evansiroky I checked in a change that includes: This also includes one other change: I apologize that I've delayed in calling the vote on this. I think we need to have a bit more discussion on these changes so we're sure this proposal is ready. Looking at the example, what are people's current thoughts about wrapping geofencing zones in a GeoJSON FeatureCollection? Will this be useful to support ad hoc visualization? Or does it make the spec kludgy? |
| \- geometry | Yes | A GeoJSON Multipolygon that describes where rides might not be able to start, end, go through, or have other limitations. A clockwise arrangement of points defines the area enclosed by the polygon, while a counterclockwise order defines the area outside the polygon [(right-hand rule)](https://tools.ietf.org/html/rfc7946#section-3.1.6). All geofencing zones contained in this list are public. | ||
| \- properties{} | Yes | As defined below, describes travel allowances and limitations. | ||
|  - name | Optional | String- Name of the geofencing zone. | ||
|  - rules[] | Optional | Array that contains one object per rule as defined below. In the event of overlapping or colliding rule, the earlier defined rule (in order of the JSON file) takes precedence. |
There was a problem hiding this comment.
Seems like this should be an object of the rules. I don't see a use case for a single Multipolygon having an array of rules. There can be instances where the rules from Features that have overlapping geometry would be in conflict, so it might be good to note that.
|
I do think this format is slightly different from the others, but don't have strong preferences about it although the code to parse this might look different than the other files. My main concern is making sure that there is no ambiguity on how to structure the data. I think the example provided is good and that the spec references the GeoJSON spec. However, the table of the geofencing_zones.json skips over the layer of the |
|
A client is already implementing the station_area field because we need it right now. Maybe it's a good idea to explicitly state that first the x coordinate (longitude) should be specified and then the y coordinate (latitude). Because this was not completely clear for the developer that implemented this functionality. |
| \- geometry | Yes | A GeoJSON Multipolygon that describes where rides might not be able to start, end, go through, or have other limitations. A clockwise arrangement of points defines the area enclosed by the polygon, while a counterclockwise order defines the area outside the polygon [(right-hand rule)](https://tools.ietf.org/html/rfc7946#section-3.1.6). All geofencing zones contained in this list are public. | ||
| \- properties{} | Yes | As defined below, describes travel allowances and limitations. | ||
|  - name | Optional | String- Name of the geofencing zone. | ||
|  - rules[] | Optional | Array that contains one object per rule as defined below. In the event of overlapping or colliding rule, the earlier defined rule (in order of the JSON file) takes precedence. |
There was a problem hiding this comment.
One type of rule not currently represented in this PR (but mentioned in the discussion and used at Bird) is a speed-limited zone. Perhaps we should add a max_speed field, with integer value. We should decide what units we want to use (mi/hr, km/hr, something else).
There was a problem hiding this comment.
@wellorder I think the intention was to only cover rules related to parking in these zones and leave other types of rules/regulations as a responsibility of the MDS spec.
There was a problem hiding this comment.
@contra Whoa, I don't agree with this at all. GBFS should include everything that consumer-facing application can use and max_speed is certainly part of it : it impacts trip planning and is certainly interesting for the user to know in a UI. I though the speed was discarded because there were no implementer for it, but seems @wellorder is one of them now.
I agree regulation/rules that aren't user facing at all can be left to MDS (like vehicle caps).
|
A few stakeholders have indicated that they are using some features in the current geofencing proposal. Should we vote to add this to the specification? Requests / notes:
All feedback/responses very much appreciated! |
We at IBI Group would definitely use this and have already implemented some logic for loading a static GeoJSON file outside of the spec for this purpose.
We don't have an immediate need for this.
We at IBI Group would definitely use this and have already implemented some logic for loading a static GeoJSON file outside of the spec for this purpose.
We support whatever leads to producers creating consistent error-free feeds. :) |
At Transit we're not ready to implement but implementation should start in Q1. We will do speed regulations.
Afaik we don't need this but we would be ok to implement at the same time.
This would be useful for us but I'm missing what exactly is missing in the spec to support this use case.
For us this is a net positive |
|
Thanks for the good work on this proposal. While reading the version 2 proposal a couple of questions came up: MultiPolygons need to be disjunct/non overlapping I made an example of a simple service area (green) in which a small no-go area (orange) exists: The corresponding geofencing_zones.json should look like this: In the geofencing_zones.json I used two polygons to describe the lager service area. One is clockwise, the other is counter-clockwise to exclude the small no-go area. The small no-go area is represented by one clockwise polygon. If one has a geo-coordinate from inside the no-go area and one wants to know if it is ok to end the ride here, one has to figure out which defined area is relevant. Doing this would involve checking each polygon if the point is wihtin this polygon and detecting if the points are clockwise or counter-clockwise oriented. In addition the geo-object for the small no-go area appears twice: one clockwise and one counter-clockwise. So my impression is that the parent-child method make things easier. Differentiation between ride_start_allowed and ride_end_allowed Missing "features" attribute in "geofencing_zones" attribute Attribute "maximum_speed_kph" It might be that some of the issues have already been discussed in other threads. In this case please bear with me. Regards. |
|
To comment on Aaron's questions:
+1 for voting on MVP and adding extensions in separate proposals. Lime has already implemented the current proposal and we plan to implement it in Google Maps in the coming days.
No plans for us.
We don't plan to use these. I have trouble seeing a use case for these for consumers. GBFS is real time. If the use case is to answer micromobility queries in the future, there would have to be more changes to GBFS to be able to do that.
It would be useful for us in the future. Same as gcamp@, not sure what's missing in this spec to make that happen. Perhaps it can be done in a follow-up proposal?
No strong opinion either way.
|
|
@MobilityData will work on making any necessary changes in response to the community's requests, and formatting this as a pull request that's ready to merge. We'll provide a timeline by Thursday. Responses to recent comments below. @matt-wirtz commented --
I think I see what you are saying. Would this be an issue for other consumers or for data producers who would need to specify non-overlapping areas precisely? Two possible solutions would be to specify layers for geofences, or parent/child relationships. If this isn't imperative, this functionality could be added after the minimum viable proposal is implemented.
I'm unsure. Conceptually, I was imagining that such a feature might be used for rebalancing bikes. We don't have a comprehensive survey of all bikeshare operating rules. I looked to see whether MDS provides functions that would allow vehicles to be rented in an area but not returned there, or vice versa, and it doesn't look as though it does (https://github.com/openmobilityfoundation/mobility-data-specification/tree/dev/policy#rules), which would be a point in favor of consolidating these fields. Can operators or those closer to bikeshare/scooter sharing systems share some insights? |
|
@antrim At Bird we do not differentiate between areas where rides can start and rides can end, if you can do one you can do the other. So consolidating the fields is fine from our point of view. |
| { | ||
| "type":"Feature", | ||
| "properties":{ | ||
| "name":"Downtown Waterfront", |
There was a problem hiding this comment.
I would recommend three optional additional keys next to name here:
start_date: string (ISO 8601) | Date and time of the start of the geo-fencing zoneend_date: string (ISO 8601) | Date and time of the end of the geo-fencing zonedescription: string | Description about the geo-fencing zone
These could be used to display temporary no-park zones for which cities place, for example for Christmas markets or street construction sites.
There was a problem hiding this comment.
Hi @Empty2k12: If start_date and end_date were included would you or another application developer commit to implementing that in software?
There was a problem hiding this comment.
Yes, we would love to implement start_date for our unofficial GBFS feeds we're providing.
We'd also like to support start_date and end_date for the GBFS explorer application we're actively developing. For that we'd implement these changes into our GraphQL wrapper for GBFS (GbfsQL) and incorporate displaying that into the viewer frontend.
Thank you for noticing that. I've made a change in the draft proposal (Google Doc version) to include the "features" object member (an array). |
|
Hi all - Sorry for the delay in posting a timeline. The PR will updated with a few changes by Friday (North American time). These additional changes will be in the PR:
We propose to wait and see what needs arise around multipolygon nesting and implement later, if it proves necessary. |
|
Hi everybody, a follow-up on this PR: A new PR #219 has been made to reflect all the modifications on the proposal that the Gdoc reflected. This new PR has also no more conflicts with the current GBFS specification. It means that the PR #219 is replacing this PR that will be closed. Thank you all for your contributions! |
This pull request is to discuss a proposal (Google Doc) -- v2, revised Oct 30 to add support for dockless, geofencing, and virtual stations. Please make comments in this thread or directly in the Google Doc. Once we have arrived at a proposal that is an implementation candidate (at least one producer and consumer say they plan to implement), then @MobilityData will edit the final proposal text and commit it to this pull request.
Proposal summary
This proposal extends GBFS (General Bikesharing Feed Spec) to add support for:
The specific changes are:
An earlier version of the proposal, v1 (Google Doc) included additional elements (discarded because there were no interested implementers):
Extend the proposed vehicle_types.json (PR Add vehicle type definitions #136) to declare whether a vehicle can be left in a dock or freestanding or both.Extend system_hours.json to describe hours during which actions specified in geofencing_zone_information.json can occur.