Proposal talk:Extended tags for Key:Surveillance

Please use the talk page below for discussing this proposal. I have added a few headers already to aid in structuring the discussion, but you are of course free to make up your own.

Surveillance=indoor or indoor=yes ?

I am not quite sure on the use of surveillance=indoor/outdoor or resorting to indoor=yes and outdoor=yes. If opting for indoor=yes and dropping surveillance=indoor, we could use surveillance= for the current surveillance:type=. Any ideas/suggestions? — Ewald ^{(talk|email|contrib)} 10:17, 27 August 2010 (BST)

Using indoor=* would be imprecise when e.g. tagging indoor surveillance of a shop with shop=*, man_made=surveillance. What would the indoor=yes refer to then? The shop itself or its surveillance? So i'd opt for staying with surveillance=indoor/outdoor --Bielebog (talk) 14:36, 14 February 2013 (UTC)

I also would prefer not to use surveillance=indoor/outdoor but would propose surveillance:indoor/outdoor=yes. But thats the question. Where should this be tagged? Do you add it to a building? Then it must be indoor and we wouldn't need the additional tag. Or could it even be outdoor when the cameras are fixed to the wall and filming the area outside. But then should the area be tagged that is captured by the camera, or the position of the camera? Hakuch (talk) 15:10, 9 October 2014 (UTC)

Separate make and model tags or combined?

Should we use separate tags for the make and model of a camera or sensor, and/or is there a term which would be more convenient/precise? Would separating make and model be more accurate for post-processing/overlay info? — Ewald ^{(talk|email|contrib)} 10:17, 27 August 2010 (BST)

Hm, I don't think the exact model is relevant to many people. Furthermore it's usually not easy to determine what exact model a surveillance camera/sensor is. What's more important is the general type of camera, as addressed in the camera:type tag. --DaniloB 12:23, 29 July 2011 (BST)

As stated in the proposal, somebody might be able to figure out the make and model, so I don't see any reason to drop this tag. And separating make and model in different tags makes it easier to work with it, e.g. to infer not explicitly tagged camera:features by using knowledge on the camera model using some kind of camera feature matrix. --Bielebog (talk) 14:42, 14 February 2013 (UTC)

camera:type=fixed or static?

Is camera:type=fixed a logical tag for tagging a non-moving camera? Or should a different term be used? As 'fixed' could also refer to the camera being fixed as in attached to a wall or pole, the term 'static' might be more descriptive. Or is there another term we may want to use for this? -- Ewald ^{(talk|email|contrib)} 11:33, 21 September 2010 (BST)

I'd vote for static. --DaniloB 12:24, 29 July 2011 (BST)

I'd vote for fixed, MassDOT has a feed where the cameras can point one of two directions, so there are static reference images so you can tell which way its pointing. --Calvin.metcalf 13:48, 17 August 2011 (BST)

Tagging camera:type=static might be better because there are cameras mounted in (fixed) domes with the cameras inside being static. As opposed to dome cams that are able to move. --Bielebog (talk) 14:47, 14 February 2013 (UTC)

camera:features, tag name and suggestions for values

Is camera:features a logical tag for tagging camera features? Or should a different term be used? Also, please leave corrections/suggestions on possible camera features below. -- Ewald ^{(talk|email|contrib)} 14:52, 9 September 2010 (BST)

I think the tag is good. Some of the feature values would be implied though. E.g. a static camera won't have a motion feature and a dome camera will always have the motion feature. --DaniloB 12:27, 29 July 2011 (BST)

Sounds reasonable for me, too. I am not a native english speaker though. Another usable term might be 'capabilities' --Bielebog (talk) 14:59, 14 February 2013 (UTC)

camera:mount, tag name and suggestions for values

Is camera:mount a logical tag for describing the way a camera is mounted (on a wall or pole)? Or should a different term be used? Also, please leave corrections/suggestions on possible mounting methods and values for them below. -- Ewald ^{(talk|email|contrib)} 16:17, 9 September 2010 (BST)

Mount is understandable, but feels somewhat awry. I am about to tag a set of traffix-supervising cameras mounted on a "portal" above the road. What are those portals (usually a simple truss structure) called on Britain, usually used to hold road signs above the road?/Johan Jönsson 16:08, 2 August 2012 (BST) (edit:Probably called gantry)

