Can we allow categories to be in both 'operators' and 'brands' trees

This is affecting kind of a lot of things now, and I need to think if I can just make some minor adjustments - but not a whole rewrite - to make it work ok.

It seems to be working - I made sure to add skipCollection to the one in the brands tree and the ones in the brands tree won’t also get added to the operators one as a city, county, or NGO operates the individual libraries

I’m just thinking out loud about the things that might be an issue:

• Revert #5613 if it turns out I can pull this off with minimal effort.
• The NSI matcher code probably will have subtle issues, because its match index is built on k/v. This might mean the items and the exclude lists from one file may overwrite those things from other file. I expect that this code will just never match stuff in whatever file it parsed first. UPDATE: I wrote some tests, and it turns out this already working ok after all.
• Raise a warning (by matcher.buildMatchIndex?) if a same-named item exists in several trees. re #5625-comment
• In iD there is other code to try to “guess” what tree a k/v pair belongs to. (This code might guess wrong, but it might be ok anyway because brands and operators are similar - I dont know). The reason for this “tree guessing” is because iD is just looking at raw OSM tags and it needs to decide which tags are considered “namelike”.
  UPDATE: I checked the code here and I think it’s ok. Any items that appear in both trees will still be checked for name, operator, and brand keys.
• For example, the iD validator sees a shop=yes+name:en=USPS - Morristown+height=3.5+roof:colour=orange, it should be able to run the name:en tag through the matcher and guess that that is probably a US Post Office, even without actually seeing a defining tag like amenity=post_office, and also not matching the “Orange” mobile phone brand because of that roof:colour tag…

This probably just needs to be its own issue now, because the ‘brand’-‘operator’ split is causing a whole lot of grief for me lately, and I just moved the post offices in #5613 (mostly for Norway, UK, and things like UPS store) and I’m still not sure I did the right thing.

_Originally posted by @bhousel in https://github.com/osmlab/name-suggestion-index/issues/5623#issuecomment-956279182_

[bhousel]

Update on this - I did a bunch of investigation and I think we are ok to have categories in both trees, for example:

• brands/amenity/post_office.json
• operators/amenity/post_office.json

I’ve added tests to make sure that our matcher can handle this, and I’ve added a warning in case an item happens to appear in both trees.

The rules:

IF an item is in the brands tree:

• the brand tag is required and brand:wikidata is used as main identifying tag for fetching the logo.
• operator* tags are optional, as they are likely to be inconsistent / irrelevant across that brand. (This includes things like privately operated post offices, like found in Norway, the United Kingdom, and stuff like the UPS Store and Mailboxes Etc…)

IF an item is in the operators tree:

• the operator tag is required, and operator:wikidata is used as the main identifying tag for fetching the logo.
• brand* tags are optional, as they are likely to be redundant / irrelevant / unusual in these situations (We wouldn’t say that a public police force or school district is “branded”).

IF you’re going to create a category that exists in both brands and operators trees:

• one or both files should have "skipCollection": true property set (to avoid having both files filled up with the same collected names)

I hope this is helpful - if there are any outstanding issues related to the brand-operator confusion, I will try to close them in the next few days.

[bhousel]

• The NSI matcher code probably will have subtle issues, because its match index is built on k/v. This might mean the items and the exclude lists from one file may overwrite those things from other file. I expect that this code will just never match stuff in whatever file it parsed first.

I wrote some tests, and it turns out this already working ok after all.