Add new vehicle accessories and parts
viestat opened this issue · 6 comments
whoami
My name is Andrés Viesca and I am a software engineer at Dott, I have been working on implementing and maintaining Dott's GBFS service (gbfs.api.ridedott.com).
What is the issue and why is it an issue?
We have some vehicles that have different accessories or parts that cannot be currently exposed to consumers as part of the latest version of GBFS.
Helmets
Some of our vehicles have a compartment for a helmet. It unlocks when the ride starts in order to make the helmet accessible, at the end of the trip it needs to be put back. We want to expose information regarding the presence of the compartment and the helmet itself.
Potential solutions
-
We would like to add this information to the
vehicle_accessoriesproperty of the vehicle_types.json feed. In order to indicate that this vehicle has a helmet compartment (but not necessarily if the helmet is present or not, see next point). -
Since we have a sensor that indicates whether the helmet is in the compartment or not we would like to provide this information in the
vehicle_equipmentproperty of the free_bike_status.json feed so that consumers have a way of knowing when the vehicle (with the helmet compartment) has a helmet or not.
Manual lock
Some of our vehicles have a manual lock. It unlocks when the ride starts and needs to be locked before ending a ride. We want to expose the presence of this manual lock so that consumers are aware of this.
Potential solutions
- We would like to add this information to the the vehicle_types.json feed, however I am not sure if the
vehicle_accessoriesproperty is the right place for it or not. So any suggestions are welcome.
Other thoughts
In general it seems that the matching vehicle_accessories and vehicle_equipment properties in both feeds accommodate for these kinds of situations, however it is odd to have to change the spec every time one needs to be introduced. Maybe it would be just good enough to add a constraint for matching stings across both feeds and make it more flexible?
Is your potential solution a breaking change?
- Yes
- No
- Unsure
Hi Andrés,
Thanks for opening this issue, these are useful and interesting suggestions.
Based on your description it sounds like the suggestions can work as a practical solution since these features fit the field descriptions in the current spec. Considering that the manual lock is a "permanent" feature of the vehicle it does make sense to be considered as a value within vehicle_accessories as these should be parts of the vehicle that are not supposed to change frequently. The same applies to the helmet compartment.
Depending on the way that the information is intended to be transmitted to the end user, an alternative could also be to list the manual lock feature as another enum option for the return_constraint field under vehicle_types.json (i.e. following similar rules to free_floating or any other rule, but adding a lock requirement). This could be useful if the goal is to inform the end user that they are required to lock the vehicle before ending their trip, rather than communicating that it’s a vehicle feature (i.e. something that the rider would want to filter for before deciding which vehicle to use). Having said that, it would be important to check how this would interact/overlap with existing values in this field, something that it’s not entirely clear to me at this moment.
It would be interesting to hear about other potential uses from the community to weight which could be the most useful way to incorporate these elements into the spec.
On your thoughts about the flexibility of the spec to adopt new values, We’re always interested in hearing suggestions to improve the spec governance process. In this particular case, the current purpose is to make sure the change is needed across the community and the definition of new values is agreed upon, but it does require considerable time/effort to make these small changes. Perhaps it might be useful to periodically reach out to producers/consumers to ask for new values they are interested in incorporating into the spec, potentially streamlining this change process. This might be something worth discussing in a future developer’s workshop.
Hello @viestat , I have a few questions -
Helmets
Some of our vehicles have a compartment for a helmet. It unlocks when the ride starts in order to make the helmet accessible, at the end of the trip it needs to be put back. We want to expose information regarding the presence of the compartment and the helmet itself.
I can see why as a user I would want to know whether of not a helmet is present when choosing a vehicle. As you suggest this could be done by adding helmet to the list of valid values for vehicle_equipment. What I don't understand is why would a user want to know that there is a helmet compartment on the vehicle? Would a user choose a vehicle based on this, regardless of whether or not it contained a helmet? If that's not the case, then it feels like including the helmet compartment in vehicle_types could lead users to believe that the vehicle has a helmet when there is no helmet present in the compartment.
Manual lock
Some of our vehicles have a manual lock. It unlocks when the ride starts and needs to be locked before ending a ride. We want to expose the presence of this manual lock so that consumers are aware of this.
Is the issue that users aren't locking the vehicle a the end of a ride? I'm not sure listing the presence of a lock under vehicle_equipment is going to solve that. The systems that I'm familiar with don't allow rides to end until the lock is closed but maybe your locks don't support that. return_constraint wouldn't support this very well, you would have to duplicate all of the defined enums and add manual lock to them.
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.
Hello @viestat,
Is this issue still relevant to Dott? If you resolved this issue, I'd be curious to know how you chose to do it.
Thank you,
Fabien
This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.
This discussion has been closed due to inactivity. Discussions can always be reopened after they have been closed.