I've seen cameras mounted on roofs, with small poles, like for aerial antennas. mount=roof seems more adequate than mount=pole here. --Bielebog (talk) 15:02, 14 February 2013 (UTC)

Sometimes cameras are also hanging from the ceiling. How to map these ones? --Chinus (talk) 13:48, 14 November 2013 (UTC)

How do I tag cameras mounted next to the traffic lights on the same pole? --Sk!d (talk) 01:22, 2 March 2015 (UTC)

  I would tag it as mount=traffic_signal. User:Adamthewebman (talk) 06:30, 13 October 2018 (UTC)

guidepost=* is using the location=* key. I'm not sure if this is better or not. --Pbb (talk) 17:38, 1 October 2017 (UTC)

Field of view, height/direction/angle - tagging camera and sensor alignment and mobility... how?

My current proposal has suggestions for both camera's and sensors on how to document the alignment and mobility of camera's and sensors. However, I feel the current tags and values are not quite convenient. Height might be relatively easy to estimate, but angle and direction are quite a bit trickier. In addition: how to define this for panning and dome camera's? Dome camera's may be tagged with direction (on compass) of 360 instead of zero to note that it is not a particular direction of view, but a 360 view which the camera has. This still leaves the panning camera with a lack of data on it's reach (if that is even detectable for mappers on street level)... Any suggestions? -- Ewald ^{(talk|email|contrib)} 14:52, 9 September 2010 (BST)

Maybe the direction and angle fields could be combined into a single field. E.g. "camera:direction=220-240" to show the range of possible directions. But then you would still need to distinguish between camera angle and field of view... The latter one is very hard to determine for a normal mapper. --DaniloB 12:31, 29 July 2011 (BST)

Text of camera:angle confuses me. I would say camera:angle is (horizontal) angle of view of the camera. camera:inclination would be better for detailing the mounting of the camera. --Hjelmeland 2013-12-01

It should be specified more clearly what camera:angle means: the inclination of the camera's view, in other words "how much" the camera is "looking down", in degrees, from camera:angle=0 for a horizontal view, camera:angle=15 (default) for slightly looking down, to camera:angle=90 to a vertical view (e.g. a dome camera?). --Hatzfeld (talk) 09:01, 14 August 2016 (UTC)

+1 for "camera:direction=220-240" for range, just angel=* for the vertical angel could be misunderstood, but if well documented ok in my opinion --Hakuch (talk) 00:31, 12 January 2017 (UTC)

I also support the idea of direction ranges. Over here, there are lots of dome cameras which are limited to 180 or even 90 degree range, which is easily visible. There should also be a range for the angle. And inclination would be a better description than angle.--Pbb (talk) 20:07, 3 October 2017 (UTC)

Multiple cameras at one location - how?

Please provide an example for tagging of three cameras on one pole; each camera facing different direction and each has website image. Fbax (talk) 14:33, 25 January 2017 (UTC)

The term 'sensor'?

I am not sure on the term 'sensor': is this really the best description/term to describe anything from devices that count people or traffic passing by, to motion sensors, to rfid/wifi sniffers to bodyscanners? — Ewald ^{(talk|email|contrib)} 10:17, 27 August 2010 (BST)

Tagging traffic surveillance, license plate tracking and related surveillance

While the mapping of speedcameras has already been established, I can imagine the tagging of general traffic surveillance and/or license plate tracking devices to be within the scope of this proposal. However, I am not quite sure yet as to the preferred way of tracking. Maybe it would just fit in the already present tagging options this proposal contains. Any ideas or suggestions? -- Ewald ^{(talk|email|contrib)} 11:45, 21 September 2010 (BST)

Guard and guarddog and the tagging of non-camera surveillance

I am pretty sure people will want to comment on the tags for guard and guarddog. As I tried to explain in the proposal, I have included these in order to expand the tagging of surveillance measures beyond the realm of merely cctv. I do however see how this moves on the border of tagging regular security features which aren't necessarily surveillance. Please leave your thoughts below. -- Ewald ^{(talk|email|contrib)} 14:52, 9 September 2010 (BST)

A guard house, security gate, observation tower, patrolling route, or dog kennel is a relatively permanent part of the geography and perhaps could be mapped. People, vehicles, and livestock don’t really belong on maps. —Michael Z. 2013-11-14 22:09 z

