Render brand=* additionally to name=*

[floscher]

This is supposed to solve parts of #698.
I've picked some amenities, for which it makes the most sense to render brand. These are:

• amenity=fuel (Shell, Esso, Agip, Total, BP, …)
• amenity=bank (Sparkasse, Volksbank, Commerzbank, …)
• amenity=fast_food (Mc Donald's, Burger King, Subway, …)
• shop=supermarket (Aldi, Lidl, Rewe, Coop, …)
• shop=department_store (Ikea, Woolworth, Galeria Kaufhof, …)

Depending on what tags are present (only name, only brand or both), one of the following variants is rendered:

• [name]
• [brand]
• [name] + "\n(" + [brand] + ")"

Currently this will result in many amenities (especially petrol stations) showing up as "Brand xy\n(Brand xy)", because many of them have the same value for the brand- and name-key. I even had difficulties to find a petrol station, that has different values for name and brand. But this is in my eyes a tagging-mistake (tagging for the renderer), which will hopefully be corrected as soon as brand renders in this style (see also the comment by Rovastar to issue #698).

[matkoniecz]

Can you provide a rendering example?

[floscher]

Two examples for the rendering of name and brand (for amenity=fuel and shop=supermarket):

Current rendering (only name is rendered):

[matthijsmelissen]

Thanks! I think rendering the brand name will be a great improvement.

I'm not sure what would be better - rendering the brand name only for selected POI, or for all POI? Are there any POI for which rendering the brand would be a disadvantage?

Alternatively, we could do the computation of the name in the SQL rather than in the CartoCSS code. I think it would save some duplication, and more importantly, it would reduce the number of cases in the generated XML code. Something like this should work (untested).

CASE WHEN name IS NULL OR brand IS NULL THEN COALESCE(name, brand) ELSE name || "\n(" ||  brand || ")" ) END AS name 

(It needs an extra condition if we don't want it for all POI.)

Also, I think it doesn't matter, because it shouldn't get triggered anyway, but you're inconsistent with the default case. Sometimes you use text-name: [name]; and sometimes you use text-name: '';.

By the way, the brand of the gas station in your example is of course a tagging error. Probably this code will highlight many tagging errors like that, but I guess that's a good thing because it means they'll get corrected faster :).

[matkoniecz]

By the way, the brand of the gas station in your example is of course a tagging error. Probably this code will highlight many tagging errors like that, but I guess that's a good thing because it means they'll get corrected faster :).

Independent as brand is widely used, it is one of top values.

[sb12]

Currently this will result in many amenities (especially petrol stations) showing up as "Brand xy\n(Brand xy)", because many of them have the same value for the brand- and name-key. I even had difficulties to find a petrol station, that has different values for name and brand. But this is in my eyes a tagging-mistake (tagging for the renderer), which will hopefully be corrected as soon as brand renders in this style (see also the comment by Rovastar to issue #698).

So you are suggesting to delete all the name tags for McDonalds restaurants, Burger Kings, Rewes etc. when they have a brand tag? This means that all other applications also have to use the brand-tag otherwise the names of supermarkets, fuel stations and fast food restaurants are not shown anymore.

I think it's perfectly fine for a fast food restaurant to have 'name=McDonalds' and brand='McDonalds'. See also http://wiki.openstreetmap.org/wiki/Key:brand#Distinguishing_between_Brand.2C_Name.2C_Operator.2C_etc.
This will probably result in even more tagging for the renderer because people will delete the brand-key as they don't want to show it up twice.

Independent as brand is widely used, it is one of top values.

It's also in the JOSM-preset for fuel stations. I didn't find documentation for it, but afaik it is used for fuel stations that do not belong to a specific brand.

[floscher]

math1985 wrote:

I'm not sure what would be better - rendering the brand name only for selected POI, or for all POI? Are there any POI for which rendering the brand would be a disadvantage?

I'd go with a limited set of POIs, because e.g. amenity=embassy, amenity=prison, landuse=military, natural=bay or natural=forest don't make much sense with brand=*. These tags don't currently have brand-tags (didn't check that, but I assume that), but I suspect, that some mappers could misuse them for displaying some text in braces below the name of some POI.

Alternatively, we could do the computation of the name in the SQL rather than in the CartoCSS code. I think it would save some duplication, and more importantly, it would reduce the number of cases in the generated XML code.

+1
Your suggestion would be an elegant solution for the current duplication in my opinion.
If CartoCSS wouldn't force text-name to always appear in conjunction with the text-attributes for styling the text (text-face-name, text-size, …), it could also be done in MapCSS with less duplication. Then one selector could be created for all amenities for which brand should be rendered, which determines only the text-name.

you're inconsistent with the default case. Sometimes you use text-name: [name]; and sometimes you use text-name: '';.

