Proposal:Extended tags for Key:Surveillance
Extended tags for Key:Surveillance | |
---|---|
Proposal status: | Draft (under way) |
Proposed by: | Ewald |
Tagging: | surveillance:*=* |
Applies to: | , |
Definition: | proposal to allow extended and more accurate tagging of surveillance measures in public spaces |
Statistics: |
|
Rendered as: | preferably not on the main map, but on a separate overlay |
Draft started: | 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 | Generic main tag for tagging surveillance measures | |||
surveillance | indoor/outdoor | 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 | 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?) | 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 | 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 | 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 | 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.
|
|||
camera:mount | wall/pole | 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 | 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 | 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 | 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-180 | 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 | 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 |
Sensor
(View the Talk page section on this issue)
Key | Value | Element | Comment | Rendering | Photo |
---|---|---|---|---|---|
sensor:type | motion/wifi?/rfid?/other | 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 | 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 | See camera:make and camera:model. | |||
sensor:direction | 0-360 | See camera:direction. | |||
sensor:angle | 0-180 | See camera:angle. | |||
height | 0-? m or 0-? ft | 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)
Guard dog
Not that interesting either, again, for the sake of completeness. (View the Talk page section on this issue)
Current tagging
Currently there are some stats on man_made=surveillance.
surveillance
surveillance:type
camera:type
guard:type
guarddog:type
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
- [1] renders camera:type and camera:direction nicely
- On the Wikimedia Toolservers
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.