tourist=attraction label blocked by oneway arrow

[jidanni]

Expected behavior

Zoom in and and tourist attraction still there

Actual behavior

Zoom in and and tourist attraction disappears

Links and screenshots illustrating the problem

https://www.openstreetmap.org/node/4877275221
Appears at zoom level 17, then gone at 19.

[HolgerJeromin]

The name collides with the streetname at zoom 19.
18:

19:

[jidanni]

OK that's terrible...
Neither names or pedestrians near roads are safe these days!

[jidanni]

In an ideal world, the name would simply be printed to the right of where the road (now, zoomed to 19) is. Alas, it was unfortunately "hit by the road name". If it only had been a little further down the road it wouldn't have happened(?)... but then it might have got hit at a different zoom level(?).

[HolgerJeromin]

Near road? I thought the attraction is on the right lane of the raod:

[jidanni]

Next month I will turn the attraction into an area. But that is beside the point. The mapper apparently placed it beside the road as would be expected of mappers who want to map a single point.

So in conclusion should we tell mappers "Place any single points at least xx meters away from roads!"?

[HolgerJeromin]

It is placed on the road! So collision with the street name is more likely.
But in any case we will always have collision with other stuff in computer generated labels.

[jidanni]

What if the mapper was using different or no imagery than in your screenshot when he made the edit?
In that case we know he placed it east (to the right) of the road.
If he placed it on the road, the node would be part of the road.

[jidanni]

I checked Google Maps in the densest of cities. The street names always have a way of moving around, avoiding place names.

[jeisenbe]

The name collides with the streetname at zoom 19.

Not quite, the names are rendered with lower priority, since they can move around on the line of the street or road.

The problem is the oneway arrow, that's what is blocking the name label for the tourism=attraction.

Note that we decided to render tourism=attraction names with low priority, since this tag is vague.

Perhaps there is a more specific tag for this feature, "蕃茄會社" "Tomato Club"? Is it a nightclub perhaps? More specific tags are rendered with slightly higher priority, though the oneway arrow issue might still be a problem.

[jeisenbe]

This is nearly a duplicate of #2429

[jidanni]

Well in #4150 (comment) you can look at the photo link. I won't edit it just to fix this bug, as that would be "tagging for the renderer."

[jidanni]

#4163

[jeisenbe]

I won't edit it just to fix this bug, as that would be "tagging for the renderer."

The phrase "tagging [incorrectly] for the renderer" is used when mappers enter incorrect or sub-optimal tags, features or geometries to get a certain visual result.

In this case, moving the feature to it's actual location, as suggested in the aerial imagery, would likely solve the rendering problem. That would not be "tagging for the renderer", it would be correcting the location of a mis-placed node (unless this feature is in fact located underneath the asphalt roadway?)

Closing as a duplicate of #2429 - conflicts between text labels and oneway arrows

[HolgerJeromin]

"tagging for the renderer."

We should really use "lying for the renderer." as a phrase. But too late :)