Render brand=* for amenity=fuel

[s3b4s5]

Hi! Sorry for my beginner English.

I propose to render on maps the label brand=* instead of name=* tag.

"Brand" should be prioritised rather than "Name".
Brand should be rendered if do not exist Name tag.

.
Explanation: for example write "Shell" or "Axion" on name label would be wrong, because these are the brands. "Name" is used only if the fuel station have a special name. And operator is, of course, the name of company.

At least in South America, it is always important to know the "brand" rather than the "name". Because the brand is synonymous price (usually Shell is more expensive than YPF in Argentina), fuel quality (octane), etc.

[kocio-pl]

It's more specific kind of #698 issue.

[naoliv]

At least for South America we need both (brand and name).
I don't know what could be better:
name - brand
name (brand)
name [brand]

Or have this info using two lines?

 name
[brand]

[jengelh]

Since the brand name is usually first on the receipts (at least it so happens in Germany), this should be reflected on the map. People also go by brand (because of bonus programs and whatnot), not so much a specific owner.

[matthijsmelissen]

How is this particular fuel station mapped? What does it say on the outside of the building?

[jengelh]

The buildings are generally branded in the style of the brand, that probably needs no explanation.

[dieterdreist]

2015-12-01 0:42 GMT+01:00 math1985 notifications@github.com:

How is this particular fuel station mapped? What does it say on the
outside of the building?

all petrol stations I have seen in my life put the brand on the structure,
it's definitely the main (aka most useful and important) tag for petrol
stations. Around here they are rarely buildings, much more often they are
just 2 pumps and a machine to pay (although bigger stations with a roof and
maybe a shop/cafe can be found).

It is not a problem if the name cannot be seen from far away. You can find
it in the Internet, ask the operator or look on the receipt. It is a
verifiable property. It might also repeat the brand or have it included as
part of it. On a rendered map I'd omit the name (save maybe very high zooms
like 20+) and use the brand for the label

[trigpoint]

Not all have a fuel brand displayed, I can think of some that just use their name, and I guess buy whatever brand of fuel is cheapest on the day.
I think they are perhaps know as Mom & Pops in the US.

[dieterdreist]

2015-12-01 10:45 GMT+01:00 trigpoint notifications@github.com:

Not all have a fuel brand displayed, I can think of some that just use
their name, and I guess buy whatever brand of fuel is cheapest on the day.
I think they are perhaps know as Mom & Pops in the US.

