Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle tag to disallow automatic brand tagging #6577

Open
bikeoid opened this issue Jun 25, 2019 · 15 comments

Comments

Projects
None yet
9 participants
@bikeoid
Copy link

commented Jun 25, 2019

I have seen several local restaurants with same or similar names to chains being incorrectly upgraded to the chain branding. I would like to mark these so they don't get re-tagged with branding later.

The tag not:brand:wikidata has been suggested for this.

@bhousel

This comment has been minimized.

Copy link
Member

commented Jun 25, 2019

The tag not:brand:wikidata has been suggested for this.

This sounds good to me, but can you link a discussion about it? Just saying "it's been suggested" doesn't mean much.

@BjornRasmussen

This comment has been minimized.

Copy link
Contributor

commented Jun 25, 2019

It's been discussed on the #poi channel of the osmus slack.

@bikeoid

This comment has been minimized.

@jnicho02

This comment has been minimized.

Copy link

commented Jun 25, 2019

We've used the 'not:' prefix elsewhere for 'not:addr:postcode' to flag a common mistake, and i'm sure there must be others. It is probably a fairly acceptable thing to do.

@quincylvania

This comment has been minimized.

Copy link
Collaborator

commented Jun 25, 2019

@bikeoid @jnicho02 I agree 100% that introducing this tag would be acceptable based on historical precedent. However, a few members of the OSM community are dead-set against iD introducing any tag without consulting them, resulting in trivial tag introductions having an outsized negative impact on the health of the iD project (see #6332). As such, a new tag like this needs to receive lots of real-world usage and/or go through the "approval" process before we can support it 🙁

@1ec5

This comment has been minimized.

Copy link
Collaborator

commented Jun 25, 2019

not:* is already a well-used tagging scheme, just not not:brand:wikidata specifically yet. For example, #6411 is about not:name. But no usage of not:brand:wikidata yet, so to kick things off, I tagged a couple independent restaurants that happen to match the name of chains in the same country:

https://www.openstreetmap.org/changeset/71606044
https://www.openstreetmap.org/changeset/71606149

If the validator warning about the missing brand tags could have an option to permanently ignore the warning (adding the not:brand:wikidata or not:brand tag), then we could potentially remove some disambiguating suffixes from name-suggestion-index that are there just to account for independent stores.

@1ec5

This comment has been minimized.

Copy link
Collaborator

commented Jun 25, 2019

@SK53

This comment has been minimized.

Copy link

commented Jun 30, 2019

not:name was originally AFAIK introduced for widespread usage as a way of avoiding false positives when using Ordnance Survey data road names around 2010. At the outset I think the OSM community established 1-2% of the british Ordnance Survey road names were not supported by on-the-ground evidence. Many of these differences were relatively trivial (presence or absence of apostrophes, words split of concatenated), but the utility of helping contributors avoid unnecessary work was invaluable.

In any case where some reputable external source is used to populate an OSM element or tags of an element, there is clearly some need to quickly signal to other contributors that the element as mapped is more accurate than the external source. A generic extension of not:key=* or even further not🔑 when there are multiple potential external linked sources has been in use, albeit it at a low level for a number of years in OSM.

Although @tec5's useful write-up describes "not:" as a life-cycle prefix, the usage is not really data about the object itself, but largely metadata about conflicts which may occur when OSM data is linked to external data sources. If we are to incorporate values which do allow linked data queries between OSM & other sources there will clearly be a need for some mechanism for flagging up that known discrepancies may exist. This is currently the mechanism, and it would need to be invented if it did not already exist.

Therefore although the iD team may feel it politically expedient to suggest an approval process the downside is that the small community who discuss and vote on proposals may choose to reject a tag and approach which has nearly 10 years of active usage.

Note: I'm not sure if not:brand:wikipedia=McDonalds is a good thing, as it may be encouraging sloppy practices in assuming that McDonalds is always a hamburger joint. This is unlikely to apply in Scotland.

@quincylvania

This comment has been minimized.

Copy link
Collaborator

commented Jul 1, 2019

Therefore although the iD team may feel it politically expedient to suggest an approval process the downside is that the small community who discuss and vote on proposals may choose to reject a tag and approach which has nearly 10 years of active usage.

Again, I'd personally love to just implement this tag in iD. However, I'm being extra cautious here because we came under heavy criticism from that small community when we introduced nonsquare=yes, using exactly the same approach as longstanding tags like noname=yes. So much criticism that we had to reverse that feature. No one wants that to happen again.

I'm not saying this tag needs to undergo an entire approval process necessarily, but some level of community buy-in would keep people from feeling that iD went behind their back by adding this.

@batyrmastyr

This comment has been minimized.

Copy link

commented Jul 9, 2019

heavy criticism

nonsquare had one huge drawback - it's a hint invented to fight against false-positives in iD, still it was stored in common database. Editor config is the data that should be stored externally.

an approval process the downside is that the small community

Not consulting with community may lead to garbaging database (useless changing "zebra" to "marked" instead of community approved "uncontrolled" with or without traffic_signals support), massive routing breakage (making everything a highway) to name a few. UPD: added links.

Back to the topic - not:source:identifier is fine (IMHO) as it gives some useful information for everyone.

@quincylvania

This comment has been minimized.

Copy link
Collaborator

commented Jul 9, 2019

@batyrmastyr Not to get too off topic, but nonsquare is not iD-specific, it specifies on-the-ground conditions and any other tool that examines squareness could use it. iD did not "garbage" the database, did not make everything a highway, and did not cause massive routing breakage.

@batyrmastyr

This comment has been minimized.

Copy link

commented Jul 9, 2019

@quincylvania sorry, I haven't seen other editors proposing to square corners. Seems like I've missed some.
I've added links to the issues I mentioned earlier. The latter is fixed, but the former is't ("thanks" to bhousel's strong NIH-syndrome).

@1ec5

This comment has been minimized.

Copy link
Collaborator

commented Jul 12, 2019

Let’s keep this discussion on-topic please. I suspect folks here are already aware of the crossing and squaring controversies, and people’s opinions on those matters are unlikely to be changed as a result of the discussion here.

So, about the brand suggestion feature: would it be enough to tag a feature with not:brand:wikidata, or would a feature need to be tagged with not:brand and not:brand:wikipedia too? Presumably the “ignore” button could conveniently add whatever tags are needed to turn off the suggestion, but given that brand, brand:wikipedia, and brand:wikidata are all redundant or complementary to each other, maybe the suggestion could be turned off when any of these tags is negated.

It may be helpful to tackle #6411 first, to understand if there are any problems with supporting the not: namespace overall. not:name has a longer history, as @SK53 explained in #6577 (comment). Making use of not:name could set a precedent for iD supporting other not:-namespaced tags in use and potentially other lifecycle tags as well. After all, the point of a namespace is extensibility.

@1ec5

This comment has been minimized.

Copy link
Collaborator

commented Jul 12, 2019

Note: I'm not sure if not:brand:wikipedia=McDonalds is a good thing, as it may be encouraging sloppy practices in assuming that McDonalds is always a hamburger joint. This is unlikely to apply in Scotland.

Even if it were unsound for a validator to assume brand affiliation based on naming alone, not: tags still have value as hints to mappers and data consumers who would be inclined to think otherwise.

Imagine using Overpass turbo to fetch the locations of Burger King locations around the world. But maybe you’re unaware of the one unaffiliated Burger King in Illinois, which predates the international chain and has the right to open additional locations under that name within a 20-mile radius. Without that context, you might be inclined to search for amenity=fast_food and name="Burger King" global rather than "brand:wikipedia"="en:Burger King" or "brand:wikidata"=Q177054, because occasionally someone adds a Burger King without brand tags. It would be nice to be able to add something like and "not:brand:wikidata"!=Q177054 whenever querying for chain store locations. That way you could at least exclude the locations that mappers have explicitly asked you to exclude.

@SilentSpike

This comment has been minimized.

Copy link
Collaborator

commented Jul 12, 2019

I imagine not:brand:wikidata would be the only appropriate and necessary tag since it's the only stable (in theory) identifier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.