I’ve been mapping a lot of Flock ALPR cameras lately and I’m hitting a bit of a crossroads with how to tag the direction.
The wiki for surveillance:type=ALPR still leans toward using the basic direction=* tag, but for things like traffic signs, direction usually relates to the flow of traffic (forward/backward). With cameras, camera:direction feels a lot more intuitive since it’s describing where the lens is physically pointing, not necessarily the behavior of the road.
I noticed tools like DeFlock and StreetComplete seem to prefer the namespaced version, but I don’t want the data to break for older renderers either.
Are people generally moving toward camera:direction as the new standard? Should we be double-tagging both for now just to be safe for backward compatibility, or is that just making a mess of the data?
Not too long ago DeFlock only recognized directionand our wiki had conflicting advice depending on which page you looked. The couple of cameras I added at that time I used both forms for compatibility with whatever data consumers might be using the data. I contacted the person behind DeFlock as asked about the direction tagging and they changed to using the name spaced version. I suspect that they changed their app that people enter ALPR locations to use the name spaced form and that the ones with only direction are older but I would not swear to it.
One advantage of the name spaced version is that sometimes the cameras are mounted on existing posts or poles that have other features facing in other directions. Unless you want to have multiple nodes at the same location for each item, name spaced version of direction allow you to specify each. I am thinking of a case where a single street lamp post has both traffic signs and a ALPR camera on it.
I don’t see a need to double-tag both direction=* and camera:direction=*. The former is unambiguous as long as you’re mapping the man_made=surveillance as a standalone node, but the latter becomes necessary if you’re dual-tagging it with another kind of feature, such as a street lamp or traffic sign. We don’t really have a consensus on how else to map multiple accessories colocated on a single pole. ALPRs are usually mounted on the same pole as something else, so if an editor has to pick one key to support, camera:direction=* would err on the side of safety.
In id-tagging-schema (which powers iD and some other editors), the Surveillance preset has a Direction field that applies direction=*. If you set Surveillance Type to Camera (surveillance:type=camera), it becomes the Surveillance Camera preset, and that same Direction field applies camera:direction=* instead. But if you set it to Automatic License Plate Reader (surveillance:type=alpr), the Surveillance preset still sets direction=*. This seems logically inconsistent to me, since an ALPR is technically a kind of camera, if not the kind that surveillance:type=camera refers to.
Taginfo corroborates this. surveillance:type=camera has 37% tagged with camera:direction and 0.98% with direction. surveillance:type=ALPR has 89.5% tagged with direction and 5.8% with camera:direction. I’m sure that the high % for ALPRs is due to the DeFlock app primarily, which is also probably why direction is so high for them, as DeFlock is probably the majority source for ALPRs.
I agree that it should be consistent, but I don’t know whether I like camera:direction, as it doesn’t seem more descriptive than direction, and I can’t think of a situation where direction would mean anything different than camera:direction.
Thank you for the great information. I definitely understand the logic, and at the same time using tags like camera:mount and camera:type would make camera:direction a good choice, but the numbers say otherwise. From what I have seen, at least with Flock ALPR, they are typically mounted on independent poles, so direction does imply camera:direction. I’m probably just over thinking it.
I agree. I don’t necessarily see a difference, other than camera:type and camera:mount are already being used, and with that camera:direction seems to follow that namespacing more so than just direction. Specially when you look at all the ways direction is used for other types on nodes.