Add available bike type(s) in station_status.json

[AntoineGiraud]

How about letting the opperator of the GBFS put optional information about bike types at each station. I'd see it as an object detailing num_bikes_available like:

"num_bikes_available_types" : {
    "3 gears":7,
    "7 gears":3,
    "electric bike":2,
    "special event bikes":2
}

[gaelhameon]

From here:

• station_status.json
  • need a way to distinguish between multiple bike types at a station if/when hybrid systems using e-bikes become available

I'd like to point out that systems using e-bikes will become available January 1st 2018 in Paris as Velib switches from JC Decaux to Smoove. In an email that was sent to Open Data users, they say that the new Open Data platform will use GBFS.

[gaelhameon]

In addition to @AntoineGiraud 's suggestion, it might be interesting at some point to let the operator publish information about every single vehicle. I'm not sure how Velib's e-bikes will work exactly, but I can imagine that they will have a rechargeable battery and that it might be interesting to let users know about the charge level of each e-bike. A user might go to a different station to find a bike that has a better charge if they are planning a long trip.

[nackko]

Excellent news ! I wonder how they're gonna handle the manual/electric distinction. Could I get looped in those Open Data uUsers communications ? Yeah, could they push to estimated range ? End user will want to know what stations are 'reachable' with the battery level of a bike. (I understand it's not trivial). Great times ahead !

On Wed, 27 Dec 2017, 12:10 Gaël Haméon, notifications@github.com wrote:

From here https://github.com/NABSA/gbfs/blob/master/gbfs.md#possible-future-enhancements :

• station_status.json
  • need a way to distinguish between multiple bike types at a station if/when hybrid systems using e-bikes become available

I'd like to point out that systems using e-bikes will become available January 1st 2018 in Paris as Velib switches from JC Decaux to Smoove. In an email that was sent to Open Data users, they say that the new Open Data platform will use GBFS.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NABSA/gbfs/issues/81#issuecomment-354144493, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZbi4rCk2ed0WbTGGUxA4JqD-3aBHneks5tEnn3gaJpZM4RJ1RD .

[gaelhameon]

Here is the full email from developer@jcdecaux.com (the former operator) I don't think that there is a lot more to expect from them going forward. I sent an email to opendata@smovengo.fr asking where there new platform can be found ... I will post any reply here.

Dear Open-Data users,

From January 1st 2018, JCDecaux will not be in charge of the Parisian Vélib' bike-sharing system anymore. After this date, we won't be able to provide any data about it.

Smovengo, the new Vélib’ Métropole service operator starting January 1st 2018, will continue to provide information about Vélib’. A new platform will be set-up in december based on the following specs : https://github.com/NABSA/gbfs/blob/master/gbfs.md

For any further information, please contact opendata@smovengo.fr.

Vélib' is the only JCDecaux bike-sharing system that is impacted. The other bike systems around the world, listed here, are still available.

We have been very pleased to provide you with the Vélib' data since 2013 and we hope that it has helped you in your various projects.

Best regards, The JCDecaux Developer team

[apinho-fm]

Any answer yet? I was checking this endpoint here https://opendata.paris.fr/api/records/1.0/search/?dataset=velib-disponibilite-en-temps-reel&rows=300

But it is only showing 200 stations. I remember that JCDecaux endpoint had many more.

[serialc]

This thread is straying... The new Paris BSS operator is deploying their system as fast as possible. They are late however, and being heavily fined. They have no GBFS feed. I know there is a feed that is GBFS-esque but it's not public. https://twitter.com/serialc/status/952829009200582656

But back to having bike types in the feed...

[nackko]

They do seem to have a botched deployment. They'll probably (hopefully) get more responsive as their urgent issues get fixed.

On Thu, 1 Feb 2018, 13:36 Cyrille Medard de Chardon, < notifications@github.com> wrote:

This thread is straying... The new Paris BASE operators are deploying their system as fast as possible. They are late and being heavily fined. They have no GBFS feed. I know there is a feed that is GBFS-esque but it's not public. https://twitter.com/serialc/status/952829009200582656

But back to having bike types in the feed...

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/NABSA/gbfs/issues/81#issuecomment-362253224, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZbiwaO_v9H4dYIJf6zihzZk5YGHEShks5tQa-7gaJpZM4RJ1RD .

[dsgermain]

I think since bikes can have multiple attributes at once, we should provide a list of bikes with their specific attributes for each station. Thoughts?