Mapping surveillance and legality

Someone told me there might be legal issues with mapping surveillance measures in certain countries or under certain jurisdictions... anyone? -- Ewald ^{(talk|email|contrib)} 15:02, 9 September 2010 (BST)

more than one camera mouted on a pole

quite often there are a couple of cameras mounted to a pole which all face different directions. how should that be mapped?

- Use different nodes at the same location I'd suggest, perhaps different heights? An option could be to also makes the nodes part of the same polyline. Webmind 20:23, 17 February 2012 (UTC)

How to map these cameras?

Sometimes they are horizontal aranged on one pole, sometimes about each other. Here is a nice example. How to map this one? :) Working with relations? --Chinus (talk) 12:58, 14 November 2013 (UTC)

Or perhaps working with camera1, camera2 and so on? --Chinus (talk) 13:44, 14 November 2013 (UTC)

I suggest make each camera as a relation, the only member is the location node. The location node could be a man_made=mast. The relation could be tagged as type=surveillance or type=camera.--hjelmis 2013-12-01

contact:webcam for url to publicly viewable camera footage (was: camera:url)

Some cameras will have a public-facing image stream. camera:url or just url could hold the URL to that stream (or static image). -- Martijn van Exel 11:24, 26 March 2011 (UTC)

"camera:url" sounds great. --DaniloB 12:34, 29 July 2011 (BST)

Why not use "website="? Fbax (talk) 19:29, 29 December 2016 (UTC)

@Fbax @DaniloB @Mvexel: The original proposal mentioned contact:webcam=* which sounds even better. It is very easy to search on the map this way. It is also already widely used. I started using it and it feels very comfortable. The iD editor was also recently patched to support it via the surveillance preset. Although, today the recommended solution is to create a new node for each camera, what if it was sometimes tagged on the building way and that had both a URL for a website and a different one for a webcam stream? (Just a random idea) A webcam could also plausibly be operated by a network or a company nearby and we could get more information or contact the owner for privacy or enforcement reasons via contact:phone=* and contact:website=*, while contact:webcam=* is strictly reserved for the camera stream. Sometimes we do have the website of the operator, but we don't have access to the public stream at all, in which case again contact:website=* needs to be used. Anyway I'm fine with camera:url=* or anything else as well because it can easily be changed back and forth via search & replace, however moving to website would be a one way trick. Bkil (talk) 22:13, 29 December 2016 (UTC)

I agre camera:url=* is best for the stream or static images. The tag contact:webcam=* implies a video stream however many camers do not stream but instesd have regularly refreshed still images. contact:website=* is best used for the web site address of the camera operator/owner/manager etc. Adamthewebman (talk) 11:47, 13 October 2018 (UTC)

Status?

What is the status of this proposal? Are there any open issues? When will the voting be opened? --Chinus (talk) 12:11, 7 November 2013 (UTC)

There's not much traffic on the talk page. I'd love to see a progress in this proposal's status, too. --Bielebog (talk) 16:07, 8 November 2013 (UTC)

guards and guard dogs

For me, guards and guard dogs are the total opposite of surveillance. So this perhaps should be covered by another tag!? A guard protects something, a surveillance item does not. Perhaps it prevents something from being attacked by deterrence, but not by active measures as a guard or guard dog could do. I suggest to make an extra tag for this. --Chinus (talk) 13:42, 14 November 2013 (UTC)

People and dogs aren’t relatively permanent geographical features. It’s getting a bit like mapping cattle or wildlife. —Michael Z. 2013-11-14 22:04 z

Addendum

I have read the proposal and I see the importance of a good tagging scheme to come alive.

