See for example https://www.openstreetmap.org/way/165659335#map=19/39.48195/-88.37310 https://en.wikipedia.org/wiki/Burger_King_(Mattoon,_Illinois)
Burger King has the right to use this name throughout USA, with the exception of a 20-mile radius surrounding a restaurant, also called Burger King, in Mattoon.
_Originally posted by @matkoniecz in https://github.com/streetcomplete/StreetComplete/issues/2290#issuecomment-752023774_
We could do this, but wouldn't it be maybe more correct to just tag that one special Burger King with a
not:brand:wikidata=Q177054
Adding the not: prefix is an accepted way to make it clear to consumers and validators that the POI is special and not affiliated with the main brand. https://wiki.openstreetmap.org/wiki/Key:not:#Software_support
cc @1ec5 , I think he's tagged a few of these before and can let me know if I have it correct?
I see some ways how it can be handled:
(1) document that users of NSI are supposed to take care of not:brand:wikidata
(2) complicate system of how NSI applies tags and include info about this exclusion zone
(3) have list of false positives within NSI itself
(1) relying on not:brand:wikidata seems like viable one, though it may require implementation effort in iD, StreetComplete, Vespucci (?) and among other data consumers. But (2) and (3) would also require implementation effort, likely even worse.
From the Wikipedia page, the international chain aren't allowed to open a restaurant with the same name within 20km of their competitor, so shouldn't we have a geographic exclude to cover that area?
That would be (2) from my ideas, but it would be quite a lot effort for a very minor gain.
(2) is technically possible with an "exclude" of the Mattoon BK's lat/long. It's a little amusing that the resultant shape is "The whole earth except this 25km circle." Ah. I see Peter has beat me to the comment submission
Also, @bhousel has expressed a preference for the simplest include/exclude statements available, which is an argument in favor of (1).
My reading of @matkoniecz's comments in Street Complete are not "Hey this one thing is broken" but rather an example of a class of problem that has minimal recourse in SC. Personally, I think the benefit outweighs the detriment, but the point is that he's not as concerned about this specific Burger King as he is about edge cases that may have more instances.
My reading of @matkoniecz's comments in Street Complete are not "Hey this one thing is broken" but rather an example of a class of problem that has minimal recourse in SC.
Yes, I just wanted to point out the worst possible obscure case. And StreetComplete is special here as it will apply NSI silently, without exposing anything to user (so potential misapplying will not be noticed).
The geographic area associated with an NSI entry isnāt meant to be a strict statement of where a chain is and isnāt. Trademark laws being what they are, there are same-named chains that overlap geographically (āPeopleās Bankā), but we only need to add so much detail to the geometries in NSI.
The Mattoon-based Burger King is already tagged with not:brand:wikidata, and iD recognizes that tag to avoid suggesting an āupgradeā to the Florida-based chain; any consumer of NSI should do the same.
The Hootses have the _right_ to open another unaffiliated location within that 20-mile-radius area, but they havenāt in the more than half a century since _Burger King of Florida, Inc. v. Hoots_ was decided. If they do, Iām sure the OSM community will find out about it in due time.
(2) is technically possible with an
"exclude"of the Mattoon BK's lat/long. It's a little amusing that the resultant shape is "The whole earth except this 25km circle."
There's an xkcd for that:
https://xkcd.com/2403/
Yes, I just wanted to point out the worst possible obscure case. And StreetComplete is special here as it will apply NSI silently, without exposing anything to user (so potential misapplying will not be noticed).
I'm not convinced every iD user checks every change every single time, so I don't think SC is entirely unique in that respect (although logos may mean they're not mis-tagging the wrong People's Bank for example.
The geographic area associated with an NSI entry isnāt meant to be a strict statement of where a chain is and isnāt. Trademark laws being what they are, there are same-named chains that overlap geographically (āPeopleās Bankā), but we only need to add so much detail to the geometries in NSI.
Given it's pretty trivial to do, is it not worth stopping tagging of BK within Mattoon though, more to trap errors with new BK stores than Hoots based ones?
I'm sure SC is displaying the logo, and the local community is surely aware of the BK situation on the ground, so I don't expect there to be confusion. I see the exclude rule to primarily be aimed at not clogging up the UI with irrelevant suggestions, not as something authoritative. (In Go Map!! I'm not even looking at excludes, only includes).
I'm sure SC is displaying the logo
It is not. See https://github.com/streetcomplete/StreetComplete/issues/2290#issuecomment-737576970 https://github.com/streetcomplete/StreetComplete/issues/2290#issuecomment-738105616
Ok, well since this issue isn't going away, and we can just do this easily without breaking anything, I changed Burger King's locationSet to:
"locationSet": {
"include": ["001"],
"exclude": [[-88.3726, 39.4818]]
},
Location-conflation will create a circle for us that is 25km, not 32km, but maybe I'll add a future enhancement there to let people control the radius of the circle.
At least I have an amusing geo story to tell people, and it's pretty great that the locationSets give us so much flexibility.
The Burger Kingdom:

_Enhance..._

_ENHANCE!_

Well, this is embarrassing.
After some more research I have learned that they aren't in Australia either - there they use the name Hungry Jacks, which we have in the index already.
I updated the locationSet appropriately. Sorry Aussies!

Thanks @bhousel . Sorry I wasn't intending to just throw it over the fence, I was going to try and take a look at them soon.
Sort of linked to Hungry Jack's what's the deal with the alternative script ones, should we be excluding the English one from these countries too?:
https://nsi.guide/index.html?t=brands&k=amenity&v=fast_food&tt=burger king
I see the exclude rule to primarily be aimed at not clogging up the UI with irrelevant suggestions, not as something authoritative.
Personally I'd feel the opposite (within reason, e.g. a 25km circle not 32km), if NSI is trying to be an authoritative source of brands etc, then it should try and be as authoritative as it can about where they're available. Otherwise you could just list everything as being relevant everywhere.
Sort of linked to Hungry Jack's what's the deal with the alternative script ones, should we be excluding the English one from these countries too?:
We don't need exclude the regional brands.. The matcher code will still match "Burger King" in places like Japan, but will return a local result "ćć¼ć¬ć¼ćć³ć°" (burgerking-3e7699) before the worldwide one (burgerking-d8d21b).
I wrote a whole bunch of test code last week to make sure that the matcher was performing well and returning results this way, check it out: https://github.com/osmlab/name-suggestion-index/blob/main/tests/matcher.test.js#L133
This was really the last big thing I wanted to finish before an official v5 release - it's important to get this right for iD's validator.
Most helpful comment
Ok, well since this issue isn't going away, and we can just do this easily without breaking anything, I changed Burger King's locationSet to:
Location-conflation will create a circle for us that is 25km, not 32km, but maybe I'll add a future enhancement there to let people control the radius of the circle.
View it!
At least I have an amusing geo story to tell people, and it's pretty great that the locationSets give us so much flexibility.
The Burger Kingdom:



_Enhance..._
_ENHANCE!_