Polygon coordinates for stationless bikes

[mplsmitch]

I'd like to get a discussion going around adding polygon coordinates to describe parking areas and service area boundaries for free floating bikes. Cities are beginning to wrestle with how to regulate stationless bikes and it seems like there's an opportunity to address this via GBFS. Since I run a station based system I'm not up to speed on how these data are currently described. This issue also comes up with the proposed "super hubs" in Portland. Is there anyone from SoBi or with GIS expertise that would be interested in working on this?

[barbeau]

+1

We'd be interested in being a GBFS consumer for floating bike areas, both in OneBusAway and our USF Maps App. I actually just had this discussion with TriMet in Portland OR last week and I know they are interested in this for their multimodal app as well as part of their FTA MOD Sandbox project. ccing @fpurcell from TriMet.

Right now for the USF Share-A-Bull system in Tampa, FL SoBi is publishing the drop off zones as individual virtual stations, defined as points in the existing station_information.json endpoint:
http://usf.socialbicycles.com/opendata/station_information.json

To give a concrete proposal to this discussion - how about a new endpoint?

free_bike_zones.json

Field Name	Required	Defines
zone_id	Yes	ID field - identifier for this free bike drop-off zone. This should be globally unique (even between different systems) and it is currently up to the publisher of the feed to guarantee uniqueness. In addition, this value is intended to remain the same over the life of the system. Each drop-off zone should be disjoint - there should be no geographic overlap between two different zones.
zone_area	Yes	A valid GeoJSON Polygon that describes the area where free bikes can be dropped off.

I think our only realistic option to describe the geographic properties of zones is GeoJSON, as they can be complex. Here's what the allowed drop off zone currently look like at USF (from https://usf.socialbicycles.com/):

[serialc]

Sounds like a good idea with the growing number of such systems.

A few comments on refining the above definitions.

Given that each bike share system (BSS) already has its own unique identifier within the GBFS system list, uniqueness of the zone id relies simply on the operator to distinguish them. So University of South Florida's Share-a-Bull Bikes has the id usf_share-a-bull_bikes and then simply can create/manage its zone ids independently (e.g., 1, 2, 3, north, south, campus). Further the stipulation that each zone be distinct (no overlap) isn't necessary - it makes sense but isn't necessary to stipulate. Of course zones from different BSS operators may overlap...

Regarding the the zone_area I would recommend a MultiPolygon feature type rather than a Polygon to allow greater flexibility.

[barbeau]

@serialc Sounds good! Revised proposal:

free_bike_zones.json

Field Name	Required	Defines
zone_id	Yes	ID field - Unique identifier of a free bike drop-off zone. See Field Definitions above for ID field requirements.
zone_area	Yes	A valid GeoJSON MultiPolygon that describes the area where free bikes can be dropped off.

[fruminator]

Just to be clear: are we talking the virtual stations here, or the overall service area? We should be clear to distinguish because those are 2 different things. Thanks, Mike

…

On May 18, 2017 11:22 AM, "Sean Barbeau" ***@***.***> wrote: @serialc <https://github.com/serialc> Sounds good! Revised proposal: free_bike_zones.json Field Name Required Defines zone_id Yes ID field - Unique identifier of a free bike drop-off zone. See Field Definitions <https://github.com/NABSA/gbfs/blob/master/gbfs.md#field-definitions> above for ID field requirements. zone_area Yes A valid GeoJSON MultiPolygon <http://geojson.org/> that describes the area where free bikes can be dropped off. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#65 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJXEDsXQVUInWP7AE7FPnk4CeEUo4Ogks5r7GI_gaJpZM4NeIIi> .

[serialc]

The definition of what the zone represents exactly will likely vary by operator in terms of cost/possibilities.
In this discussion the zones described above are the areas that bicycles can be dropped off in (likely with a cost), in addition to the stations.

[mplsmitch]

The scenario I'm thinking of is a city with multiple companies operating bikes. It's going to fall on the city to define where bikes may be parked. These areas once defined would/could be used by multiple operators.

I'm imagining there are 3 parts to this:

1. Small areas where users are permitted to end rentals, like hubs currently used in SoBi systems. This could be a "station" or just a rectangle painted on the sidewalk. These could be defined by a municipality and used simultaneously by multiple operators.
2. Large areas where users are permitted to end rentals like the proposed Super Hubs in Portland These could also contain (1). These could be defined by a municipality and used simultaneously by multiple operators.
3. Boundaries of the service area outside which users would not be permitted to end rentals. This would contain both (1) and (2) These would probably be defined by operators because they could span multiple municipalities.

