Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
unforgettableid opened this issue Aug 30, 2022 · 11 comments

Comments

@unforgettableid
Copy link

unforgettableid commented Aug 30, 2022

(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
Copy link
Contributor

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
Copy link
Author

unforgettableid commented Aug 30, 2022

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
Copy link
Author

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
Copy link
Contributor

erikmoot commented Oct 6, 2022

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
Copy link
Contributor

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
Copy link
Contributor

richfab commented Sep 26, 2023

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!

@richfab richfab closed this as completed Sep 26, 2023
@futuretap
Copy link
Contributor

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
Copy link
Contributor

richfab commented Sep 27, 2023

@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
Copy link
Contributor

@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
Copy link
Contributor

richfab commented Sep 28, 2023

Good catch! This is the type of data sanity check being discussed in MobilityData/gbfs-validator#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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants