labeling logic for golf=hole inconsistent between MSS and SQL

[imagico]

SQL code requires ref:

openstreetmap-carto/project.mml

Line 2113 in aef9179

OR (tags @> 'golf=>hole' AND ref IS NOT NULL)

while MSS code renders name with priority over ref.

openstreetmap-carto/style/golf.mss

Lines 35 to 45 in aef9179

	[feature = 'golf_hole'][ref != ''],
	[feature = 'golf_hole'][name != ''] {
	text-placement: line;
	text-size: 11;
	text-fill: @golf-color;
	text-face-name: @book-fonts;
	text-halo-radius: @standard-halo-radius;
	text-halo-fill: @standard-halo-fill;
	text-name: "[ref]";
	[name != ''] { text-name: "[name]"; }

This is inconsistent and confusing for mappers.

We either should change the SQL condition to also include features with name but no ref or we should remove the name support from MSS. Currently about 11 percent of golf=hole have a name tag - see here. >90 percent have a ref tag. So i would be slightly in favor of making it ref only (simpler logic, simpler code, not much lost).

[benjaco]

Looking at the golf docs

ref=* - number of the hole
name=* - (rare) the common name of the hole, if there is one. Hole number belongs to ref=*

For example, the Masters Golf Course in Augusta, Georgia, USA, not only assigns numbers to their golf holes, but specific names are assigned to each one;
Hole 1 – Tea Olive, Hole 2 – Pink Dogwood, etc.
In this case, both ref=* and name=* would be tagged on the golf hole. The tag ref=* would be used to describe hole numbers while the tag name=* would be used for the name of each hole.
If a hole does not have an actual name, ref=* is sufficient.

Then I will almost argue for showing both if exist eg, name is a guides reference when used:

OR (tags @> 'golf=>hole' AND (ref IS NOT NULL OR name IS NOT NULL)  ) 

And mms like

[feature = 'golf_hole'][ref != ''], 
[feature = 'golf_hole'][name != ''] { 
   ...
   text-name: "[ref]"; 
  
   [name != ''][ref != ''] { text-name: "[ref] - [name]"; } 
   [name != ''][ref = null] { text-name: "[name]"; } 
}

The example Masters Golf Course in Augusta, Georgia, USA don't shows the hole numbers at the moment which feels wrong.

But the overpass query shows that when both is present, which is the case a lot of places, then the number is often in the name as well to show the number on the map, which following the docs is wrong.

[out:json];
(
  way["golf"="hole"]["name"]["ref"];
);
out;

Then the options could be to just show then name and ref to encourage to remove the number from the name as the docs says, or complicate the mss to check for the substring like

[feature = 'golf_hole'][ref != ''], 
[feature = 'golf_hole'][name != ''] { 
   ...
   text-name: "[ref]"; 

   [name != ''][ref != ''][name!~=ref] { text-name: "[ref] - [name]"; } 

   [name != ''][ref != ''][name~=ref]
   [name != ''][ref = null] {
      text-name: "[name]"; 
    }
 
}

(not sure if I nailed the syntax)
But I'll general agree that keeping it simple would be nice

[imagico]

That would add substantial complexity in code, is difficult to intuitively understand for the map user (compound labels with no clear indication how it is composed from tags) and would work poorly in most non-latin scripts.

But more importantly: The name tag on golf=hole almost never contains a proper name:

https://www.openstreetmap.org/way/909406128
https://www.openstreetmap.org/way/1135730674
https://www.openstreetmap.org/way/897105274
https://www.openstreetmap.org/way/931962337
https://www.openstreetmap.org/way/574577047
https://www.openstreetmap.org/way/808552984
https://www.openstreetmap.org/way/788926408
https://www.openstreetmap.org/way/882009720
https://www.openstreetmap.org/way/928834753
https://www.openstreetmap.org/way/1079334197
https://www.openstreetmap.org/way/1079091264

This in my eyes rules out rendering the name tag - there is no consistent use of the name tag on golf=hole that we could support by showing it.