That was intentional: In the pub/biergarten/restaurant/fast_food/cafe-selector, the default is name, because this will be used for pub, biergarten, restaurant and cafe. But in the bank-selector the default is '', because it will never be used. MapCSS doesn't recognize the unused default and thus requires some default. This could basically be anything, but wouldn't change the result, so I chose the simplest value, the empty string.

By the way, the brand of the gas station in your example is of course a tagging error. Probably this code will highlight many tagging errors like that, but I guess that's a good thing because it means they'll get corrected faster :).

As mkoniecz and sb12already mentioned, brand=Independent is used for gas stations, that do not sell a specific brand, so this gas station is tagged correct. It is a member of the "Federal Association of free gas stations and independent german mineral oil dealers" (German: Bundesverband Freier Tankstellen und Unabhängiger Deutscher Mineralölhändler e. V.) or short bft. Maybe you could also tag brand=bft, but brand=Independent isn't really wrong.

[floscher]

sb12 wrote:

So you are suggesting to delete all the name tags for McDonalds restaurants, Burger Kings, Rewes etc. when they have a brand tag? This means that all other applications also have to use the brand-tag otherwise the names of supermarkets, fuel stations and fast food restaurants are not shown anymore.

Yes, if the name-tag equals the brand-tag. If the POI has an own name, this one should be placed in the name-tag, otherwise no name-tag should be present.
And yes, applications should consider the brand-tag additionally to the name tag. This would be an improvement especially for businesses, that make use of both. A common example in Germany is Edeka. Edeka is the brand, but the supermarkets for this brand are operated by many different operators (typically one operator has one, maybe two or three supermarkets) and often also called after the owner. Examples for names are "Scheck-In", "aktivmarkt John Doe". These would then be represented correctly in those applications.

Just recently I needed this feature in OsmAnd, when I searched for a gas station and needed a certain brand, because I had a company car with a fuel card for this brand. But I was in a region, where it showed me only entries like "gas station City XY east", "gas station John Doe" or "self-service gas station". I had to manually open each one and look up the brand-tag (almost all had one). It would be so much better, if applications would evaluate both the name- and brand-tag.

[dieterdreist]

2014-09-24 1:54 GMT+02:00 Florian Schäfer notifications@github.com:

Yes, if the name-tag equals the brand-tag. If the POI has an own name,
this one should be placed in the name-tag, otherwise no name-tag should be
present.
And yes, applications should consider the brand-tag additionally to the
name tag. This would be an improvement especially for businesses, that make
use of both. A common example in Germany is Edeka. Edeka is the brand, but
the supermarkets for this brand are operated by many different operators
(typically one operator has one, maybe two or three supermarkets) and often
also called after the owner. Examples for names are "Scheck-In",
"aktivmarkt John Doe". These would then be represented correctly in those
applications.

actually things are much more complicated than this, have a look here in
German: http://de.wikipedia.org/wiki/Edeka
There are many brands which are all owned by the group Edeka Zentrale AG &
Co. KG
examples for the brands are EDEKA, Edeka-Aktivmarkt, Edeka-Neukauf, Spar,
E-Reichelt, Netto Marken-Discount, Plus etc. There are also bakeries,
travel agencies and more owned by the group.
Then there are cooperatives of "independent" retailers owning the group,
"Regionalgesellschaften" for the wholesale part which are supplying goods
for the independent retailers and also to the branches (which are either
operated by the group, or by the "regional corporations"). Edeka (being
very big and heterogenous) is a perfect example that it is almost
impossible to reproduce the details in OSM.

[sb12]

And yes, applications should consider the brand-tag additionally to the name tag. This would be an improvement especially for businesses, that make use of both. A common example in Germany is Edeka. Edeka is the brand, but the supermarkets for this brand are operated by many different operators (typically one operator has one, maybe two or three supermarkets) and often also called after the owner. Examples for names are "Scheck-In", "aktivmarkt John Doe". These would then be represented correctly in those applications.

I agree that this improves the rendering for Edekas (I always tagged them as name=Edeka Aktivmarkt XY until now), some Rewes, many fuel stations and eg. British Wetherspoon pubs (Operator and brand is Wetherspoon, while it usually has a name like e.g. "The Red Lion"). Especially for fuel stations I like this very much, because as you said when you have a fuel card the brand is actually more important than the name of the fuel station.

Just to clarify: I like the rendering of the brand name and I also tag it a lot, what I do not like in this approach is the double rendering of name and brand (if both is set). If we assume that it is wrong to tag a name when the name is actually a brand, I think this needs to be discussed with the community and the wiki needs to be changed accordingly. I would prefer to have something like

if brand == name
then only show name

Please also think about the impact of this style. This can lead to a massive retagging of names especially for fast food restaurants and shops. So other applications need to be aware of this change so they can adapt their code to also use brand instead of name.

