aggregate numbers of available vehicle_types at a station

[davidlewis-ito]

GBFS v2.1-RC introduces the vehicle_types definition and enables the more specific description of the nature of the available docks at each station as well as details of each specific bike there.

Prior to this extension there have been a number of proprietary extensions to the station_status.json designed to communicate aspects of vehicles types such as:

"num_bikes_available": 5,
"num_ebikes_available": 2,
"num_docks_available": 11,

and

"num_bikes_available_types": {
  "mechanical": 1,
  "ebike": 0
},

Whilst the ambition of the GBFS v2.1 to provide per-bike description is very positive, I wanted to explore with the community whether the aggregate description of bike availability might be worth supporting formally. Perhaps in the form:

"vehicle_types_available": [{
  "vehicle_type_id": "abc123"
  "count": 2
 },{
   "vehicle_type_id": "def456",
   "count": 1
 }
]

or more concisely:

"vehicle_types_available": [{
  "abc123": 2
   }, {
  "def456"]: 1
   }]

Without this, it seems we have a rather all or nothing approach to describing vehicles at a station.

It would be great to get feedback from feed publishers.

[kanagy]

For easy comparison, this is how the available vehicles are currently described in station_status (i.e. listing individual vehicles instead of aggregates):

       "vehicles": [{
          "bike_id": "stu901",
          "is_reserved": false,
          "is_disabled": false,
          "vehicle_type_id": "abc123"
        }, {
          "bike_id": "vwx234",
          "is_reserved": false,
          "is_disabled": false,
          "vehicle_type_id": "def456",
          "current_range_meters": 4321
        }]

Note that station_information describes station capacity as aggregates:

       "vehicle_type_capacity": {
          "abc123": 7,
          "def456": 9
        }

I'm not quite sure why available vehicles were not done in the same format as capacity in #136. Perhaps this was to have the reserved and disabled booleans?

Can you explan more what do you mean by "Without this, it seems we have a rather all or nothing approach to describing vehicles at a station.". These additional fields don't seem like a big overhead for producers to describe the vehicles: bike_id is not a key into other feeds (it just needs to be unique) and the two booleans could be set to false when not known.

[davidlewis-ito]

@kanagy I agree it would be possible for producers to expand out the aggregate by simply creating notional bike_id's but being mandated to set the is_reserved, is_disabled and current_range_meters for what may be artificial bikes seems likely to lead to some misinterpretation by consumers.

[sfaubert1]

We agree at PBSC that a count per vehicle type in the station_status feed would be preferable for us than a list of all vehicles with details.

For example, in a city with thousands of bikes, the station_status feed becomes very heavy if we list all vehicles details in this feed. Since station_status is used to populate maps on websites and apps and is pulled frequently to check the availability of bikes/docks, it should remain rather small for a better performance and data consumption.

Maybe consider a count per vehicle type as proposed by @davidlewis-ito instead of the vehicle list per station in the station_status.json and have another feed for all vehicle details for one specific station or another integration that would allow to get the vehicle details differently.

[mplsmitch]

The addition of info about individual vehicles added to station_status.json in #136 scrambled up the data model.

I think free_bike_status should be refactored ( and renamed) to contain all info related to individual vehicles. In docked systems, station_id could be used as the location key. Everything in the vehiclesarray would move to the refactored free_bike_status.json.

Where vehicle_types.json is defined, aggregate numbers, separated by vehicle type as proposed by @davidlewis-ito could go in station_status.json.

If for example you're operating a pedal ( non-electric) bike system where all vehicles are identical and have no varying attributes e.g. current_range_meters, you shouldn't have any reason publish data on individual vehicles and would not need to define vehicle_types.json but you should be publishing aggregate numbers in station_status.json using num_bikes_available.

[sfaubert1]

What would be the next steps for this? A PR and/or a vote? (sorry, I'm getting familiar with the change process)

@heidiguenin FYI, we at PBSC (producer), would be willing to implement and test the changes as proposed by @davidlewis-ito and @mplsmitch above.

[davidlewis-ito]

We would be very happy to consume your data @sfaubert1

I wonder what the best way forward is. I like @mplsmitch concept of removing the per-vehicle elements from station_status so should the pull request both add the aggregate counts and remove the per-vehicle (pending refactoring of free_bike_status) ?

any advice @heidiguenin ?

[heidiguenin]

Thanks, all! Yes, @sfaubert1 the next steps would be to open a PR with the changes that you'd like to see. (If you want to see the current governance and the proposed new governance, you can check out #253.)

Once the PR is open, we need to leave it open for at least 7 days of discussion and further revision before calling a vote, and then the vote takes another 7 days.

MobilityData can create that PR and then be responsive to the requests that come through during the discussion if you'd like, or you can do it, too - what would be your preference? If you'd like us to do it, we'd likely get it open early next week.

[sfaubert1]

@heidiguenin thanks for the info and the link!

It seems I don't have write access to nabsa/gbfs (or my setup is not done properly)? Would you be able to grant me access? If not, then I would have to ask MobilityData to create the PR and I'll work on getting my access and doing my setup properly. Thanks

[josee-sabourin]

Hi @sfaubert1! You would need to "fork" the repo (essentially make a copy of the repo), make your changes on a branch in your fork and then make a PR here that would be a request to merge your branch to the master repo.

MobilityData would be happy to write up the PR since we'll have to touch on quite a few things, PR coming soon! :)

[mplsmitch]

Closing this - taken up in #261