Adopt additional parking facilities information

[rwdbrooks]

Is your feature request related to a problem? Please describe.

Yes. As more mobility providers add infrastructure in the ROW, the City of Minneapolis has been having challenges understanding where parking facilities are located and what their different features are.

We'd like mobility operators to regularly report where their parking facilities are so we can know where they are, what features/amenties they have and to be able to direct riders to those locations and create optional or required parking zones. The City would also share its parking infrastructure as well.

Additionally, as we add more and different parking facilities; racks, docks, hangars, etc. with various features; power, security, etc. we need to better track what capabilities and capacities these new facilities have for residents & users.

Describe the solution you'd like

We would like to add data fields and new variables that can capture the different data necessary to map and understand their locations and different features.

Is this a breaking change

• I'm not sure

Impacted Spec

For which spec is this feature being requested?

• agency
• provider

Describe alternatives you've considered

Receiving regular reports or maps from individual providers.

Additional context

[rwdbrooks]

Here are the fields and variables we've come up with to start. We've grouped them under Station Information, Station Location, Station Status, and Station Features to start. Some of these fields are included, but I wanted a full list to start.

Station Information

Station ID:
Name:
Operator:
Station type

• Dock
• Rack
• Hitch
• E-Station
• Virtual Corral
• Valet Zone
• Locker
• Enclosed Facility

Secure

• True
• False

Permit #:
Contact info:
Station Usage (who can use it)

• Public (anyone)
• Private (only their customers)

Rental methods

• key (operator issued vehicle key / fob / card)
• Credit card
• Pay pass
• Apple pay
• Android pay
• Transit card
• Account number
• Phone

Station Location

• Latitude
• Longitude

Address:
Cross-street:
Property Owner

• City
• County
• State
• Federal
• Tribal
• University
• Park Board/District
• Private
• Other

Station Attached (is it attached in the ground or not)

• None
• Permanently affixed
• Temporarily affixed

Ground type

• Turf
• Dirt
• Brick
• Concrete
• Pavers
• Specialty Surface
• Other

Location Type

• On-street metered
• On-street non-metered
• Off-street parking lot
• Underground parking
• Sidewalk/Furnishing zone
• Other

Station Status

Is Installed

• True
• False

Is Renting

• True
• False

Is Returning

• True
• False

Is stored in place (for seasonal removals)

• True
• False

Hours of operation:
Capacity

• Number of total places per vehicle type

Station Features

Electrified

• True
• False

Charging Capacity

• Number of total places per vehicle type

Vehicle types it can serve

• Scooter
• Bike
• E-bike
• Cargo bike
• E-cargo bike
• Moped
• Other

Vehicle types it can charge by vehicle type (or connector types)

[schnuerle]

Thanks Russ the details you provided in this issue are great.

It's an interesting idea. It seems we would need to allow:

1. cities to publish this through Policy (which is part of Stops, but with not as many fields as you are suggesting), and
2. allow operators to publish as well (which we don't have now, mostly because it's usually the cities who are the authority on this on stations in the right of way).

GBFS does have a way to for operators to publish, which has good information, but not all the fields you list:
https://github.com/MobilityData/gbfs/blob/master/gbfs.md#station_informationjson

Some of your ideas overlap with ways of defining things at the curb with the CDS, and something we are thinking of expanding in the next release (like other curb area adjacent elements that facilitate or impede curb transactions: trees, utility box, bench, ramp, art, bike rack, planter, meter pay stations, signal cabinets, scooter parking. Specific focus on EV Charging in spec - status Active/Charging/Inactive, reliability, uptime).

So now others can chime in here, and the steering committee can look at this to bring to a future working group meeting as a topic too.

[schnuerle]

Some of these ideas like around publishing stops in Policy are discussed in #638 as well now.

[pierre-bouffort]

As I mentioned in Issue #925, I think this would typically be features we would potentially get more value out of by sending that over to CDS instead of growing a massive Stops API in MDS which would, from my perspective, compete with CDS Curbs API.
Happy to discuss this more in depth, as this is a very strategic question, and the devil will be in the details on this.