yes. obviously only branded petrol stations have a brand, unbranded ones
can be found in europe as well (but typically they will still show some
brand, but it will be unknown because the only have one or a few petrol
stations operating. Some mappers have in the past mapped these with
brand=independent (what is of course not helpful, because it suggests that
"independent" is a brand, but getting there you'll notice another "brand"
like "Freie Tankstelle" (German for independent petrol station)), even this
is kind of a brand:
https://upload.wikimedia.org/wikipedia/de/thumb/6/6f/FreieT.svg/100px-FreieT.svg.png
To get an impression what these look like:
https://www.google.com/search?q=freie+tankstelle&safe=off&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiA2PjYsrrJAhXBvhQKHeeaAWgQ_AUIBygB&biw=1873&bih=932
(the term "SB" is not a brand but an abbreviation for : "self service")

[matthijsmelissen]

I'm not sure what others think, but personally, I think that if the name 'Uwe Joch' appears nowhere on the outside of the tank station, and is not generally used by people using the tank station, it wouldn't be right to (only) use this name in the name tag.

[HolgerJeromin]

Imo this is the name, but only pedantic mappers knows this.
Name=Aral and official_name =Uwe Joch
seems wrong

[jengelh]

Search engine results suggest that the official name of this particular enterprise, as present in the Handelsregister, would be "ARAL-Tankstelle Uwe Joch e.K."

[dieterdreist]

2015-12-02 0:10 GMT+01:00 jengelh notifications@github.com:

Search engine results suggest that the official name of this particular
enterprise, as present in the Handelsregister, would be "ARAL-Tankstelle
Uwe Joch e.K."

this is the official name of the company, i.e. in osm this would be
"operator"

[jengelh]

I concur.
Anyhow, if brand==name, then the renderer should, despite "$brand $name" proposed above, obviously only show $brand.

[naoliv]

Do we have any news for this, please?

[kocio-pl]

I'm ready to make coding soon, given that this is the most wanted feature missing on the map. What's the outcome of this discussion - how exactly should it be displayed: which of the fields (only brand or both? which one should come first?) and in what format (using parenthesis or just with a new line)?

[jengelh]

From my side, the general algorithm (not just fuel, but also shops) could be

if (name == "") result = brand;
else if (brand == "" || (can_do_regex && name matches /\bBRAND\b/i)) result = name;
else result = brand + " " + name;

[dieterdreist]

sent from a phone

On 16. Sep 2017, at 23:47, jengelh ***@***.***> wrote: From my side, the general algorithm (not just fuel, but also shops) could be if (name == "") result = brand; else if (brand == "" || (can_do_regex && name matches /\bBRAND\b/i)) result = name; else result = brand + " " + name;

this would probably in many cases lead to 2 problems: repetition of names ("Shell Shell") or very long names. I'd coalesce brand, name for fuel, not sure for shops. In brand we should maybe replace semicolons with space or comma+space for rendering display.

[jengelh]

this would probably in many cases lead to 2 problems: repetition of names ("Shell Shell")

it wouldn't, that's excluded by the case-insensitive word (substring) match (expressed as regex here).

[dieterdreist]

sent from a phone

On 17. Sep 2017, at 11:26, jengelh ***@***.***> wrote: it wouldn't, that's excluded by the case-insensitive word (substring) match (expressed as regex here).

still in rendering I'd focus on brands and drop the name in case it is there, while in search, name is more interesting.

[naoliv]

still in rendering I'd focus on brands and drop the name in case it is there, while in search, name is more interesting.

But then we will have the problem in another direction: people will start to wrongly include/use name in brand, to have it rendered.

[ftrebien]

My understanding of good mapping practice:

• brand is the main brand name, regardless of anything else, even apparent visual style; brand=Independent is not defined but I believe its de facto usage means no actual main brand, so I think it should not be rendered (that is, treated as if there was no brand assigned to the element)
• name is a verifiable name visible from the ground, by definition not the brand (it may be part of the name, even though it is quite rare in my experience); if there's no name, only the brand is implied by visual style, then:
  • do not add name
  • possibly add noname=yes to express that name is not missing simply because it hasn't been surveyed
• other name tags such as official_name and loc_name do not need to be verifiable on the ground by definition, and are expected to be indexed by geocoders, regardless of rendering

So, previously mentioned examples would be tagged in a semantically correct way as:

• brand=Aral + official_name=Uwe Joch + noname=yes and no name
• brand=Shell + noname=yes and no name

Thus, I believe that, if brand is considered usually more recognizable than name, then there are only two possibly desirable choices for rendering the label:

• render brand if present, otherwise render name; or
• render brand [sep] name with [sep] being either a hyphen or a line break

The second option encourages mappers to tag elements properly, which I understand is one of Carto's main goals. That is, if Aral - Uwe Joch and Shell - Shell are undesirable renderings, I believe it is because tag semantics was not respected when mapping, the tags need to be corrected, and the incorrect rendering would be exposing this and encouraging mappers to take action.

Adding an unverifiable name (that should go in official_name or loc_name) to name (such as name=Uwe Joch) or mixing tag purposes (such as name=Shell) can lead to edit wars and that's one of the reasons why mappers should avoid doing that. Mappers and their mapping tools should encourage semantically correct mapping. Both JOSM and iD allow mappers to add any tag they wish, but IMHO neither makes yet the distinction between non-existing and unclear/unknown (not surveyed yet) names as clear as it should be to avoid confusion. JOSM supports noname=yes in its validators though.

If things were incorrectly tagged due to wrong interpretation of tag semantics or to obtain a specific result in rendering, then the data needs to be fixed, not the app. At least the common situation of name having exactly the same value as brand can be easily fixed by a bot.

[SomeoneElseOSM]

In case it helps anyone, I recently added brand and/or operator processing to a map style via lua. See https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/b9772ae44de94e17728af1ce00344d411148886e/style.lua#L982 . Results as per https://map.atownsend.org.uk/maps/map/map.html#zoom=20&lat=53.1927617&lon=-1.342772 (I chose brackets for the brand/operator, there are other possibilities of course).

[dieterdreist]

2017-12-04 20:20 GMT+01:00, ftrebien <notifications@github.com>:

brand=Independent_ is not defined but I believe it's de facto usage means no actual main brand, so I think it should not be rendered (that is, treated as if there was no _brand_ assigned to the element)

I would not make special treatment for undocumented tags, that are supposedly in contrast with the documentation. Rendering these errors will help us resolving the issue, while hiding them will make them persist (longer).

* _name_ is a verifiable name visible from the ground, ... * other name tags such as _official_name_ and _loc_name_ do not need to be directly verifiable by definition, and are expected to be indexed by geocoders, regardless of rendering

all tags have to be verifiable, but that does not mean necessarily that you can _see_ them on the ground, (e.g. you might see them on the receipt, on a publicly visible register, being told by the shop owner or someone else, etc.)

[ftrebien]

I would not make special treatment for undocumented tags, that are supposedly in contrast with the documentation.

I think that's fine. If people complain, then they should first formalize the meaning of that value and then request Carto support for that. I think that this is part of a deeper issue in OSM where people are coming up with special values to represent the difference between missing knowledge (absent tag) and knowledge about non-existence or about lack of clarity (sometimes some special tag values, sometimes an auxiliary tag).

you might see them on the receipt, on a publicly visible register, being told by the shop owner or someone else, etc.

That seems reasonable, but what's on a receipt is not so apparent (and often not exactly the same as what's on the signs, at least where I live, where it is often a less-known registered name with the government that is more suitable for official_name), and what people tell you is often conflicting and would often suit loc_name better, so I'd be careful when relying on these sources of information. Also, the good practice article specifically says that:

they need to find the names from local signs in the map and vice versa. The only exception to this could be obvious misspellings

This, of course, requires some knowledge of tag semantics. I'm not the only person that thinks that name=Shell + brand=Shell is usually a mistake in interpreting the purpose of name.

[dieterdreist]

Following recent discussions on the Italian ML (because of an import of fuel stations), here is an example for a node amenity=fuel without name but with brand:
https://www.openstreetmap.org/node/429433477
We should show the brand in this case (besides the price, it's the most important information for petrol stations anyway)

[kocio-pl]

Would you like to prepare the code, so we could discuss it on a test rendering? I feel that such an old discussion won't fly without some real support.