Proposed features/Extended tags for Key:Surveillance

From OpenStreetMap Wiki
Jump to: navigation, search
Extended tags for Key:Surveillance
Status: Draft (under way)
Proposed by: Ewald
Tagging: surveillance:*=*
Applies to: Node, Area
Definition: proposal to allow extended and more accurate tagging of surveillance measures in public spaces
Rendered as: preferably not on the main map, but on a separate overlay
Draft start: 2010-08-15
RFC start: 2013-02-14
Vote start: -
Vote end: -


Proposal

This proposal seeks to extended the tagging of surveillance measures and document their usage. This will open up the possibility for more accurate and detailed overlays aimed at visualizing the presence of surveillance measures. While my personal focus is mostly on camera surveillance, I want this proposal to open up the possibility of mapping the broadest possible spectrum of surveillance.

Rationale

Quite a few people like me are looking for ways to increase the public awareness of surveillance measures, especially when it comes to the presence of (cctv) cameras. Currently there is the tag man_made=surveillance for very broad tagging of such measures and there is a proposal for Key:Surveillance which aims to tag certain areas as 'under surveillance'. Both are not as accurate and as broad as I want this current proposed set of tags to be.

This proposal is aimed at (allowing) more accurate tagging of specific measures and areas by implementing keys and tags to describe the presence of surveillance in detail.

Notes

  • This proposal does not aim to map speedcameras, or other traffic violation apparatus, there are separate projects for that, notably under Relation:enforcement and highway=speed_camera. I can however imagine the mapping of traffic surveillance cameras and/or license plate tracking devices, but I'm not sure yet if this fits into the current proposal. (View the Talk page section on this issue)
  • It certainly is a lot of work to map for instance London, due to the mind-boggling number of cameras. However, this is one of the main reasons for establishing these tags: to create public awareness of the omnipresence of surveillance. As a side note, from this follows that rendering these on the main OpenStreetMap is not preferable, as it would obstruct the regular usability of main city maps enormously.
  • I realize that especially the non-camera tags might feel a little iffy, especially as it basically comes down to mapping security measures which will allow both good willing people and people with ulterior motives to assess these measures from the safety of their own home. I want to stress that these tags are first of all here because I was striving for completeness for the Surveillance key. Second I want to plead caution when mapping these as especially banks and governments may want to avoid having this information out in the open. (View the Talk page section on this issue)
  • To build upon the previous note: mapping security measures might in some places or countries be both unwanted and illegal, take caution. (View the Talk page section on this issue)

Proposed tagging

The proposed new tags consist of three different kinds:

  • general 'required' tags to allow identification of a node or area as falling under the scope of this proposal
  • additional tags which are applicable to all different surveillance:type options.
  • tags specific to a certain surveillance:type option

Required tags

Or 'kindly suggested minimum'.

Key Value Element Comment Rendering Photo
man_made surveillance Node Area Generic main tag for tagging surveillance measures
surveillance indoor/outdoor Node Area This tag enables you to define a node that is concerned with surveillance as being indoor or outdoor. Alternatively you can tag a full area as being 'under surveillance' and the area concerned is hereby deemed to be indoor or outdoor. (View the Talk page section on this issue)
surveillance:type camera, sensor, guard, guarddog, other Node Area This tag is used to further clarify the type of surveillance found at this specific node or within a specific area. If used on a certain area, multiple values can be given.

A camera refers to any kind of device that records visuals. A sensor will most of the time refer to a motion sensor of some kind. I chose not to go with the value of 'motion' as it would be less specific, especially out of the context of a motion sensor. The guard value refers to the presence of one or more security guards whereas the dogs value refers to the presence of one or several guard dogs. Of course feel free to suggest additional categories.

Additional generic tags

In addition to the above, a few other tags are highly wanted:

Key Value Element Comment Rendering Photo
image http:// (or maybe interwiki?) Node Area I want to stimulate the adding of links to self-made photographs (especially of cameras), therefore I added this to the suggested additional tags.
source:location waypoint Node Area As image=* implies source=photograph, I prefer adding an additional tag in case I was able to pinpoint the exact location of a camera using the GPS waypoint function of my GPS device. source:location=waypoint was mentioned on the tagging mailinglist and seemed appropriate for this situation.
operator and surveillance:operator User Defined Node Area The generic operator tag can be used to provide info on the person, company or governmental body behind this tagged surveillance measure. When tagging a building or area ("surveillance in this building/office park is provided by [name company]"), it might be preferred to add surveillance:operator instead to avoid confusion with the general building operator.

Surveillance item specific tags

For these item specific tags I went with camera:, sensor:, etc. I decided to omit a surveillance: in front of these tags to avoid lengthy tags and to ease the entering of said tags in your editor. But please let me know if and why a preceding surveillance: is preferred.

Camera

Key Value Element Comment Rendering Photo
camera:type fixed/panning/dome Node Camera:type will define the main characteristic of the camera. This additionally allows the rendering of type-specific overlay graphics. In case a photograph is specified through the use of image=*, others can use that to fill in this tag if it is not present yet.
  • fixed' would refer to a camera normally incapable of moving, always pointing in a certain direction, only movable by physically adjusting it, ie. non-remotely and non-automatically moving (View the Talk page section on this issue)
  • panning would refer to a camera capable of moving, either along a set path or through the remote use of a joystick or something along those lines
  • dome would refer to a characteristic dome camera, with usually a dark 'glass' dome under which a freely moving camera is situated