{
    "bike_type_listing" : [
        {
            "gears":"3",
            "ebike":"true",
            "charge_level":"67%"
        },
        {
            "gears":"7", 
            "ebike":"false"
        },
        {
            "gears":"7", 
            "ebike":"false",
            "gps":"true",
        }
    ]
}

[AntoineGiraud]

Hi @dsgermain, hi @gaelhameon

On one hand, if you provide the types of all bikes present in each station, you'd have a way heavier station_status.json (500 stations status + 5000 bikes types)

On the other hand, you might be interested in knowing the details of each bike if they are electric. However as a customer, you don't need the full spec details, you just needs a functional information : low charge (20%-), mid charge (20-60), charged (60+)

It's more an operator concern to know the full status details of all of his bikes (it's already available for him through it's bike list with their current status).

I found it important to keep the station_status.json as light as possible

Antoine

[mplsmitch]

Since these bike variables could apply to docked bikes described in station_status.json and bikes described in free_bike_status, and there are now systems having bikes that may be both docked and free floating, how do we do this in a way that's not duplicative?

[dsgermain]

@AntoineGiraud I agree we need to keep these structure light. Can we agree to have at least the following fields as part of the spec? They should be optional, so that mechanical bikes feeds are not affected:

ebike: "true/false" charge_level: "xx%"

@mplsmitch Maybe we could add an endpoint to return additional information by passing in the bike ID? This way, we touch neither endpoint, and if someone needs the additional info, they need to explicitly fetch it?

[mplsmitch]

@dsgermain for what it's worth, Jump/Social Bicycles has been using a charge level field in their DC feed here: https://dc.jumpmobility.com/opendata/free_bike_status.json

Where would the bike ID live in the case of station based bikes? Currently station_status.json only tells the number of bikes present but does not include an identifier.
I also think that as you said earlier since bikes may have multiple attributes, they could be captured in one field like was done in station_information: rental_methods

[dsgermain]

@mplsmitch we could simply add a bike_ids list in station_status.json.

The biggest station in know of out there is around 60 bikes, which doesn't add that much weight to the structure.

In any case, we need to move on this as eBikes are now a reality. I've never been part of one of these extension discussions, what is the process to get it approved?

[mplsmitch]

Does @cubbi or anyone from Jump have an opinion on this? Is there a downside to publishing bike ids and other attributes in both station_status.json and free_bike_status.json. I'm thinking of the future when free floating ebikes go into charging docks.

@dsgermain I'm working on formalizing the change process but for now- The general outline for changing the spec has 4 steps:

1. Propose a change by opening an issue at the GBFS GitHub repository.
2. Receive comments and feedback from the GBFS community and iterate on the proposed change. Discussion lasts for as long as the proposer feels necessary, but must be at least 7 calendar days
3. Find at least one GBFS producer to implement and test the proposed change.
4. Submit a final request-for-comments on the proposed change to the issue discussion. If no outstanding issues are identified after one week’s time, and there is general agreement that the proposed change is worthwhile and follows the GBFS guiding principles, the proposal will be officially adopted.

[dsgermain]

@mplsmitch thanks for the process description. I suppose this thread counts for more than 7 days discussion?

[AntoineGiraud]

I'd still rather say that you don't need the full details of each bikes in station_status.json but more the aggregated information. I'd have then created a bike_status.json in wich you put every bike (docked or free floating) with their details plus the code of it's station or the lng,lat if it's a free floating one.

Some numbers: (550 stations, 5 500 bikes)

• raw json station_status.json : 123 323 chars (~123 Ko) (no information on bike or dock types)
• station_status.json with aggregative bike types (~200 Ko)
  • 550 x "num_bikes_available_types":{"3 gears":7,"7 gears":3,"special event":2,"ebike<20%":2,"ebike<50%":2,"ebike<75%":2,"ebike>75%":2}, = 70400 chars (+ ~71 Ko) the sum of all is the total of bikes available at the station (num_bikes_available)
• station_status.json with all bikes detailed : (~400 Ko)
  • 550 x "bikes_listing":[{"code":"A00123","gears":"3","ebike":"true","charge_level":"67%"},{"code":"A00123","ebike":"true","charge_level":"67%"},{"code":"A00123","ebike":"true","charge_level":"87%"},{"code":"A00123","ebike":"true","charge_level":"11%"},{"code":"A00123","ebike":"true","charge_level":"94%"},{"code":"A00123","gears":"3","ebike":"false"},{"code":"A00123","gears":"3","ebike":"false"},{"code":"A00123","gears":"3","ebike":"false"},{"code":"A00123","gears":"7","ebike":"false"},{"code":"A00123","gears":"7","ebike":"false"}], = 294 260 chars (+ ~294 Ko)