Field Name	Required	Defines
hub_id	Yes	ID field - Unique identifier of a permitted bike parking hub. See Field Definitions above for ID field requirements.
hub_area	yes	A valid GeoJSON MultiPolygon that describes a hub where bikes can be parked.
zone_id	Yes	ID field - Unique identifier of a permitted bike parking zone. See Field Definitions above for ID field requirements.
zone_area	yes	A valid GeoJSON MultiPolygon that describes a zone where bikes can be parked.
boundary_id	Yes	ID field - Unique identifier of a bike service area. See Field Definitions above for ID field requirements.
boundary_area	yes	A valid GeoJSON MultiPolygon that describes the bike service area outside of which bikes cannot be parked.

[barbeau]

@mplsmitch As a GBFS consumer, I'm not sure I understand when I should show a zone_area to a user vs. a boundary_area or a hub_area.

The primary use case I'm trying to address is that a user has rented a floating bike, and now needs to return it. So, I'd like to show them polygons on a map that indicate where they are allowed to return the bike.
Would I show all polygons from zone_area, boundary_area, and hub_area to a user? Under what cases would I show some but not others?

At USF we have a single polygon for where floating bikes can be returned which is equivalent to the service area, but maybe this is a simpler implementation than other city/region-wide solutions.

[serialc]

Given that GBFS is organized/driven by a consortium of private companies and has the purpose to "make real-time data feeds publicly available online in a uniform format so that map and transportation based apps can easily incorporate this data into their platforms." I think talking about municipalities getting involved sounds out of scope.

What you/@mplsmitch are suggesting, let's call it municipal bike-share zoning feed (MBSZF), sounds helpful for cities, such as those in China, having bike-share crowding problems due to many companies with overlapping coverages. This creates the big piles of bikes we've seen in the news lately.

Having said that, even then MBSZF doesn't seem worthwhile as the city would simply pass along a shapefile to the company and they would then themselves use that polygon in the zone_area's we've discussed earlier above.

TLDR: GBFS is for bike-share operator feeds, not municipal regulation of bike-share.

[mplsmitch]

@barbeau I think the answer to which polygon area is displayed depends on the business rules of the particular system. I don't know about USF but many floating bike systems like Coast charge different rates rates to users depending on where they end their rental. Ending a rental outside a hub/station is allowed but incurs an extra $2 charge. Presumably this is something you would want to be able to convey to users. Currently hubs are defined as points in station_information.json. I'm not sure how they determine if the bike is within the hub area. Ending a rental outside the service area (boundary) results in a significant fine - also something users would want to be aware of. Maybe 3 types is going too deep. I agree the "zone" is harder to define - but it seems like it's distinct from the hub/station since it could contain stations. It wouldn't have occurred to me had it not been for Portland's Super Hub plan.

@serialc I would disagree that GBFS is organized/driven by a consortium of private companies. NABSA's membership is largely made up of cities. The industry in the US is changing. As an owner/operator I want to be able to compete with new business models but without municipal regulation that's going to be difficult if not impossible. This is already happening in my city so it's not confined to Asia. I think you're correct that cities will pass shape files to (multiple) operators. I also think cities will become consumers of the resulting GBFS feeds in order to monitor and enforce bike parking regulation. Without access to uniform real time data I can't see how they can effectively prevent piles of illegally parked bikes blocking the ROW.

[barbeau]

If we add a plan_id, would that be sufficient to represent fees charged for dropping a bike off in both virtual hubs as well as outside the service area?

free_bike_zones.json

Field Name	Required	Defines
zone_id	Yes	ID field - Unique identifier of a free bike drop-off zone. See Field Definitions above for ID field requirements.
zone_area	Yes	A valid GeoJSON MultiPolygon that describes the area where free bikes can be dropped off.
plan_id	Yes	The plan_id for the fee charged to the user for dropping off a bike in this zone, as defined in system_pricing_plans.json.

I'd like to keep this as simple as possible, which is hopefully the area where I can drop off a bike, as well as how much that would cost me.

[mplsmitch]

As I understand it, *system_pricing.json* doesn't cover fees currently. The plan_id field identifies a subscription or access type and it's associated price but usage fees (or fines) aren't covered. http://coast.socialbicycles.com/opendata/system_pricing_plans.json The question we need to answer is whether or not the bike is parked in a permitted area, it's up to the owner/operator of the system to decide if that impacts pricing or not. What if we used an enumerable field zone_type that could contain hub boundary etc

[barbeau]

