Store names which include the branch name

[NKAmapper]

Store names in Norway includes the branch name, for example "Spar Arendal Sentrum", not just "Spar", as discussed by the local community. This is also the case for other categories such as fuel stations, hotels, restaurants etc .

How could this be specified in the index?

Currently, iD is encouraging users to strip the name tag for everything but the brand name, causing a lot of unwanted edits.

[arch0345]

By adding "preserveTags": ["^name"], to the entry, iD will keep the name of the locations and not suggest splitting into name=* and branch=*. The name=* will only be used when a new POI is added. Here is an example of this:

    {
      "displayName": "Verizon",
      "id": "verizon-ce3e5c",
      "locationSet": {"include": ["us"]},
      "preserveTags": ["^name"],
      "tags": {
        "alt_name": "Verizon Wireless",
        "brand": "Verizon",
        "brand:wikidata": "Q919641",
        "brand:wikipedia": "en:Verizon (mobile network)",
        "name": "Verizon",
        "shop": "mobile_phone"
      }
    },

All of the entries can be easily viewed under the data folder on the main page. Let me know if you need any help with this.

[NKAmapper]

Thanks. I browsed the index. The brands in question are all the entries with a NO country code: https://nsi.guide/?t=brands&cc=NO

I think help is needed to add all the preserveTags...

[Adamant36]

Store names in Norway includes the branch name, for example "Spar Arendal Sentrum", not just "Spar", as discussed by the local community. This is also the case for other categories such as fuel stations, hotels, restaurants etc .

Am I correct that the signs in front of the stores usually say "Spar" and not "Spar + whatever location name"?

(Like in the mailing list discussion you linked to the person mentions KIWI Nøstet. But the sign outside of KIWI Nøstet just says "KIWI", not "KIWI Nøstet")

[NKAmapper]

Am I correct that the signs in front of the stores usually say "Spar" and not "Spar + whatever location name"?

