|Definition:||area covered by camera surveillance|
Nodes with man_made=surveillance mark the spots for security cameras but this offers little information on the area under their surveillance. Adding a surveillance=outdoor to, say, market places is possible but requires either splitting the market place along the monitored area extents or leads to inaccurate tagging when some corners are outside the cameras' view. A relation is able to capture the relation between the camera and the corners, i.e. "this or these camera(s) can supervise an area up to these nodes".
|surveillance_hours||as in opening_hours=*||optional|
Where a way or and an area is a member in the role visible, it is interpreted to be visible for all it's parts.
For each camera, add one relation. Any objects or nodes that limit the area overseen by the camera, or that are in that area, are or can be added. Assessing the extents is often guesswork but ought to be reasonably accurate. Where the inside and outside are ambiguous when defined by extents only (revolving cameras, for example), or only the main focus of surveillance is clear, or appropriate nodes are not already present, objects in the role visible or hidden are welcome.
Where some features inside the otherwise visible area are behind obstacles blocking the view, they can be defined also. An example could be a small (low) shed on a plaza and whose door is on the side not visible to a camera, but the building (and it's door) behind the shed is again visible.
Where only one or few visible objects are in the relation, the supervised area can be modeled somewhat like a probability field centered on those nodes and elongated towards the camera; and possibly clipped by any building=* features.
At least one feature with a role extent or visible (or empty) is required.
Group several cameras with one operator together. Any features visible on any of the cameras are added (or the perimeter objects) - information on which camera sees what is partially lost but the existence of supervision might be sufficient information for most.
At least one feature with a role extent or visible (/empty) is required.
Several cameras, possibly operated by the same institution or company, could be grouped in one relation by using a freeform text as the role to tie each camera to it's extents. Every camera is already, hopefully, tagged with man_made=surveillance so the other members in the same role are the extents. Possible only when no two cameras share extents of the field of view as one object can not be a member of a relation multiple times. Likely the worst solution, comments on the discussion page.
|Way or Node||Role||Recurrence?||Description|
|#n||one or several|
I've added lots of these near my local city center (some 200 cameras) and have not used the method 3 above one single time. Remarks:
- Cameras in the corner of building overseeing only one wall kind of often require one node somewhere along that wall - but that's just a reason to add a node and tag it as a building=entrance. Using only the far corner is possible, if the city block is not too long and reasonably guessed incomprehensible by persons seeing the surveillance feed.
- Cameras are sometimes or quite often under a canopy - this needs still some thought; For now I've added the camera just a bit outside the building wall and marked only the entrance at that point as visible. This is not quite exact when the camera is revolving=yes.
Please use Talk:Relations/Proposed/Surveillance.