1. But if this tagging scheme should be used a lot it has 1. be easy to use and 2. complete. There has to be a tagging scheme which is easy to use for a lot of people. They just want to map a surveillance camera. They have no idea how OSM really works, how tags can be combined or ever read the proposal. For these people there has to be a self-describing tag. I don't know if man_made=surveillance is the right one, because there is no "camera" in it.
2. And I have a problem that man_made=surveillance is not only for cameras, but also for other things (e.g. sensors). For easy and anyhow correct use perhaps there should be a alternative tag like surveillance=camera or something else but also self-describing!? What do you think?
3. I think guard and guarddog should be ignored here. This is no surveillance as I understand it. Guards and guarddogs can be tagged another way.
4. As I see it is open how multiple cameras on one pole can be mapped. Any solutions? I would suggest, see above, camera1, camera2 and so on. This could be combined with pole:height=*, camera1:height:=*, camera1:direction=*...
5. I even don't know if "surveillance" is the right thing. Cameras in the public can be used for surveillance, but is a camera that shows nature and the weather "surveillance"?
6. Is there a possibility to embed a image that shows the area that is covered from the camera eye (best a image made by the camera itself) in addition to a webcam url with its live stream?
7. Is there a possibility to map shops (or other facilities) that are surveillanced? Maybe shop=shoes, name=Shoe Bob, surveillance=yes?
8. 

   Warning sign
   In some countries (e.g. Germany) it is, at least sometimes, dictated by law, to advice people, that they enter a surveillanced area. Normally this happens by a sign. Is there a chance to map such signs too, perhaps also directly at the camera that shows that you will be warned if you get into the area that is covered by that camera?
9. What does location=* mean in the context with a camera? The location of the camera or the area that is covered by the camera? I would suggest to map the location of the camera with location=indoor/outdoor (or perhaps with camera:location=*?), because the camera can eventually cover both, outdoor and indoor areas.

This are my thoughts and questions to that proposal that, in my opinion, are not solved properly. But I hope this could be solved soon, so this proposal can be approved. --Chinus (talk) 14:34, 14 November 2013 (UTC)

Dummies

What about camera dummies? Often real cameras will not be differentiated from camera dummies, but if so, how could camera dummies be tagged? --Chinus (talk) 14:50, 14 November 2013 (UTC)

What do you mean “if so?” Is it wise to map this at all? We can safely assume:

• This info cannot be reliably determined or confirmed
• It is considered confidential or secret by the camera owners
• It is confidential for reasons of security, safety, property protection, etc.
• Concerned parties have it in their interest to falsify the mapping of this info

It would be unwise to trust this information if it were mapped, and doing so could lead to legal, liability, and moral issues. —Michael Z. 2013-11-14 21:54 z

If a camera could be identified safely as a dummy, then it should be tagged as dummy. I know, this is probably more a theoretical consideration because today camera dummies can not be identified as such. But maybe, if you can take a look close enough at the camera and you know how dummies differ from real cameras, they could be tagged as a dummy. But yes, it is very theoretical and, in regard of the fact that they can hardly be distinguished, I see no need for a tagging scheme of camera dummies anymore. --Chinus (talk) 12:02, 15 November 2013 (UTC)

What is being monitored???

There is no mention of what is being monitored. Some examples - people, traffic, weather, fires, surf. Possible tag surveillance:monitoring=people/traffic/weather/fires/surf/* Used it indicate the primary intended surveillance target. Warin61 (talk) 06:06, 25 March 2018 (UTC)

Access to video feeds

Some cameras are accessible via the public internet and a link to the video feed would be useful. Perhaps the contact:website tag could be used but the semantics are somewhat other --Mr Shark (talk) 08:56, 23 August 2019 (UTC)

contact:webcam is proposed in this proposal (under camera:features), and it's already in use on almost 1500 nodes. —M!dgard [ talk ] 10:40, 23 August 2019 (UTC)

Strange tag ;)

Currently 3 main keys are in use (see my comments).

9 years after, the vote for this proposal didn't start. So contact:webcam=* status is "proposal" or "de facto". It is no more legitimate than website=* isn't it ?

Anyway, the community shoud standardize better a "webcam".

--Pyrog (talk) 16:30, 10 January 2022 (UTC)

Camera : key names 'type' 'features' have same values.

The suggested keys camera:type=* and camera:features=* share some of the same values and are not clear as to what is to be tagged. Better to have a clear key so that unexpected values don't cloud the original thing to be tagged. Examples of better keys? camera:housing=none/dome/*, camera:pan=no/yes/remote/automatic/tracking camera:tilt=no/yes/remote/automatic/tracking camera:audio=yes/no camera:night_vision=no/yes/lit/infared. Note the camera:direction and camera:angle are confusing, it maybe better to use camera:pan:limit and camera:tilt:limit instead? Warin61 (talk) 01:34, 18 August 2020 (UTC)