curb-data-specification
curb-data-specification copied to clipboard
openmobilityfoundation
There is no way to provide double parking event locations in the Events API with exact location
Is your feature request related to a problem? Please describe.
After implementing cameras at scale across customer cities, the first thing that our customers asked for were double-parking events and locations. After looking into the events API, there is currently only a way to provide a double-parking event in a defined travel lane, but there is currently no way to provide the cross section of where that event happened for an entire block. Other events like unauthorized parking or stopping in the non-travel (parking) lane are mapped to the lane adjacent to the curb and can be provided via the current events API.
Describe the solution you'd like
As a simple short-term solution, we are proposing to add a double parking event tied to a camera ID in https://github.com/openmobilityfoundation/curb-data-specification/issues/147. This will allow us to map the event on maps based on the camera, which will also allow us to report on the affected zones related to that camera. The reason this is a short term solution is because it would not require any breaking changes to the current CDS schema.
Long-Term Solution - We would want to provide the exact lat/long of the double parking events.
Is this a breaking change
No, not breaking - This would not break the current schema and would just be an addition to the existing version.
Impacted Spec
For which spec is this feature being requested?
Events
Describe alternatives you've considered
We have thought about storing this data in our backend databases, but then it will not allow us to provide events via CDS API to other systems to locate where issue are occurring.
The Curb Event model does have an event_location field that allows reporting an exact lat/lon for an event. It seems like the issue might be more that there is no way to indicate that the event is a double-parking event? Available event types are listed here.
That is correct, but unless the exact lat/long can be detected from the CV model there needs to be another reference point to show where it happened in the travel lane along the block. Tying it to an adjacent loading, ADA, or parking zone won't really work for a few reasons:
- If the car parks halfway between two zones, we don't want to get into fractional measurements between two zones.
- We don't really care about the adjacent zone. The drive that is parking is more likely double parking because of a business on the curb that they are picking up food or a delivery form ,etc. which definitely cant be defined in the Curbs API at this point.
This is why we are currently mapping the events to the camera that captured the event and then providing the pixel coordinates in our backed.
@rneubauer
Long-Term Solution - We would want to provide the exact lat/long of the double parking events.
unless the exact lat/long can be detected from the CV model there needs to be another reference point
If you can't determine lat/lon from your camera model, how would it be determined?
We've only been discussing this in terms of double parking events but if I understand it correctly, the issue is that CDS only models the single lane adjacent to the curb. If the solution is to model all lanes in the ROW, are there other data that cities are interested in that would be enabled by this?
Modeling the entire ROW would significantly broaden the scope of the spec so it seems like we should be considering more than just double parking events.
A couple thoughts on this:
- I think the short term solution works really well to just add another event type. Related, I think there are a few other event types we can look to add in related to enforcement (citation given, ALPR Hit, ALPR ticket). I can create a separate issue for this if beneficial, or we can chat through in next meeting.
- The lat/long provides a good option for providing the exact event location while also letting you connect the event to a given curb zone or space. This is how we handle ALPR Reads - we have a specific lat/long then connect the event to the nearest Curb Zone.
- In future, if there is some type of standard to define the ROW space (i.e. the travelling lane adjacent to the curb lane), we could look to have different event types for travel lanes including double parking. This relates to other discussions happening with MDS. However, I don't think this separate lane classification is needed to define double parking for the time being.
We will be talking about this Issue and Pull Request to review specific change proposals in the Working Group meeting tomorrow. Thanks!
We would ideally want to know the transect location of the double-parking violation- is it occurring in the center lane, travel lane(s), bike/transit lane, parking/curb lane, or above the curb (sidewalk or pedestrian zone). So looking for it to ideally contain x and y coordinates, where the y is parallel with the curb, and x translates to one of the 5 different locations it could be (where it is a double-parking violation if it occurs anywhere outside of the parking/curb zone (highlighted in orange).
As a solution for this, to keep it non breaking for 1.1, we would need to still capture lat/lon locations for the event. See #183 for this general concept.
For additional needed double parking context, I think it makes sense to use the new Enforcement draft, per #179. So when a double parking event is known, it would trigger a vehicle_detected event type, and/or a vehicle_violation event type.
Then the enforcement object can be called, and the double parking event can be recorded with the municipal_code and name fields. The name field can include double parking, and some kind of lane identifier as needed.
In the Event, there is already a field called vehicle_blocked_lane_types where you can enumerate the types of lanes blocked (travel, bike, bus, sidewalk, etc).
I think what is missing is recording the time of the end of the double parking event. So for that, I've added a new field in PR #179 that is called violation_ended to record the time, location, id, and details of the end of the violation. See this commit.
Also, to tie together events across the 4 different enforcement event types, I've added an enforcement_id which is a UUID that can be generated the first time an enforcement event is recorded. See this commit.
Let me know if you think this solves it in an adequate way for 1.1. We can explore this in more detail in a future release if needed.
Like stated above, I don't think there is a way to add some kind of linear transect location, without having the right of way defined a bit more, which neither CDS or MDS does now (or anyone does in a standard way) and would be a bigger task for this late stage of CDS 1.1.
We will be reviewing this at tomorrow's public Curb Working Group meeting. However we won't have much time to discuss, so leave your comments and suggestions here as general or inline comments to spark changes before the CDS 1.1 release is made.