MobilityData / gbfs

Documentation for the General Bikeshare Feed Specification, a standardized data feed for shared mobility system availability. Maintained by MobilityData
https://gbfs.org
Other
785 stars 290 forks source link

Dear PBSC: Please publish current_fuel_percent data, to reveal the battery charge of each e-bike #448

Closed unforgettableid closed 12 months ago

unforgettableid commented 2 years ago

(PBSC is a company which sells bike-share products and services worldwide, including a technology platform. If a city uses PBSC's technology platform, the city will include publicbikesystem.net somewhere in its feed URL.)

Dear @fbouchPBSC:

Background information

Hi! I'm a Bike Share Toronto customer, with a yearly membership. I don't develop any bike-share apps, but I do use such apps.

I mostly use Cycle Now and the official PBSC app. I used to occasionally use the Transit app as well. Unfortunately, the Transit app can no longer unlock PBSC bikes, and I rarely or never use that app anymore.

I see that PBSC now offers GBFS v2.3 endpoints for all PBSC cities. This is good news.

My request

I wonder if you could please open an internal ticket, so that PBSC will start to publish current_fuel_percent data for all e-bikes? This is an optional (but useful) field in the GBFS v2.3 specification. It reveals how much battery charge each ebike has left.

Conclusion

Thank you for reading this, and for all the work you've done for PBSC!

fbouchPBSC commented 2 years ago

Hi,

in GBFS V2.3, current_fuel_percent is provided only in the free_bike_status.json file. We don't publish this file since our bike share system is currently dock based only (no free floating bikes).

Thanks,

Francois

unforgettableid commented 2 years ago

Hi Francois,

Things might have been different in GBVS v2.2. But, nowadays, GBFS v2.3 writes that free_bike_status.json is:

"REQUIRED for free floating (dockless) vehicles. OPTIONAL for station based (docked) vehicles."

So, it is now completely acceptable for docked-only bike-share vendors to publish a free_bike_status.json file (as of GBFS v2.3).

our bike share system is currently dock based only (no free floating bikes).

True.

Some cities don't want to buy docks, because docks are expensive. Other cities want to provide a combination of docked and dockless bikes.

I myself would like it very much if Bike Share Toronto offered at least a few dockless bikes. Being able to end a trip at any arbitrary place would increase the system's freedom and convenience.

Lyft now owns PBSC (and also part of Motivate). Lyft already owns its own free-floating e-scooter technology, which it calls "Lyft Scooters" (not "Spin"). If Lyft would adapt its free-floating e-scooter technology into an optional free-float add-on technology for PBSC bicycles, then perhaps Lyft could sell more bikes and make more money.

unforgettableid commented 1 year ago

Hi Francois,

Things might have been different in GBVS v2.2. But, nowadays, GBFS v2.3 writes that free_bike_status.json is:

"REQUIRED for free floating (dockless) vehicles. OPTIONAL for station based (docked) vehicles."

So, it is now completely acceptable for docked-only bike-share vendors to publish a free_bike_status.json file (as of GBFS v2.3). This, in turn, will allow them to publish current_fuel_percent data.

Is this something you might be interested in doing in the future? Or do you have too many other higher priorities? :)

If you have too many other higher priorities, I can close this issue as "won't fix".

erikmoot commented 1 year ago

This would be the choice of the operator/supplier and not an issue with the GBFS feed standard. I would take this up with Bike Share Toronto or PBSC.

We recently did added battery levels in Vancouver as part of the introduction of ebikes however I have not seen any data consumers use our battery data publicly. It is still rare for a docked operator to provide this.

mobilitydataio commented 1 year ago

This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 60 days if no further activity occurs. Thank you for your contributions.

richfab commented 12 months ago

I'm closing this issue as it is at the operator's discretion to publish current_fuel_percent or not. Thank you @unforgettableid and happy riding in Toronto!

futuretap commented 12 months ago

We recently did added battery levels in Vancouver as part of the introduction of ebikes however I have not seen any data consumers use our battery data publicly. It is still rare for a docked operator to provide this.

@erikmoot interesting but I don’t see them. Do we use the wrong feed?

richfab commented 12 months ago

@futuretap The battery level expressed in current_range_meters is published for some vehicles in free_bike_status for the Mobi Bike Share feed that you shared:

{
  "bike_id": "25fb7542130b0b40ca7d5c93e5bcca6a",
  "is_reserved": false,
  "is_disabled": false,
  "vehicle_type_id": "2",
  "last_reported": 1695818839,
  "current_range_meters": 10000, <--
  "station_id": "0065"
},

Or were you specifically looking for current_fuel_percent information?

futuretap commented 12 months ago

@richfab Thanks, of course you’re right. I didn’t scroll down far enough to the e-bikes. I just noticed that max_range_meters in the vehicle_types should be 50000 since it’s measured in meters, not km.

richfab commented 11 months ago

Good catch! This is the type of data sanity check being discussed in https://github.com/MobilityData/gbfs-validator/pull/106.

In https://vancouver-gbfs.smoove.pro/gbfs/2/en/vehicle_types.json:

{
  "vehicle_type_id": "2",
  "form_factor": "bicycle",
  "propulsion_type": "electric_assist",
  "default_reserve_time": 30,
  "max_range_meters": 50 <-- should be 50000 since it’s measured in meters, not km
}
erikmoot commented 11 months ago

@richfab Thanks for flagging that. I'll bring it up with our supplier.