either way, @dsgermain, you're the one that can test it !

[dsgermain]

@AntoineGiraud We'll implement an extension which will be ready end of March. I like the idea of a separate bike_status.json with all the details. On top of that, I would add the following two fields to station_status.json

"num_ebikes_available":0,"num_ebikes_disabled":0

I don't want developers to have to download and parse the whole bike_status.json feed to tell users how many ebikes are at a station.

Here's my proposal for bike_status.json:

bike_status.json Describes all bikes in the system that are not currently in the middle of an active ride.

Field Name	Required	Defines
bikes	Yes	Array that contains one object per bike that is currently docked/stopped outside of the system as defined below
bike_id	Yes	Unique identifier of a bike
lat	Yes	Latitude of the bike. The field value must be a valid WGS 84 latitude in decimal degrees format. For bikes in stations, this is the latitude of the station. See: http://en.wikipedia.org/wiki/World_Geodetic_System, https://en.wikipedia.org/wiki/Decimal_degrees
lon	Yes	Longitude of the bike. The field value must be a valid WGS 84 latitude in decimal degrees format. For bikes in stations, this is the longitude of the station. See: http://en.wikipedia.org/wiki/World_Geodetic_System, https://en.wikipedia.org/wiki/Decimal_degrees
is_reserved	Yes	1/0 value - is the bike currently reserved for someone else
is_disabled	Yes	1/0 value - is the bike currently disabled (broken)
is_ebike	Yes	1/0 value - is the bike an electric bike
is_geofenced	Yes	1/0 value - is the bike locked in a geofenced enclosure rather than at a traditional dock

[AntoineGiraud]

If you don't add the station id, it's the free_bike_status.json plus is_ebike and is_geofenced should you add also the battery charge as optional ?

[AntoineGiraud]

I wouldn't either want developpers to parse the whole bike_status.json to tell the number of eBikes at a station, indeed you have to add it too in station_status.json

However, you'd also want to know the types of the bikes however, you'd want to add more information about the bike's types at a station plus the battery left in those.

That's why i suggested to add an aggregative field "num_bikes_available_types":{"3 gears":7,"7 gears":3,"special event":2,"ebike<20%":2,"ebike<50%":2,"ebike<75%":2,"ebike>75%":2}

if you had put the full list of bikes, you'd have to parse the whole list anyway (and at each stations)

[mplsmitch]

@dsgermain Your bike_status.json looks a lot like free_bike_status.json. Wouldn't it make more sense to extend free_bike_status.json in stead of creating another end point? If we added something like this:

Field Name	Required	Defines
is_docked	Yes	1/0 value - is the bike in a dock?

This would be a way to keep all the information about bikes in one file which seems important if you're thinking about bikes moving between docks and geofenced locations. There would still be some redundancy with station_status.json if you included lat/lon for docked bikes but much less than with two bike info end points.

Also - if you're working on geofencing - what's your take on #65 ?

[dsgermain]

@AntoineGiraud I see your point. Wouldn't the aggregate fields result in problems if bikes have multiple attributes, such as ebike + 3 gears or ebike + 7 gears? It will become hard for a dev to know what the data means unless we make the fields exclusive. I would suggest to limit the fields to a simple separation between mechanical and ebikes with the charge in discrete levels as you propose. What do you think?

@mplsmitch @AntoineGiraud I agree, it is a direct copy/paste and we should merge.

I will reply on #65 directly.

[dsgermain]

Here's what we will implement:

Implement free_bike_status.json as described here: https://github.com/NABSA/gbfs/blob/master/gbfs.md#free_bike_statusjson

Add the following fields:

Field Name	Required	Defines
is_ebike	Yes	1/0 value - is the bike an electric bike
is_geofenced	Yes	1/0 value - is the bike locked in a geofenced enclosure rather than at a traditional dock

Add the following fields to station_status.json:

Field Name	Required	Defines
num_bikes_available_types	Yes	Array that contains one object per exclusive bike type and their count. Exclusive type means a type that cannot overlap with another type. a valid example is mechanical vs electric. An invalid example is 3 gears vs electric, as an electric bike could have 3 gears

example: num_bikes_available_types":{"mechanical":7,"ebike":2}

[barbeau]