Also by only rendering the brand for specific shops, this means that an IKEA will appear with only the brand tag, while Boots, Primark, WHSmith etc. still need the name tag for the name to appear on the map. Same applies to coffee shops (e.g. Starbucks).

• amenity=fuel (Shell, Esso, Agip, Total, BP, …)
• amenity=bank (Sparkasse, Volksbank, Commerzbank, …)
• amenity=fast_food (Mc Donald's, Burger King, Subway, …)
• shop=supermarket (Aldi, Lidl, Rewe, Coop, …)
• shop=department_store (Ikea, Woolworth, Galeria Kaufhof, …)

I would add

• amenity=pub (Wetherspoon)
• amenity=cafe (Starbucks)
• amenity=restaurant
• tourism=hotel/hostel/motel (Mariott, Best Western, Holiday Inn, ...)
• all shops (Primark, WHSmith, Barnes & Noble, Thalia, Boots, Media Markt, RadioShack, ...)

[matkoniecz]

I mentioned this pull request on taging mailing list ("name and brand tags" topic - https://lists.openstreetmap.org/pipermail/tagging/2014-September/thread.html ), as I agree with

Please also think about the impact of this style. This can lead to a massive retagging of names especially for fast food restaurants and shops.

especially as currently wiki describes 'name=McDonalds' and brand='McDonalds' as OK.

[gravitystorm]

I'd like to see the name vs brand issue resolved before merging this.
For example, if a McDonalds restaurant is really named "McDonalds Wandsworth" then "McDonalds Wandsworth (McDonalds)" looks daft. We can use case when position(brand in name) = 0 then ... to handle many cases like this.

[dieterdreist]

2014-09-24 19:00 GMT+02:00 Andy Allan notifications@github.com:

For example, if a McDonalds restaurant is really named "McDonalds
Wandsworth" then "McDonalds Wandsworth (McDonalds)" looks daft. We can use case
when position(brand in name) = 0 then ... to handle many cases like this.

+1. Actually for restaurants (in general for many POIs) displaying both
will lead to long strings and hence fewer displayed name instances. We
could use this long form for zoom18 or 19 and use a coalesque name/brand
for lower levels of zoom.

[floscher]

I've now reworked the pull request. Now the SQL decides, if the name, the brand or both is displayed.

It also checks, if the value of the name-tag starts with the value of the brand-tag (case-insensitive) and displays only the name, if this is the case.

By the way: Is there a better way to add a \n to the SQL in project.mml, than to add a line break followed by exactly 8 spaces in the project.yaml?

[HolgerJeromin]

Perhaps checking if the name ends with the brand would be useful, too.

[pnorman]

By the way: Is there a better way to add a \n to the SQL in project.mml, than to add a line break followed by exactly 8 spaces in the project.yaml?

You shouldn't be editing project.mml directly. Spaces within the YAML are for syntax formatting, so add them as necessary - most good text editors will help with this.

If you need to add a new line within a SQL string constant, do E'foo\nbar'.

[floscher]

You shouldn't be editing project.mml directly. Spaces within the YAML are for syntax formatting, so add them as necessary - most good text editors will help with this.

I did not want to do that. I just wanted to produce a project.mml-file containing 'foo\nbar' (by running the yaml2mml-script over the yaml-file), but I only found the approach to write the following in the project.yaml:

'foo
        bar'

With exactly one newline-character and 8 spaces between foo and bar this translates to 'foo\nbar' in the mml-file, less spaces let the translation-script fail, more spaces add spaces after \n, which is undesired in this case.

I knew that this approach was error-prone, makes the yaml-file harder to read and it might get broken by future editors, who want to format the SQL for better readability. So I asked for a better solution.

If you need to add a new line within a SQL string constant, do E'foo\nbar'.

Thank you for your tip , this solves exactly my problem. I didn't know about this PostgreSQL-feature of escape string constants before.

This change is now incorporated in this pull request.

[pnorman]

Stale PR, and the issue related to it is closed.

[nighto]

In my humble opinion (and I know this is polemic), the tag name=* for those POIs is much more official_name=* then name=*. But this is subject to the tagging list, not here, so feel free to ignore.

[BalooUriza]

On Thu, Sep 17, 2015 at 10:44 AM, Arlindo Pereira notifications@github.com
wrote:

In my humble opinion (and I know this is polemic), the tag name=* for
those POIs is much more official_name=* then name=*. But this is subject to
the tagging list, not here, so feel free to ignore.

Gas stations and convenience stores that have franchises tend to be
problematic for this. The sign out front often has something like
"Cherokee", "Phillips 66" or "Conoco" but the name on the front of the
station/store/restaurant there might be something like "Pawnee Nation
Casino", "Batman's Good Food" or "Three Flags Drive-Thru Tobacco".

[Stemby]

Please, could you look at this discussion?

Thank you!