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, ***@***.***> 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 <#81 (comment)>, 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, < ***@***.***> 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 <#81 (comment)>, 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?