@dsgermain Isn't is_geofenced redundant for the free_bike_status.json feed? In other words, the value would always be 1?

The description of the feed says:

Describes bikes that are not at a station and are not currently in the middle of an active ride.

[dsgermain]

@barbeau since we are extending this to return all bike info (whether it is ebike or not), then this feed is not about free_bikes only anymore, but more about "bikes available for rental" in general. At least, that's what I gathered from the conversation from yesterday.

[barbeau]

@dsgermain Sorry, I skimmed the thread but may have missed part of that discussion. Maybe it would be easier to discuss via a pull request to make it simpler to see what the current "proposal" is (i.e., the diff)?

[AntoineGiraud]

@dsgermain free_bike_status.json was really made first for those free floating bikes. however even if it's docked in a station, the bike is still free to be picked up ...

I still think i'd be important to tell the station code of the bike if present in free_bike_status.json The information could then be parsed indeed to give more details and bring it back to the stations level, You'd then have the option :

• to give aggregated counts on the bike types at the station
• or to give full details of all the bikes at the given station

You have 4 options for the bike:

• must be docked at a station (like BIXI)
• can lock at a station rack (like SoBi)
• can be locked in a geofenced hub (like SoBi or the free floating bikes)
• it's a free-floating bike locked anywhere in the street

In the end, a bike can be:

• free floating or docked : is_free_floating_bike
• mechanical or electric : is_ebike
• docked/locked/parked at a station or hub : station_id

Like so, you wouldn't need the is_geofenced meaning is it in a geofenced hub/station, you'd juste put the station_id if you meant is the bike in the whole network allowed geofence, it's relevant @barbeau is it more clear ?

By the way, I don't see the hub zones of SoBi stations: i don't know if it's added yet in the GBFS or not never mind: it's the issue #65

Yes, I guess we can go toward a pull request now !

[barbeau]

@AntoineGiraud I think so, but yes, a PR would definitely help :)

[dsgermain]

Just so I'm clear on process, you're talking about a pull request directly on gbfs.md?

[barbeau]

Just so I'm clear on process, you're talking about a pull request directly on gbfs.md?

Yes - defining exactly what would change as part of this proposal.

[mattdsteele]

Hi! Did this end up getting implemented? I'm looking at the results for a few of the bcycle networks in my area (Omaha & Lincoln) and I see the num_bikes_available_types key in e.g. https://gbfs.bcycle.com/bcycle_heartland/station_status.json :

      {
        "station_id": "bcycle_heartland_1916",
        "num_bikes_available": 3,
        "num_docks_available": 7,
        "is_installed": 1,
        "is_renting": 1,
        "is_returning": 1,
        "last_reported": 1542847892,
        "num_bikes_available_types": {
          "classic": 3,
          "smart": 0,
          "electric": 0
        }
      },

I think I know what "classic" and "electric" refer to, but I'm not clear on what the "smart" property is. Any idea?

[serialc]

Smart bike-share was a branding craze, like smart cities, from 2015-2016. Instead of having the checkout key on the dock or at the kiosk, on a smart bike it is on the bike. There's a display and smart card reader between the handle bars, or over the back tire. This has the potential to reduce price/cost. I guess you could say that 'new' dockless systems (Mobike, Of, etc...) are also smart bikes. Many of these systems, such as those from Vancouver or Portland, are docked and don't actually make their use any different. I think the membership keys used on docks by PBSC/Motivate are faster and easier to use (WDC, NY, Boston, etc) than smart bikes. There was some potential for smart bikes to be dockless or both/flex, with obvious benefits (and problems) but that hasn't seemed to have happened (Correction, I believe SOBI bike-share systems are). So it's mainly branding. I remember Vancouver and Portland claiming to have the largest smart bike-share systems in North America even though they only have/had a tenth of the bikes of NYC. The smart bike-share claims appeared to have died down while the (also smart) dockless bikes flooded NA in 2017.

In closing, smart bikes afford different use and interaction types but not always taken advantage of and is largely used as a branding and market differentiation tool.

[heidiguenin]

PR #136 addresses this issue and represents a heap of input from GBFS consumers and producers. We're hoping we can solidify support around it as the next step forward. It would be great to get all of your input over there on the solution that's emerged so far as a "minimum viable proposal" that better represents what operators are providing on the ground.

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

@mattdsteele @serialc @barbeau @dsgermain @AntoineGiraud @mplsmitch @f8full @apinho-fm @gaelhameon