[brands/man_made/surveillance] Add Flock Safety

[frillweeman]

Flock Safety is an American surveillance company that primarily makes ALPRs for use by their customers, mostly law enforcement agencies, but also private entities.

From the Tag:man_made=surveillance page on OSM Wiki:

operator=* – the organization operating the cameras. Note that the organization of interest would be the organization to whom the images belong (specific government, specific enterprise, etc.), for example: operator=Ajuntament de Palma or operator=My Enterprise.

Flock is not an operator as defined in the above excerpt, since Flock's customers are the organizations to whom the images belong. Flock's customers are the ones who instruct the device to alert on specific license plates, conduct searches of the data, etc. Flock just leases these devices to their customers and provides a cloud platform to access them, so they are a brand instead.

[1ec5]

The documentation seems to make an assumption that the entity operating the cameras is the same entity that owns and uses the images. I don’t know if this is always the case, but in a recent thread in OSMUS Slack, it was explained that Flock leases the cameras to the agencies, who push the buttons and use the images, so the assumption holds in this case at least. Moving Flock out of operator=* will allow mappers to more easily indicate the agency that the camera has been leased to, as in #10179. (After all, the lessee definitely isn’t the owner=*.)

One thing I’m unsure about is whether brand=* is really the right key for Flock. This key normally indicates branded chains, not anything that has an associated brand. For example, a highway=traffic_signals doesn’t get tagged with brand=Acme Traffic Signals (which might be a company that folded in the 1980s), and an emergency=siren doesn’t get brand=Federal Signal. I suspect a more appropriate key would be manufacturer=*, which is already used on thousands of man_made=surveillance features in OSM, including some Flock cameras. There are well-established manufacturer:wikidata=*, model=*, and model:wikidata=* keys to go with it.

We haven’t set up a manufacturer tree, and I don’t see any precedent for tagging it as part of NSI yet. @bhousel, should we set it up or just go with brand=* for now?

[frillweeman]

My mistake. I assumed brand was the right tag to use because of existing nodes tagged with the same brand. I can remove the insertion of Flock into brand but keep the removal of it from operators.

[bhousel]

We haven’t set up a manufacturer tree, and I don’t see any precedent for tagging it as part of NSI yet. @bhousel, should we set it up or just go with brand=* for now?

It would probably be ok as long as the tags are something like manufacturer / manufacturer:wikidata, and the stuff in this tree wouldn't appear in any other tree..

[1ec5]

My mistake. I assumed brand was the right tag to use because of existing nodes tagged with the same brand. I can remove the insertion of Flock into brand but keep the removal of it from operators.

No need to apologize – these issues come up all the time in OSM. NSI has the ability to shape tagging for a long time to come, so we just need to double-check that it’s what we’re comfortable with going forward, to avoid creating additional retagging work for everyone. I started a discussion on the forum just to gauge opinions, since apparently Flock cameras are the outlier compared to other camera vendors. There may be a good reason for that, but this is all pretty new to me.

It would probably be ok as long as the tags are something like manufacturer / manufacturer:wikidata, and the stuff in this tree wouldn't appear in any other tree..

There is manufacturer:wikidata=*, but almost any feature tagged with manufacturer:wikidata=* will also warrant an operator:wikidata=*. I suppose most law enforcement agencies would deploy Flock jurisdiction-wide – that’s kind of the point – but other street furniture might not be as straightforward. It’s pretty unfortunate that NSI clients can only tie a given feature to one NSI entry (since it affects the preset rather than an individual field).

[frillweeman]

Checking back in on this. It looks like a couple people commented on the forum post but didn't seem to address whether or not manufacturer was the right tag. How does everyone feel about creating a manufacturer tree? If not, I can remove the brand changes in this PR and just keep the operator changes, since brand doensn't seem like the right tag to use.

[1ec5]

the stuff in this tree wouldn't appear in any other tree

Based on this constraint, we would have to decide whether it’s more important to standardize the fact that a surveillance camera is manufactured by Flock or that it’s operated by such-and-such police department. This constraint exists because each entry gets converted into a preset that editors such as Rapid and iD offer right alongside the stock presets from id-tagging-schema.

If we break out a new tree for manufacturer=* and manufacturer:wikidata=* on feature types that tend to also be tagged with operator=* and operator:wikidata=*, then this might need to be a “mini tree” that would somehow only pertain to a particular field rather than the whole preset. In principle, this is doable – it’s how NSI originally functioned when it only affected the Name field. However, it would probably require nontrivial work to implement, so you’d have a longer path to seeing this work in action.

In the meantime, one possible outcome of the forum discussion could be a mass edit to move Flock Safety from brand=* to manufacturer=* to align with other surveillance cameras. (This would require some discussion beforehand, of course.) In id-tagging-presets, the Surveillance Camera preset already has a Manufacturer field that lists the most common values, but Flock is so rarely tagged as the manufacturer=* that it doesn’t show up yet. A new field for manufacturer:wikidata=* could also be added to the preset, similar to the paired species=* and species:wikidata=* fields for trees. That would make it easier for mappers to fully tag these cameras without having to look up the Wikidata item.

[Snowysauce]

I deactivated the Flock Safety preset based on this discussion by moving "Flock Safety" into the category file's named exclusions list. We could, in theory, put "Flock Safety" into the generic name list to create warnings that it isn't a valid operator value, but that probably requires a discussion of its own.

[iandees]

Checking in here. I think having a preset is pretty important as folks are trying to map these devices and getting confused when they don't see a preset for this manufacturer/operator, leading to inconsistent tagging.

To me, the case for these being operator is pretty strong. A local agency contracts with Flock, who installs and operates the devices. The local agency then views data from the devices within their territory (and without) through the Flock website. It is useful to capture which agency is paying Flock for the installation, but that is sometimes hard to know and isn't available "on the ground".

[bhousel]

Checking in here. I think having a preset is pretty important as folks are trying to map these devices and getting confused when they don't see a preset for this manufacturer/operator, leading to inconsistent tagging.

Would mappers looking for this preset search for "Ferndale Police" or would they search for "Flock"?
I read through the previous discussion and it's still not clear to me. If I am understanding it correctly, the former would mean a zillion new operator presets, the latter would be a new thing (but people seem to think it's more of a "manufacturer" than a "brand"?)

I guess I could add a "manufacturer" tree and.. test locally whether it breaks anything in my fork of Rapid?
Understand that pushing code changes to iD and Rapid at this point is not possible, as my access to both projects has been cut off. From my point of view both projects are stalled.