Hi, I was going through OSM data (specifically ALPRs ; Automated License Plate Readers) programmatically to identify bad datapoints. I noticed that some surveillance nodes were being marked as ALPRs despite being along a walking path (ie no cars). (Ex: Etowah River Park; Canton, GA) Although I haven’t surveyed the example they’re likely newer cameras that use facial tracking. These newer cameras seem to be different enough from the traditional “camera” or “ALPR” to warrant a separate tag for “Facial Tracking”. Which would also have to be reflected in the osm wiki. I’m new to the forum and would like to know what others think and also whether this is the right place to propose this? The example can be found here (personal site) in a cluster north of Atlanta, GA.
I think recently the world has learnt that “ALPR” is a policy, a policy that can’t be verified and can change at any moment. Flock may have been “ALPR only” at some point, but they aren’t now.
surveillance:type=ALPR is wrong for Flock, and unverifiable elsewhere.
“Facial Tracking” would also be a policy that can’t be verified, it can be turned on at a moments notice with a software update, or when processed elsewhere. (Closed Circuit is the surveillance of the past)
I agree. We can record the existence of a camera, but whatever a software is doing with the recorded images can change any minute.
In hindsight, maybe facial tracking was a poor choice of words. I was thinking specifically of a sort of automated PTZ that would be physically verifiable. example. Maybe something like “Automated PTZ” in camera:type?
Verifiabilty of this sort of thing is always going to be the issue.
Yes, there’s a camera (or a cluster of them) there, but what’s it doing / looking at, especially if it’s inside a dome cover?
Similarly, some cameras can be set up either fixed or auto panning across an area, but they can then also be remotely controlled to zoom in on a specific spot if needed.
Maybe ALPR should be interpreted as the bare minimum of what these things do, not the maximum.
Incidentally, my city is so proud of their ALPRs that they practically boast of them on welcome signs (but not proud enough to point out the cameras’ actual locations).
If only it were so easy and cost-effective to update the signs, maybe they’d not only keep up with technological developments but also rake in a little more in red-light-running fines. (That too is a minimum.)
automated=yes ? No need to further grow camera:type= , and mix it up with another aspect.
There was camera:features=face_detection Proposal:Extended tags for Key:Surveillance - OpenStreetMap Wiki
surveillance:type= itself hasn’t been discussed thoroughly. The 1st Talk section of the follow-on is also the author and users questioning surveillance=*doot , yet it continues to be used. https://wiki.openstreetmap.org/wiki/Proposal_talk:Extended_tags_for_Key:Surveillance#Surveillance=indoor_or_indoor=yes_?
Thank you for the relevant links. I think using [sensor:type=motion, sensor:triggers=camera] along with [camera:type=panning] should be enough for what I was thinking. Also looking at taginfo it seems that others are identifying through the camera model with [camera:model=Condor]. (Seems like its the main use of camera:model) camera:model | Keys | OpenStreetMap Taginfo
Huh, looks like most other camera models, such as Falcon, are tagged as the combination of manufacturer=* and model=* (and manufacturer:wikidata=* and model:wikidata=* if available).