camera:mount wall/pole Node This clarifies whether the camera is wall-mounted or mounted on a separate pole. This additionally allows the rendering of mount-specific overlay graphics. In case a photograph is specified through the use of image=*, others can use that to fill in this tag if it is not present yet. Please leave suggestions for the terms mount, wall and pole, especially in case there are terms already in use to define such a characteristic. (View the Talk page section on this issue)
camera:make and camera:model User Defined Node These two tags will allow a user to look-up very specific information on the capabilities and characteristics of the camera. Normally it will be hard to see the specific make and model, but some users might be able to identify the camera properly. In case a photograph is specified through the use of image=*, others might be able to use that to fill in this tag if it is not present yet. Note that camera:model does not refer to type (there is camera:type for that), but to the specific model name a manufacturer has given the camera.

I have tried to search the wiki to find terms already in use for tagging make, model, brand, manufacturer, etc., but I couldn't find any so far. Please leave suggestions, also on whether or not two separate tags are preferred to a single camera:makemodel. (View the Talk page section on this issue)

camera:features microphone, nightvision, zoom, motion, wireless, webcam, heatvision, other Node This obviously optional tag is used in case there are certain camera features worth noting. Please leave comments on the term features in case another term is preferred. Adding multiple features should of course be possible. When camera:features=webcam, please add contact:webcam=*. (View the Talk page section on this issue)
camera:direction 0-360 Node The camera:direction tag allows users to specify which direction the camera is pointing, using the compass degrees as value (the term or symbol for degrees is implied). This allows overlays to draw the field of view of different cameras. See also Proposed_features/direction and Wikipedia. (View the Talk page section on this issue)
camera:angle 0-360 Node The camera:angle tag allows users to specify at which angle the camera is mounted. Please leave suggestions as to a convenient notation (suggestion: degrees, but still working on a way of easily measuring this in the field). This allows overlays to draw the field of view of different cameras. (View the Talk page section on this issue)
height 0-? m or 0-? ft Node The generic height=* tag provides info on the height at which the camera is mounted. This allows overlays to draw the field of view of different cameras. "By default, values are interpreted as meters. Other units need to be explicit."
camera:recording no, yes, snapshots, on_movement, online_streaming Node

Sensor

(View the Talk page section on this issue)

Key Value Element Comment Rendering Photo
sensor:type motion/wifi?/rfid?/other Node Allow the specification of the type of sensor we are dealing with. Sensor tagging is meant for sensors in public areas. This category is meant to complement the optic sensor, which the camera is in a way, and allow the tagging of any other sensors. For instance motion detection, or wifi/rfid sniffing (in case that is ever implemented as a surveillance measure somehow). Maybe even generic 'traffic counters' measuring the number of people walking by in malls or the number of cars driving by on a certain road, can be tagged with the sensor tag.

Either way this tag opens up the possibility of tagging surveillance measures the future might bring us. Who knows, maybe the long range full body scanners might just become common some day.

sensor:triggers light, alarm, camera, logging, other Node This tag specifies the item that gets triggered/activated once the sensor registers something. Not sure on the wording of sensor:triggers, please leave suggestions if you have any. The 'logging' trigger means that sensors such as wifi/rfid sensors will log any data they 'sense'. It could also refer to logging the number of people passing by.
sensor:make and sensor:model User Defined Node See camera:make and camera:model.
sensor:direction 0-360 Node See camera:direction.
sensor:angle 0-360 Node See camera:angle.
height 0-? m or 0-? ft Node See height in the camera section.

Guard

Maybe less interesting than the above, but still added for completeness. (View the Talk page section on this issue)

Key Value Element Comment Rendering Photo
guard:type stationary/roaming Node Area Whether a guard is keeping at this specific node or roaming in this area.
guard:features armed, other Node Area Re-using the features portion of camera:features for consistency. Might be used to specify whether a guard is armed?
guard:number or guard 1-? Node Area The number of guards regularly found on this spot or in this area.


Guard dog

Not that interesting either, again, for the sake of completeness. (View the Talk page section on this issue)

Key Value Element Comment Rendering Photo
guarddog:type User Defined Node Area Might be used to specify the breed of dog, I guess.
guarddog:number or guarddog 1-? Node Area The number of guard dogs regularly found on this spot or in this area.


Current tagging

Currently there are some stats on man_made=surveillance.

Rendering

As noted above the proposed tags, rendering these on the main OpenStreetMap is not preferable, as it would obstruct the usability of main city maps enormously. However, an overlay would be able to render these and in the future it might even be able to handle characteristics such as height, angle and direction to draw field of view as well. In that light, I might add a 'field of view' or 'mobility' tag to allow panning and dome camera's to be represented accurately. Please leave suggestions if you have any.

Current rendering

Note that the above overlays usually just map any man_made=surveillance as a camera, which will be different once this proposal comes through. This is not too big a deal as, in my opinion, the increased accuracy this proposal brings with it's acceptance, more than makes up for the adjustment of overlay rendering.

Comments

RFC has started on 2013-02-14. Please leave your constructive criticism on the Talk page.

Voting

Voting has not yet started, once it does, please leave your approve or oppose below.

Once voting is opened, use '{{vote|yes/no}} -- ~~~~' for voting.