Open rneubauer opened 1 month ago
Is this not the data_source_device_id
field on the Curb Event model?
Thanks for pointing that out! @jiffyclub I probably should have referenced it in the original ticket...
That would work, but there is no reference to that device UUID anywhere else in CDS. We feel mapping the device ID to a defined device in the Curbs API also allows us to connect the dots in third party systems but also allows us to provide some error checking as well, since we would only want to be able to add events to zones or spaces associated with the associated camera. This also prevents double counts for cameras or sensors across the deployment.
One last thought: not all systems use UUID's for their devices and this allows us to digitize third party systems in CDS and then include those devices in the Events with a cleaner tie into the device. For example, most of the cities we are working with want to use the Pole ID for the name camera name.
I see. I think this is perhaps another use-case for the Curb Object concept folks have been discussing in #123.
100% Agree, but I thought it made sense to get some context here and then merge the issues at the right time.
Is your feature request related to a problem? Please describe.
Currently, we are extending the "Events" API to provide Computer-Vision camera based or digital signage events that include metadata for the events and there is no way to provide the device that generated the event. It also needs a relationship to the spaces and zones that are covered by this device. Spaces would be needed for defined parking spaces (paid parking, commercial loading zones, ADA, etc.). It would also need to support zones for tracking events in zones with no defined spaces (bus zones, do not stop zones, no parking zones, etc.). It would also need to have additional fields like type, make, model, color, lat/long, height, resolution, FPS, etc.
Describe the solution you'd like Add an optional device type to the "curbs" api to allow for any type of device like a camera, sensor, or even a digital sign. it would need to follow the UUID approach to the Curbs API.
Is this a breaking change I believe this would only be an addition to the existing schema and wouldn't break it, but given this and the other related items, I think it would require a review to make sure.
Impacted Spec For which spec is this feature being requested?
Curbs
Describe alternatives you've considered
We have looked into leaving that data in our backend database, but doing so would leave some much-needed keys out of the events that we need to post to provide a full cradle-to-grave events and metrics across CDS.