Parking Validation

[droverai]

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

Towards the end of the ride, there's no way to identify if the rider has parked the scooter correctly or not.

Describe the solution you'd like

The parking status towards the end of the ride would help providers and agencies immensely not only to avoid fines but also to understand behavior.

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

None. Not sure if there are any alternatives available on MDS. Please suggest.

Additional context

Add any other context or screenshots about the feature request here.

[schnuerle]

This is a good idea and something we've talked about. Could you explain how your tech works for this and maybe where this information could be slotted into the spec data feeds?

[droverai]

Drover AI's product, PathPilot, has the capability to perform parking validation. When the PathPilot registers a vehicle speed below a predetermined threshold (ex 3 MPH) for a certain number of seconds, its AI algorithm transitions from riding functionality (sidewalk detection, etc) to parking functionality.

We propose the following field "parking_status": true or "parking_status": false to the parking validation event. An additional optional field (parking_category) to explain the context of the parking job. And finally, an optional field (parking_url) for the image of the parking job.

Out of the box, PathPilot looks for 3 ‘valid’ parking outcomes:

1) within ~2ft of the edge of the sidewalk, 2) within ~2ft of bike racks, and 3) within a clearly marked designated scooter corral.

"parking_category" field value of type string when valid would be one of the following: ["corral", "curb", "bike_rack"]

Anything outside is deemed ‘invalid’ with certain selectable ‘extra invalid’ outcomes such as:

• Blocking a curb ramp
• Placement in the middle of the street
• Parking near the wall or doors of the buildings
• parking near a fire hydrant or sidewalk features other than racks
• placement below the curb regions

These higher prioritizations will result in prioritizing responses.

"parking_category" field value when invalid would be one of the following: ["invalid", "extra_invalid"]

For the end-of-ride parking job ("parking_url") can include one or more pictures. "parking_url" : [ "<domain>/parking-image-1.jpg”, "<domain>/parking-image-2.jpg” ]

Drover PathPilot can send an event ( telemetry datum) when the parking status is valid or invalid. Here event means one-off telemetry at the end of the ride. Drover exposes API which gets called by the customers' backend system when the rider ends the ride (typically by pressing the end ride button on the app). This API then dispatches the parking validation job to the PathPilot and in return securely sends all the above info to the customers (providers).

[marie-x]

What if we made it part of Trip metadata rather than Event? As a practice we try not to have Event-specific metadata, but Trip is deliberately more flexible.

[mwillmott]

Hi Folks 👋 Keen to get stuck into this as well... maybe i'm missing something but is there already a proposal for a parking_validation event, or is this it?

One thing i would add is that the parking status might not be known immediately at the end of a ride, and may be updated after ride end (i'm sure the period of time in which this could happen will vary between operators).

I'm happy to provide more input on this from the perspective of another operator but i'd been keen to get input from agencies on the inclusion of parking data.

[schnuerle]

Issue https://github.com/openmobilityfoundation/mobility-data-specification/issues/407 has a discussion of a parking_validation_url as a status change event, if that's what you're thinking of @mwillmott.

I think at end of ride would be the place to put this.

There are some trip data fields that come in later after a ride ends, e.g., the trip meta data can be updated after the trip has already been complete, so a parking_category value could come later when available. Could have enum of ["corral", "curb", "bike_rack", "invalid", "other"]. Maybe for now we just specify invalid for any of those current invalid or extra invalid options? It does seem like an 'other' option is need for when it's parked say just on a sidewalk out of the way, so properly but not in a corral/curb/rack and not blocking anything?

[schnuerle]

Please review the new parking_category field in the Trips data type object ASAP:

https://github.com/openmobilityfoundation/mobility-data-specification/blob/feature-scooter-sensors/data-types.md#trips

Field	Type	Required/Optional	Field Description
parking_category	Enum	Optional	The type of parking location detected or provided and the end of a trip. One of corral, curb, rack, invalid, other.

There is already a parking_verification_url field, with a newly updated description: "A URL to a photo (or other evidence) of proper vehicle parking at the end of a trip, provided by customer or operator."

Per the comment in the PR here, I think we need a definition for invalid and other at a minimum. Please provide this.

[droverai]

Hi @schnuerle - please find the definitions as well as one minor change i.e. instead of other please change it to other_valid. invalid - This is a category just like corral, curb, rack etc... Our AI algorithm is trained to identify invalid parking, e.g. scooter parked in the middle of the street.

other_valid - in certain European cities, our customers have requested special cases of valid parking categories i.e. next to the building. So instead of covering such one-off scenarios in their own categories, we propose "other_valid" (instead of "other")

[schnuerle]

Complete with #829.