mobility-data-specification
mobility-data-specification copied to clipboard
openmobilityfoundation
Create data type for Places within Stops
Is your feature request related to a problem? Please describe.
As brought up in Provider and City Services WG calls when discussing the preliminary spec for Stops in MDS, there is a desire to represent more information on a per-Place level. Examples of Places could range from vehicle docks, to painted parking spots on the curb, to dynamically allocated curb areas for parking, etc... Various kinds of places can have additional properties: in the case of docks (very relevant for micromobility), charging is the first thing that was brought up on the WG calls.
Describe the solution you'd like
Create a data type for a Place that lives within a Stop. Minimally, it should consist of a:
- Unique identifier (UUID) for each Place.
- Property/properties which represent charging capabilities of the Place. Scooters, bikes, electric cars, and many other EVs have different charging ports, and charging requirements -- how can we best represent these options? Is there a standard we can pull from, or should MDS define its own?
- List of vehicles which are currently at the Place.
Possible additional properties that could be beneficial to add include:
- Capacity for a given Place (similar to what we do for Stops, potentially this could result in no need for that information to live at the top level of a Stop)
- Availability at a Place given current occupancy. This is tricky because a Place could potentially house certain permutations of multiple vehicle_types simultaneously, while not allowing others (e.g. you could have a bike and 2 scooters, but not a car and 2 scooters), however I think it could be exceptionally powerful if we come up with a good way to represent this.
- If vehicles are currently using the charging capabilities of the Place, with details on their usage.
These would be added to the Stop definition under a places property defined as:
| property | type |
|---|---|
| places | Place[] |
Is this a breaking change
- I'm not sure
One could argue it's breaking if it potentially deprecates existing properties which live at the Stop level, however we can probably work around that. Additionally, Stops are currently in beta, so there may be more flexibility around potentially-breaking changes.
Impacted Spec
For which spec is this feature being requested?
-
agency -
provider
Describe alternatives you've considered
Including charging capability at the top level of a Stop, I attempted to design that early on in the drafting of Stops, and there was no clean solution I could find.
Additional context
Some historical context can be found here
We will be discussing this tomorrow at our Joint Working Group meeting, so attend if you are interested. @avatarneil
https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-conference-notes,-2020.09.17-(Joint-Working-Group-City-Services)
From working group call yesterday.
Need use cases for place definitions within Stops. Need proposals for charging capabilities. Need feedback on this issue from the community to assess demand and need/priority. Will mention at next Provider WG call
How does GBFS handle spaces? Has it included in station_information.
- Capacity count (capacity)
- Capacity by vehicle type count (vehicle_type_capacity and vehicle_capacity) - but this assumes there are a set number of places per vehicle type, not a certain size capacity total to be used by multiple vehicles. So more of a physical dock definition per vehicle.
Estimated # of devices in a corral or spray painted area on the ground can be challenging. Eg an area might fit 1 car, but 3 bikes or 6 scooters. Should we capture the dimensions of vehicles in new fields? Should this apply to charging/docking/locking stations with physical connections only?
@avatarneil Is this something you think you have a clear enough idea of to make PR for?
@avatarneil Is this something you think you have a clear enough idea of to make PR for?
@schnuerle One thing I'm still trying to figure out is how to best represent all of the possible permutations of capacity. Do we think it'd be okay if for now capacity is exclusive: e.g. fits 2 bikes or fits 4 scooters or fits 1 car, and not handling cases like: fits 1 bike and 2 scooters simultaneously? Additionally, I'd love to have detailed information about charging (thinking about how there are different chargers for EV cars), but I'm not sure if there's a good specification we could pull from for that, or if it's even necessary for the time being.
If we're okay with the simplified version of capacity (exclusive to one vehicle_type at a time instead of potentially multiple vehicle_types occupying the same place simultaneously), and simplified version of charging (just a boolean or something), I can definitely make a PR for the 1.1 timeframe.
Moving this to a future release, maybe the next release, per a conversation with @avatarneil about his availability. If anyone else wants to start to tackle this please do.