mobility-data-specification
mobility-data-specification copied to clipboard
openmobilityfoundation
Vehicle software/hardware properties
Is your feature request related to a problem? Please describe.
Actually some cities are willing to understand the percentage of vehicle equipped with swappable batteries.
This information is usually related to the vehicle generation (v1,v2, etc ...)
Describe the solution you'd like
A potential solution that is non-breaking would be to add this field to the /vehicle endpoint
Is this a breaking change
- No, not breaking
Impacted Spec
For which spec is this feature being requested?
provider
Describe alternatives you've considered
No other idea for now
Additional context
**Endpoint:** `/vehicles`
**Method:** `GET`
**[Beta feature][beta]:** Yes (as of 0.4.1)
**Schema:** [`vehicles` schema][vehicles-schema]
**`data` Payload:** `{ "vehicles": [] }`, an array of objects with the following structure
| Field | Type | Required/Optional | Comments |
| ----- | ---- | ----------------- | ----- |
| `generation` | string | Required | A string representing the vehicle version based on generation naming |
Is vehicle generation or version enough information here? Should there also be a vehicle model number, or maybe that instead of the version? Is it assumed all cities will know about versions/models of provider vehicles, or should other properties be included explicitly, like 'swappable_battery' or 'wheel_size' or 'basket', etc? Maybe this is part of a larger vehicle properties conversation.
Agree that it could lead to a wider discussion on the vehicle properties, but at first, if MDS can expose this version (software layer ?) and generation (hardware layer ?) and we can do the mapping externally without making things too complicated.
Notes from today's Working Group call: https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-conference-notes,-2021.10.28-(MDS-Working-Group)
Could be part of the vehicle attributes discussion in new modes here: https://docs.google.com/document/d/1lzQl_EvrpiDWcJidmnKhn6bAlOdimEBo5u_Yx0BTfmk/edit#heading=h.6m74qj1b4uv1
Also a discussion happening in GBFS here https://github.com/NABSA/gbfs/pull/370
Moving to a future release which could be 2.1 since it would be a non breaking change.