The big illuminated sign on the roof is usually just the brand name of course, but the full name is often used on a smaller sign on the door with opening hours, on marketing flyers, on the website (https://kiwi.no/Finn-butikk/Kiwi-Nostet/), on Facebook (https://www.facebook.com/SparArendalSentrum) etc.

But the point is that the local community want to have the full name in the name tag.

I see now that there are many brands which do not have the NO country tag in the index, for example Shell, Shell Express, Esso, Esso Express, 7-Eleven, Spar, Eurospar and many others. Perhaps it would be easier to just exclude Norway altogether.

[fredrik-lindseth]

I hope this can be resolved before some trigger happy ID user "fixes" everything 🙏

[bhousel]

Hey @NKAmapper & @fredrik-lindseth - when I built this feature I was following the guidance on the OSM wiki here:
https://wiki.openstreetmap.org/wiki/Key:branch

Using the branch tag in this way gives data consumers more flexibility in how they work with POI data. It seems reasonable, and I did put thought into it.

That page doesn't mention anything like "do this everywhere except in Norway" so it didn't occur to me to write any special code for Norway. If you really insist, I can add this code to the iD validator to make Norway an exception.

But the point is that the local community want to have the full name in the name tag.

The discussion you linked to was from 2012, so it predates a lot of stuff that has evolved in tagging since then. I'd encourage you to discuss with your community whether using the more modern branch tag makes sense in Norway, and then report back here with whatever you decide today.

Also, if you are having a discussion about this now, it would be great to link to it so we can follow along. It sure is suspicious when people who aren't regular contributors show up on a repo upvoting or downvoting stuff and making snide comments about "trigger happy iD users". Please give us a chance to actually work with you rather than just jumping to the conclusion that we're wrong.

[JohanEntur]

We are not regulars, but NKA is really speaking for the rest of us (Norway) here. Individual shop names is a thing, and NKA has put a lot of work into building several import structures (incl. shops) to both populate and keep these POIs up to date in Norway. It would be unfortunate if the presets and users of iD would unwittingly degrade these items.

I can tell you right now, the same issue will be relevant for Sweden:
The suggestion iD gives here is not sound.

[riiga]

I'll chime in on Sweden: The situation is essentially the same. Especially supermarkets and the like tend to have individual names which should be part of the main name tag, not in any branch tag. There are however lots of other shops that have their location in the name when they shouldn't (imho) and where it might make sense to keep this functionality.

[NKAmapper]

I think the index is a great idea, I just did not realize that it would enforce one way of using the name=* tag. I just discovered that a large number of store names had been edited in Norway and tried to understand how that happened.

I guess both methods (name=* with and without the branch name) are being used in other countries as well, but I have not checked. A problem with the branch tag is that search is in general not supported, at least not in Nominatim and in all the apps I have tried. A search will then usually just produce a list of identical brand names within the same city, which is not very helpful.

The practice of name=brand+branch has in fact been used since 2012, and is being actively maintained that way. We have put a lot of effort into getting a complete and well structured set of the most common retail chains in the country into OSM. It has been discussed several times on IRC/#osm-no, including today.

[Adamant36]

A problem with the branch tag is that search is in general not supported, at least not in Nominatim and in all the apps I have tried.

I think official_name and ref are both supported in the major apps. Including Nominatim. There's also the local_name tag. All of those are potential options. In the meantime, It's not really on the OSM community at large (or the NSI) to custom tailor mapping or presets for what a particular piece of software does or doesn't support a tag. Otherwise, we are just tagging for the rendering or in this case the search. You could ask Nominatim or other apps to add support for whatever tag you think they should support though.

In the meantime there's the "on the ground rule" and I'm pretty sure not every single store out of the however many chains have been mentioned would have the "local" name on the door. Whereas all of them are going to have a sign outside that just says the name and that's usually what we go off for the name. IMO the local "name" is usually more of reference used by the store managers then anything shoppers use or care about.

For instance in America Walmarts, Safeways, and many other chains have store specific IDs, but no one uses them. So it would be weird to include them in the name field. Unless you can give a real world use for it. Also, if your requiring people to read a tiny little print sign on a door that most people aren't going to know about to figure out how to tag something instead of the large, obvious sign out front then your doing this wrong and just gate keeping.

Especially if your reason for why the NSI should be adopting something is because "NKA has put a lot of work into building several import structures." Cool NKA has done that, but that's not on us or the rest of the community to follow it just because you say so. Maybe NKA should have done more research before building those structures. I can't tag every store in the United States with the letter A for the name and then be like "well, it should be done that way because I built the structures and say so. So screw ID Fiddlers" or whatever.

[mathiash98]

I'll add another voice in this

I am a loving ID user from Norway (active in the Norwegian community) which has also imported several shops and restaurants in Norway.

Also contributed in this index with #5240 #5241 #5238 #5237

In my PRs I purposely excluded the name field since I don't want iD to suggest removing "Lagunen" from "Egon Lagunen".

The name of the restaurant is "Egon Lagunen" in all places (search engines, restaurant rating services, untappd, Egon's official website etc). So setting name to only the name of the brand would be wrong, it's better to use the "brand=xxx" and "brand:Wikipedia=xxx" for this (in my opinion).

• Using local_name or official_name for the combined name "Egon Lagunen" might make sense to do as well

I see this could fit into a much broader "name vs branch vs brand" discussion which probably should be done elsewhere, but adding the "preserve Tags" : ["^name"], prop is a good solution for the brands we are concerned about (at least in the Nordic countries).

[JohanEntur]

In the meantime there's the "on the ground rule" and I'm pretty sure not every single store out of the however many chains have been mentioned would have the "local" name on the door.

No, but not everything in OSM can be seen on the ground. It doesn't mean it isn't the correct information. Many roads have names, but only the ref has a sign, many houses have a house number without having an actual number on the wall.

Cool NKA has done that, but that's not on us or the rest of the community to follow it just because you say so

Yes, NKA has put a lot of work into building a uniform dataset for all shops in Norway and I don't see why the "iD fiddlers" should have some special right to override these, because they are not mapping whats on the ground either, they'll be mapping what iD tells them to because there is a warning.

[mathiash98]

Further reading for those interested in previous global discussion on these topics:

As I see it, there is no global consensus on what is correct or not, as seen in this discussion today other than to always include branch=* and brand=* and then let the community decide what to place in the name field.

• This allows renderers to use brand+ branch if they would like and use the official name if they would rather use that.
  • And it makes it easy to search for all "McDonald's" in my area based on brand
• Forcing all POIs to have name==brand makes it redundant to have either name or brand on POI and is not good in many cases.

https://wiki.openstreetmap.org/wiki/Talk:Key:branch
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:branch
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Key:branch
https://wiki.openstreetmap.org/wiki/Key:name

• BTW: The voting on key:branch never finished and was moved back to proposed, so it is not an official method, but it is used a lot of placed (in Norway too where we set name=Egon Lagunen, brand=Egon and branch=Lagunen)

https://wiki.openstreetmap.org/wiki/Key:brand

• Has the best known global examples for how to do naming

Depending on a particular brand's branding practices, name=* may consist of brand=* and branch=* in some order.

[Adamant36]

No, but not everything in OSM can be seen on the ground. It doesn't mean it isn't the correct information. Many roads have names, but only the ref has a sign, many houses have a house number without having an actual number on the wall.

Sure, but that's a false equivalency because in this case the information is actually on the ground. So they aren't comparable. Otherwise, that would be like saying "you can't tag this as a house even though you can see it's a house because the boundary of the city where the house is located can't be confirmed to exist in the real world." Seriously, who cares? They have nothing to do with each other.

Yes, NKA has put a lot of work into building a uniform dataset for all shops in Norway and I don't see why the "iD fiddlers" should have some special right to override these, because they are not mapping whats on the ground either, they'll be mapping what iD tells them to because there is a warning.

How do you know whoever is using ID Editor to "fiddle with the tags" didn't visit the location of the store before they used the preset? conversely, I highly doubt NKA has visited every single store in Norway to check that how they are tagging things is correct. So why should NKA have special right sitting at his home computer to make a judgement over anyone else that's doing the same thing if they haven't ground verified the name of the store?

The name of the restaurant is "Egon Lagunen" in all places (search engines, restaurant rating services, untappd, Egon's official website etc).

Generally I probably wouldn't have a problem with a brand that's only located in Norway excluding the name field if that's what the local community decides. Although, it would have to be a better reason then the mediocre ones I've heard so far. Especially if the people fronting those reasons are unwilling to consider alternatives.

That said, brands like Shell, Shell Express, 7-Eleven (and I'm sure others) are global brands. As such the wider global OSM communities preferences should be considered. Since it would be weird and detrimental to the quality of the map if we fragmented how global brands are tagged into silos based on the country, state, town, neighborhood Etc. Etc. that they are located in. Say Germany's prefer "Seven-Eleven", Norwegians prefer "Seven-11 Arendal Sentrum" or whatever, and American's prefer "7-Eleven." Maybe we could technically accommodate that in the Index, but I don't think it would be a good idea to because it essentially makes finding a 7-Eleven almost impossible (or at least much harder) for anyone that's not a local. Whereas if you use something like the local_name tag for "Seven-11 Arendal Sentrum" and keep the name tag 7-Eleven the local community gets what it wants without screwing over everyone else in the process.

[mathiash98]

(...) Whereas if you use something like the local_name tag for "Seven-11 Arendal Sentrum" and keep the name tag 7-Eleven the local community gets what it wants without screwing over everyone else in the process.

• This is exactly what we have the key: brand=* for https://wiki.openstreetmap.org/wiki/Key:brand

But yes I agree that we should name these as the global OSM Communities prefer. Currently we sadly don't have any global naming standard for amenities

[1ec5]

The crux of the disagreement here seems to be how to name branches of multinational brands: is the brand’s consistency across the globe more important, or is the brand’s consistency with local naming practices more important? Depends on the use case, I suppose.

Unlike most of the keys NSI standardizes, name is prone to regional variation due to variations in cultural naming practices. For any data consumer that isn’t aware of all the ways brand and branch can be combined to form a name in the (unspecified) local language, a fully-qualified name or official_name can add information that’s hard to obtain otherwise.

There’s a limit to how well some of the American examples above translate to other countries – the U.S. is the land of strong brand identity! But even here, one could make the case that the name of an IGA supermarket should generally include the branch name, and NSI already has plenty of other per-category and per-brand exceptions. As I explained in openstreetmap/iD#8734, there can even be inconsistency within a single brand in a single country, but at least branch can be a way for a mapper to affirm that name intentionally includes the branch name.

branch + brand, not the other way around.

[Adamant36]

This is exactly what we have the key: brand=* for

Not really. The brand tag doesn't automatically resolve issues that might occur from someone putting whatever they want in the name field. Otherwise we wouldn't be having this discussion and putting junk characters as the name would essentially be OK, because who ultimately cares what's put in the name field since we have the brand tag?

but at least branch can be a way for a mapper to affirm that name intentionally includes the branch name

For me its about weighing the pros and cons. in this case the problem as I see it with puting the name of the branch in the field is that most people won't have any way of knowing that its the name of the branch and not just a different brand. Lots of brands out there share the same or extremely similar first words in their names. Sure there's the brand tag as @mathiash98 says, but the name tag is the defacto, universal first and main thing someone sees and searches for and there's way for people to know if something like "Seven-11 Arendal Sentrum" is THE 7-Eleven brand or just another one with a similar name. In the meantime hiding that information five steps down with a tag like brand when there's literally zero real world use for "Seven-11 Arendal Sentrum" is just ridiculously obtuse.

P.S. I asked a few messages back if the branch name had a real world use and my question was ignored. Of course if there is one then I'm willing to adjust my opinion, but ultimately there is numerous options of what can go in the name field and the usefulness of the information IMO is best way to decide what should or shouldn't go in it. People should also be able to say what the benefit of what they are asking for is.

Otherwise we could just as easily argue the Wikidata ID #, Wikipedia page title, internal corporate store ID #, slang name, or something else entirely should go in the name field. None of those are "technically wrong." Its just a matter of perspective. I.E. some locals call Walmart "Wally's World" and similar, but we don't default to that for the name of Walmart even though its technically a valid name for the locals who use it.

[mathiash98]

@Adamant36

• Of course one should not put in the name "Seven-11 xxxx" when the brand name is "7-Eleven", we should have consistent naming. The discussion is not about variants of the brand but whether or not to include branch in the name.

the name field is defacto, universal first and main thing someone sees and searches for

• This is exactly why we advocate for keeping name to be equal to brand + branch (or branch + brand) in order to make it easier for users to search for a particular amenity

(...) when there's literally zero real world use for "Seven-11 Arendal Sentrum"

Whenever someone tells me to meet me at "Esso Nesttun" I go to my map provider and search for "Esso Nesttun", then I expect to find a gas station names "Esso Nesttun", not just "Esso" which will require me to go into the hidden information five steps down with a tag like branch in order to know if this is the Esso I am looking for.

• In general it is very common to tell people too meet up at "Egon Lagunen" or "7-Eleven Arendal".

Another use case is that shop websites using "click and retrieve" (order and pay on website -> Pickup in store) will tell me to pick up my item at "Clas Ohlson Bergen Storsenter" -> I will then lookup in the map where this store is (searching on name as this is defacto standard in all applications).

[Adamant36]

we should have consistent naming.

Adding special words or characters to the end of a name isn't "consistent naming" though. Its literally a different name. "Walmart" isn't the same name as "Walmart, Sacramento, California." Its weird to act like it is.

Whenever someone tells me to meet me at "Esso Nesttun" I go to my map provider and search for "Esso Nesttun", then I expect to find a gas station names "Esso Nesttun", not "Esso" and then I have to go into the hidden information five steps down with a tag like branch in order to know if this is the Esso I am looking for.

I assume depending on the software that if Esso Nesttun was in the local_name field (or whatever alternative) and you searched it that you'd still be getting the Esso Nesttum in the results whatever the name field has in it. So you wouldn't have to go five steps down if you trusted the software and (or) knew it supported the alternative tag ahead of time. We literally have to do that with everything already.

In the meantime if it turns out you get the wrong result then its on Nominatim or whoever to figure out why you aren't getting the correct results in their software. Otherwise we could justify adding the location of anything in the name field just to make it more easily findable. "I don't know if I'm getting whatever mountain in the search or something else. So I'm going to put 'mountain, country, state, county, nearest locality, etc.' in the name field so I'm sure I get what I want."

Another use case is that shop websites using "click and retrieve" (order and pay on website -> Pickup in store) will tell me to pick up my item at "Clas Ohlson Bergen Storsenter" -> I will then lookup in the map where this store is (searching on name as this is defacto standard in all applications).

Every brand in the world that has pickup says what store location you should do the pickup at when you order something. Again, just because the location isn't in the name field doesn't stop you from finding it if the information is in a different one.

I should have clarified that by useful I meant within in the context of a use case that is unique to the name field and that can't just as easily (and probably better) be served by a different tag. If its a 1/1 where every reason that the name field should contain the location can also apply to something else, then the case should be made why we shouldn't just go with that something else instead.

Like @bhousel said, the branch tag is a more "modern" way of tagging store locations as opposed to puting the information in the name field and it has its advantages. Same with the other options. Looking at line 23 of https://github.com/osm-search/Nominatim/blob/master/settings/import-extratags.style it appears they support a ton of alternatives to the normal name tag. I don't see the branch tag listed there, but maybe its worth asking them to support it. If they don't want to for some reason its not like there isn't many other options though. My guess is that eventually someone will want to use them anyway. Realistically you can't edit war them over it if they do. So now might be a good time to embrace change, before its forced on you.

[bhousel]

Jeez can everybody chill? I want to respond to some points on this thread and it's impossible if people keep attacking each other.

Most importantly, NSI is configured to preserve names in the amenity/fuel category, so the example about Esso Nesttun is not even a situation where iD's validator would suggest to split the name. We can add this setting per brand or per category and we already have it set on a bunch of categories like gas stations, pubs, fuel stations, car dealers, and many others. We can add more of these, or I can just change the code in iD.

The issue of search has come up a few times - Nominatim has an old ticket open since 2018 to support the branch tag. osm-search/Nominatim#1161

[bhousel]

@NKAmapper said:

I think the index is a great idea, I just did not realize that it would enforce one way of using the name=* tag. I just discovered that a large number of store names had been edited in Norway and tried to understand how that happened.

I guess both methods (name=* with and without the branch name) are being used in other countries as well, but I have not checked. A problem with the branch tag is that search is in general not supported, at least not in Nominatim and in all the apps I have tried. A search will then usually just produce a list of identical brand names within the same city, which is not very helpful.

Yes branch tag is still gaining acceptance, but I heard about it a few years ago and it already seemed to have a significant usage at that point. I believe it's up well over 100k uses today. Part of what makes this an extra tricky problem is that name tag is special and often the thing that gets rendered on map pins, so most users will type whatever they want into there in order to get it rendered. That makes it not a great tag to use as the "primary key" for a POI.

The practice of name=brand+branch has in fact been used since 2012, and is being actively maintained that way. We have put a lot of effort into getting a complete and well structured set of the most common retail chains in the country into OSM. It has been discussed several times on IRC/#osm-no, including today.

What you built sounds really cool and I'd like to learn more about it (I'm about to build something similar). I really think our project can help you out with whatever you are doing. If you want to chat directly on OSM US Slack, OSM World Discord, or the OSM IRC server, please DM me on any of those places.

I agree it made sense in 2012 to join on the name tag and expect that brand+branch string to be mostly stable. After all this project is called "name-suggestion-index" because originally we only looked at name tags and generated presets that set name tags only! It took us many years to drop this behavior, and I'm sure the iD presets to set name tags on things have been breaking your process for a long time.

Today we have a lot more flexibility that we can use tags like brand:wikidata to identify the brand exactly, leaving the name tag to be the thing most users expect it to be: a search target and a thing to render on map pins. (The Co-op example above is the perfect example actually of a brand where there are dozens of "coops" around the world, and finally with brand:wikidata we can unambiguously know which brand the POI belongs to without location or country code lookups or other hacks).

I want to add, this is a hard problem and I believe nobody has really solved it really well, not even the commercial providers like Google, Apple, Here, TomTom, etc. Look at any of those and you can see inconsistency in how they name and label things too.

[1ec5]

P.S. I asked a few messages back if the branch name had a real world use and my question was ignored. Of course if there is one then I'm willing to adjust my opinion, but ultimately there is numerous options of what can go in the name field and the usefulness of the information IMO is best way to decide what should or shouldn't go in it. People should also be able to say what the benefit of what they are asking for is.

I don’t want to muddy this conversation even more, but since you asked, one underappreciated use case for the fully qualified name has little to do with rendered maps. Bulk geocoding services are often used for “location tagging” in news reports, receipts, bank statements, spreadsheets, etc. There isn’t a user meticulously choosing the best result for each query, but often the input does contain the fully-qualified name. The geocoder will yield higher-quality results if it’s able to index that fully qualified name, even if some of the input contains addresses too. This isn’t the same as indexing “Walmart, Sacramento, California” just because the Walmart location happens to be in Sacramento; rather, it’s about indexing “Tatsuda IGA”, “PostalAnnex Silicon Valley”, “East Springfield Avenue Shell”, or “Safeway #5052”. Someone looking at a map might regard that as clutter, but location data is used for more than maps.

Personally, I don’t consider it of utmost importance that the fully qualified name go in the name key. official_name would be fine by me. But I’m currently participating in an import (codeforsanjose/OSM-SouthBay#23) where we have both brand names and fully qualified names for thousands of POIs, potentially allowing us to locally achieve more precision and consistency than the competitors named above, on par with specialized non-map services. The fully qualified names were important enough to the shop owners that they contributed it to our data source. It would be sad if we had to toss out all that information and wind up less detailed than those other services; hopefully we can accommodate that data without forcing data consumers to guess. (The “brand branch” formula would get it wrong maybe half the time, and this is in the U.S.)

Yes branch tag is still gaining acceptance, but I heard about it a few years ago and it already seemed to have a significant usage at that point. I believe it's up well over 100k uses today. Part of what makes this an extra tricky problem is that name tag is special and often the thing that gets rendered on map pins, so most users will type whatever they want into there in order to get it rendered. That makes it not a great tag to use as the "primary key" for a POI.

Having editor support for the branch and official_name keys could take some of the pressure off the name key, at least for POI types where the branch name is clearly secondary to the brand name. openstreetmap/id-tagging-schema#215 and openstreetmap/id-tagging-schema#249 add fields to iD for the official and branch names, respectively.

[Gazer75]

I can't understand why the name= tag has to be only the brand tag? We have brand= for this.
The name could be anything that you find to be the "local" norm tbh.

I think some of this is cultural differences and brands are quite strong in the US. For Norway all of these brands that can have multiple stores in one city/town area all use the location name on their website, Facebook and in publications. Even the legal name include the location name for obvious reasons.

So I find it logical that the name= consists of both the brand and the branch. This makes it much simpler for data consumers to index and differentiate as well. They do not have to support a multitude of tags to produce a result.
Adding loc_name and official_name just clutters the tagging and complicates things.

name=Kiwi
branch=Palmafossen
brand=Kiwi
loc_name=Kiwi Palmafossen
official_name=Kiwi Palmafossen
legal_name=Ng KIWI vest AS avd 811 Palmafossen

See how this is starting to be a mess? What key is the consumer going to use for indexing this?
By simply removing all the silly local official and legal names and simply use the name tag it is cleaner and easier to use.

[zekefarwell]

I just looked up a local hotel. The sign out front says "Delta Hotels Marriot Burlington". On marriot.com they call it "Delta Hotels Burlington" and "Delta Hotels by Marriott Burlington" on the same page. When I called the phone number, the message welcomed me to "Delta Hotels Burlington Marriot". Yeah I'd say this is a difficult problem. 😀

[Adamant36]

Someone looking at a map might regard that as clutter, but location data is used for more than maps.

I don't care about map clutter a super amount myself, but I know it's something I know @bhousel tries to prioritize and I'm respectful toward that since he's the maintainer.

Having editor support for the branch and official_name keys could take some of the pressure off the name key, at least for POI types where the branch name is clearly secondary to the brand name.

The blocker for support in Nominatim was that branch tagging was all over the place when the issue was opened. It's been a few years though. So I might be worth seeing things have improved enough for them to add support for it. Or at least if not we could work toward improving things. Since whatever happens with this it would still be helpful in the long-term if the tag is supported in Nominatim.

I can't understand why the name= tag has to be only the brand tag? We have brand= for this. The name could be anything that you find to be the "local" norm tbh.

If a sign in front of a store says "7-eleven" on it and a sign on the door says ""7-eleven whatever", neither is technically wrong or not the name. I'm sure you could ask different employees of a store what the name of it is and they will give both options as an answer. That said, the purpose of the NSI is to be an add in mapping, and it's just easier for people to map stores by looking at the large signs in front of them.

I think some of this is cultural differences and brands are quite strong in the US. For Norway all of these brands that can have multiple stores in one city/town area all use the location name

I mean, we do the same in the US to a degree. It's just more informal and we don't treat it like a do or die situation. Which is how it seems like the people in Norway view it.

See how this is starting to be a mess? What key is the consumer going to use for indexing this?

No one is suggesting we use every single one of those tags at the same time. Personally, I have faith that the Norwegian community can pick the best tag for their use case. That said, I've seen much worse before.

By simply removing all the silly local official and legal names and simply use the name tag it is cleaner and easier to use.

Calling them silly is a little dismissive. They can serve an important purpose depending on the situation. So hopefully you don't go removing the tags just to make things "cleaner."

I just looked up a local hotel...Yeah I'd say this is a difficult problem.

Hotels are a particularly screwed up example of this problem. Sometimes I think they do it on purpose 🤣

[Gazer75]

Keep it simple I say. And that was our intent when discussing this for naming stores and such in Norway.
If consumer wants to read brand and branch then that's fine, if not then combine them in the name value.

I guess for small places where there is just one store or one of brand they would maybe just use "go to the store" or "go to Kiwi" in day to day speech. But when searching in an app and getting a list, having the full name is kind of essential.
Splitting this up also can cause funny naming as the developer of an app might not know what to put first, brand or branch, in a particular country.

By requiring branch value to be added you basically expects all devs to use this. This might result in less people picking apps based on OSM data as they find them inferior to say Google maps (From what I can tell they have the full name in the name field for a POI). They might not understand what OSM is and just think its a shitty app and move on.

[Adamant36]

Keep it simple I say.

One more tag doesn't complicate things that much.

If consumer wants to read brand and branch then that's fine, if not then combine them in the name value.

The problem is we don't really know what consumers prefer. Just what the opinions of you and a few other Norwegian mappers do. For all we know consumers might not actually prefer your method of tagging the name though.

When searching in an app and getting a list, having the full name is kind of essential.

Not really. Most of the world doesn't have the location in the name and we do perfectly fine. I find businesses in California with OSM all the time without issue and we don't do that way. Except in a few rare instances, like with hotels. That's not because we have to though or else everyone in America will run screaming from the project like your acting.

This might result in less people picking apps based on OSM data as they find them inferior to say Google maps (From what I can tell they have the full name in the name field for a POI). They might not understand what OSM is and just think its a shitty app and move on.

Sure, it might result in less people picking up apps based on OSM data, but there's zero evidence that it has in places where the name doesn't include the location. While on the flip side there's zero evidence that including it increases usage of OSM data. hat OSM isn't a direct competitor to Google Maps anyway. Most OSM "map consumers" are actually "geographical data consumers" and aren't using OSM as a map directly. So your average Google Maps user isn't really the intended audience. Like @1ec5 mentioned, one of the use cases for a fully qualified name (which is large but mostly ignored in these discussions) has little to do with rendered maps.

[Gazer75]

By using the combination of brand and branch in the name field the developers can pick how they want to index without loosing important information.

So if I am in my car and is supposed to meet someone at a specific shop, which would be given with brand and location here, and I start searching only to find 10 in a list of a brand but nothing else. How do you suggest I find the right one?
There is no indication other than perhaps an address that have no meaning to me as I don't know the area and street names.

Just because this is not common practice in the US doesn't mean the rest of the world should do it like you do.
Being told by someone almost on the other side of the globe how to tag stuff in my country doesn't feel right.
If you want to only use brand name in the name tag in the US then please do, but that is not common practice here.

The branch definition is really not a thing here for regular shops, but to help internationally we used it to make it clear.
The shops have a name that consists of the brand and the location, that's it. If they don't use that name on the building shouldn't matter, its probably a cost saving thing not having to put up more lit signs than needed.
Which to me is a good thing, to many big logo signs and light pollution as it is.

Some grocery brands use simple non lit signs for the location name.
Nærbutikken is one example of this. A brand of more rural and small grocery stores.

[NKAmapper]

Thank you for your edits to the supermarket and convenience files, @bhousel. Much appreciated. These are the other Norwegian brands in the index which would need a similar preserveTags rule:

Shop:
Trade: Bygger’n, Byggmakker, Byggtorget, Maxbo, Monter, XL-Bygg
General: Europris
Agrarian: Felleskjøpet
Garden centre: Hageland, Plantasjen
Hardware: Jernia, Würth
DIY: Biltema, Clas Ohlson, Obs Bygg, Coop Byggmix, Jula
Furniture: Bohus, Skeidar, Møbelringen, Fagmøbler
Alcohol: Vinmonopolet
Sports: XXL
Mobile phone: Mobit, Telenor, Telenorbutikken, Telia
Tyres: Dekkman, Vianor
Optician: Synsam
Car parts: Bilxtra
Car repair: Mekonomen
Books: Norli
Clothes: Carlings, Cubus, Dressmann, KappAhl, Lindex,
Shoes: Din Sko

Amenity:
Pharmacy: Apotek 1, Ditt Apotek, Vitusapotek, Boots
Restaurant: Beefeater, Egon, Peppes Pizza
Post office: Posten Norge
Cafe: Espresso House, Wayne's Coffee

Craft:
Plumber: Bademiljø, Comfort, Varme & Bad

Leisure:
Fitness centre: Sats

There could be other brands as well which I did not discover in the index.

Is it possible to have the same rule for the Norwegian stores of the Spar and the 7-Eleven brands? These two chains are not part of the international organisation in Norway. They have a different owner and operator in Norway, which have just acquired the right to use the logo (so the wikipedia reference is not correct either).

[bhousel]

There is - again - a bunch of misinformation being shared on this ticket, and I'd encourage people to take a step back and think carefully about how you post things, whether you are really adding to this conversation, and use the software before getting mad about things it doesn't actually do.

• This index did a long time require specific name values on POIs and we don't anymore. This is good!
  Is name required? #4034
• We go out of our way to make sure communities can use the name values that they want to. This can be scoped by location too, so if a local community wants to name their brands differently, they can do that. (We support localized names in Korean, Chinese, Cyrillic, Quebecois, anything)
• Splitting name into name/branch is a suggestion based on OSM Wiki guidance, that's been around for a while - we didn't invent it.
• The code I wrote in iD does not suggest name/branch for everything, only the ones where we think that's the right thing to do. For example, we preserve the existing name for pubs, gas stations, cinemas, hotels, post offices, car dealers, charging stations, vending machines, a bunch more. We preserve the unique names of the Apple stores.
  Store more information (including name handling rules) for each category #4906
• We can set the preserveTags property for some locations or some brands or some categories. (I'll go through @NKAmapper's list above and do that now - yes even global brands like Spar and 7-Eleven can have a special rule for Norway).
• If you find other situations where using branch not useful or the code splits the name wrong, open tickets for them either here or in iD (ideally with a screenshot of what it suggested). The code is trying to do a hard thing and I'm not surprised if there are bugs.
  Validator dismantles fully-qualified name of branch location openstreetmap/iD#8734
  Check branch splitting rule for "Texas Chicken & Burger" openstreetmap/iD#8719
  Branch tag added  #5281

[Adamant36]

Is it possible to have the same rule for the Norwegian stores of the Spar and the 7-Eleven brands? These two chains are not part of the international organisation in Norway.

How is that different then any other franchise or company that licenses a brand identity in the world? For instance in America Barns & Nobles licenses the Starbucks brand identity for it's in store coffee shops, but as far as I know they are still tagged as Starbucks' (and considered Starbucks coffee shops by most Americans) even though they are technically independent. Since it's the same signs, products, coffee shop layout, Etc. Etc.

[bhousel]

(I'll go through @NKAmapper's list above and do that now - yes even global brands like Spar and 7-Eleven can have a special rule for Norway).

update, I did this ☝️

[Adamant36]

update, I did this

Not to beat a dead horse, but I'm sort of bummed I didn't get my question about Starbucks' in Barns & Nobles answered because I asked the manager my local Barns & Nobles about it and he said they are actually "Barns & Nobles Cafe" even if though they use the Starbucks branding. So it might be something worth looking into and changing. I'll probably open an issue for it at some point if no one else does, but at least the discussion in this one helped clarify things. Even if some people thought it was argumentative. So I appreciate the constructive feedback that was given. As well as @1ec5 clarifying things about the branch tag in the Nominatim issue tracker 👍

[bhousel]

Not to beat a dead horse, but I'm sort of bummed I didn't get my question about Starbucks' in Barns & Nobles answered

Oh, I didn't see this as an issue about who owns the brand - I just see it as an issue of what they want to name these POIs in Norway.

In my view this is really no different than how in Quebec, "Staples" is named "Bureau en Gros", and "Kentucky Fried Chicken" is named "Poulet Frit Kentucky" (see #3162). They'd be rightly annoyed if iD suggested renaming these POIs back to the global name.