@mplsmitch here's a version with the fee pricing directly in the new endpoint:

free_bike_zones.json

Field Name	Required	Defines
zone_id	Yes	ID field - Unique identifier of a free bike drop-off zone. See Field Definitions above for ID field requirements.
zone_area	Yes	A valid GeoJSON MultiPolygon that describes the area where free bikes can be dropped off.
drop_off_fee	Yes	The fee charged to the user for dropping off a bike inside or outside of this zone_area, as defined by fee_outside_zone. This should be in the base unit as defined by the ISO 4217 currency code with the appropriate number of decimal places and omitting the currency symbol. e.g. if the price is in US Dollars the price would be 9.95
drop_off_fee_currency	Yes	Currency the drop_off_fee pricing is in (ISO 4217 code: http://en.wikipedia.org/wiki/ISO_4217)
fee_outside_zone	Yes	1/0 boolean - 1 if the fee is charged if the user drops off a bike outside of this zone, and 0 if the fee is charged if the user drops off a bike within this zone.

This would allow you to specific a fee for leaving a bike outside of a service area with fee_outside_zone=1, or a fee if the user drops off a bike within a specific zone/area with fee_outside_zone=0.

Or are you saying that the fee amount shouldn't be contained in the GBFS feed because the fee may not be controlled by the GBFS feed maintainer?

From a GBFS consumer perspective, I would hope that the operator and GBFS feed maintainer would coordinate/communicate enough that this would be transparent to consumers.

If the fee issue gets too complicated, we can simplify it back to just zones where no additional fees would be charged:

free_bike_zones.json

Field Name	Required	Defines
zone_id	Yes	ID field - Unique identifier of a free bike drop-off zone. See Field Definitions above for ID field requirements.
zone_area	Yes	A valid GeoJSON MultiPolygon that describes the area where free bikes can be dropped off without the user incurring any additional fees.

We want to stick to something simple and universal that doesn't require an external explanation of business logic, as much as possible. It doesn't seem like this is possible when expressing hubs vs. zones vs. service areas, unless I'm missing something.

[mplsmitch]

I think we should stay away from pricing and fees since there's already an endpoint for pricing info. This endpoint should stay focused on location. I used pricing as an example of how an operator (or feed consumer) might use the data but I could see other uses. Let's stick with zone_id and zone_area until someone else weighs in.

[jcn]

After reading through this discussion, my question is whether the proposed free_bike_zones is really just extending the existing station_information.

Using Share-A-Bull as a model, it seems that the best thing to do would be to add an optional geometry field (or something similarly named) that defines the return area for that particular station as a MultiPolygon. A station defines a location where bikes can be returned; this seems like it would work for virtual stations and super hubs alike without overcomplicating things.

[barbeau]

That works for me, and seems to be the closest model to existing implementations.

Any producers willing to try this out?

[barbeau]

Friendly ping - any producers willing to implement this? We're rolling out bike share info (layer and real-time bike share/transit trip plans) in OneBusAway in Tampa right now, and it would be great to be able to show floating bike area boundaries in the app. Other cities on the roadmap include San Diego, Seattle, and Washington, D.C.

[dsgermain]

We are willing to supplement station_information with zone_area.
I would also add a zone_area_enabled boolean field to indicate whether this extension is active or not in the case of a traditional station. Because of regulation, or other business logic, this zone might be available only during specified time slots.

Field Name	Required	Defines
zone_area	Yes	A valid GeoJSON MultiPolygon that describes the area where free bikes can be dropped off.
zone_area_enabled	Yes	1/0 boolean - 1 if the zone currently allows parking, 0 if the zone does not currently allow parking.

[barbeau]

@dsgermain That's great you're willing to implement this concept in station_information.json!

A few questions off the top of my head, related to adding this info into station_information.json vs. a new feed file like free_bike_zones.json:

1. The definition of zone_area_enabled isn't entirely clear to me. From your written text ("whether this extension is active or not in the case of a traditional station"), it sounds like zone_area_enabled = 0 would mean that the station is a physical dock, and zone_area_enabled = 1 would mean that it's a virtual zone. But, for the field definition in the table and your other written text ("because of regulation, or other business logic, this zone might be available only during specified time slots"), it sounds like this field is more dynamic based on time, with zone_area_enabled = 0 meaning that the virtual zone exists but is not currently available to the customer to drop off a bike, and zone_area_enabled = 1 being a zone that is currently available for customers to drop off bikes. This is important because consumers of the feed need to know whether a "station" in this feed is a virtual area for floating bikes or a physical dock. Could you clarify your definition? Maybe we need a separate boolean flag for whether the station is a physical dock or zone, like is_zone?
2. If zone_area is required, what value does it contain if the station is a physical dock and not a virtual drop-off area? If we have a separate is_zone field, should zone_area only be required if is_zone is 1?
3. If a station is a zone in station_information.json, what values do the required lat and lon fields contain?

[dsgermain]

@barbeau in our case, the station can be supplemented by a zone. This is means we can have a combination of docks and bikes parked outside of docks. If zone_area_enabled is true, then this extra zone is active. if zone_area_enabled is false, then this extra zone is disabled. I think the information of whether it is a physical station or not is already provided by the station_status.json->num_docks_available?

2. agreed, it should be optional, will change on our side
3. I think it should be the centroid of that zone. Will still be useful if someone wants to put a pin on a map or something similar.

[dsgermain]

To recap:

Field Name	Required	Defines
zone_area	Optional	A valid GeoJSON MultiPolygon that describes the area where free bikes can be dropped off. If no zone exists at current station, this field can be omitted.
zone_area_enabled	Yes	1/0 boolean - 1 if the zone currently allows parking, 0 if the zone does not currently allow parking. If no zone exists at current station, this field should be 0.

[barbeau]

in our case, the station can be supplemented by a zone. This is means we can have a combination of docks and bikes parked outside of docks.

Hmmm, ok. So in your deployments is there ever a zone without a physical dock?

I think the information of whether it is a physical station or not is already provided by the station_status.json->num_docks_available?

No, this field is the real-time availability of docks at a station (from feeds I've seen at least). It's defined as "Number of docks accepting bike returns". So, if there are 5 physical docks and 3 of those docks are occupied by bikes, then station_status.json->num_docks_available would be 2.

My concern is increasing existing confusion over how drop off points are defined. In the deployment at USF (part of Coast Bikeshare now for Tampa) we have floating bikes, with no physical docks. However, in the GBFS feed Coast mapped all of the normal bike racks (i.e., just metal poles, no dock) on campus as a "station" that appears in station_information.json and station_status.json. The result is a clutter of markers on the map of mostly empty stations, unless a bike happens to be near that station. In this case num_docks_available is also very deceptive - they coded it as the value of slots in the normal bike rack, so the value never changes (because it's a dumb bike rack, it doesn't know how many slots are occupied).

I just want to make sure that the definition of any new fields added to the spec are very clear to avoid further confusion.

[mplsmitch]

@dsgermain Does it make sense to tie zone_area and related fields so closely to stations? I'm expecting that as we add free floating bikes we'll also expand our service area but we may not add additional stations. When that happens, we'll need a way to define geo-fenced areas that aren't adjacent to a station. Your extension will cover that, but we should be careful to leave any business logic out of the definitions.

[AntoineGiraud]

@mplsmitch if you look at SoBi stations, they all are geofenced as their bike lock on anything (zoom in a lot, you'll see various zones for each stations)
however, the geofence of each stations isn't (yet) provided in their GBFS

[nbdh]

Hi everybody,
I'm currently implementing GBFS at nextbike.
In six systems which are operated by nextbike there are so-called "flexzones". Inside of those zones a user can return a bike anywhere.
In the description of the system_regions endpoint (https://github.com/NABSA/gbfs/blob/master/gbfs.md#system_regionsjson) it reads: "It is defined as a separate feed to allow for additional region metadata (such as shape definitions)." I don't know what kind of shape definitions that was intended to refer to, but from my point of understanding the author might had something like a zone for stationless bikes in mind.

Wouldn't it be a good idea to add the information about a zone for stationless bikes in there instead of creating a new endpoint or putting it in station_information? I mean: We are talking about stationless bikes...
I'd propose changing the system_regions to:

Field Name	Required	Defines
regions	Yes	Array of region objects as defined below
- region_id	Yes	Unique identifier for the region
- name	Yes	Public name for this region
- free_bike_zone	No	A valid GeoJSON (Multi?)Polygon that describes the area where free bikes can be dropped off. If no zone exists in this region, this field can be omitted.

[dsgermain]

@nbdh Our zones are extensions of physical stations, so we need to account for this case as well.

[heidiguenin]

PR #175 addresses this issue and represents the solution that's emerged so far as a "minimum viable proposal" that address the main geofencing issues that have been raised in issues and PRs over the past few years.

Once folks have a chance to check it out, I'd like to propose we close this issue and move relevant conversation there.

@mplsmitch @dsgermain @jcn @barbeau @serialc @fruminator @nbdh @AntoineGiraud