-
Notifications
You must be signed in to change notification settings - Fork 821
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"tourism" refrains "man_made" node from rendering "name" #3545
Comments
Thanks for the report, it looks like a valid problem. Would you like to prepare the code fixing this? |
I think this is a text-dy problem? If there is a man_made=cross alone, the code moves the name label text down by 6 pixels so that the name label is not blocked by the icon:
But tourism=attraction is rendered without an icon, like an area feature, the same as zoos and theme parks:
The wiki page for tourism=attraction says: "This tag may be added to object to indicate that the place is interesting for tourists. Note that tagging just tourism=attraction is not enough - this tag should be used only as addition to main tag describing the feature. "For example tourism=attraction + name=Waterfall "Foobar" is not a proper way to tag waterfall named Foobar, such object should be tagged rather with waterway=waterfall + tourism=attraction + name=Foobar." "Other (rarely used) possible way is to map the primary feature (eg waterfall) and add tourism=yes." So this suggests that we could solve this problem by removing the code to render names for features that are tagged tourism=attraction without another tag. Thoughts on this option? |
Previous threads and comments about tourism=attraction : #460 (comment) #1047 "Change color tourism=attraction label and drop rendering of tourism=attraction areas " |
That does seem to the issue as other things co-tagged with tourism attraction dont seem to have their names render either. Whereas places just tagged as tourism attraction do have their names rendered. The problem with removing name rendering from attraction is that you'll be removing a lot of names of importent features from the map. As a lot of things are tagged that way despite the wiki. Id imagine there's a lot of places out there like city districts or wharfs that dont have clear boundaries or objects to add the tourism node to that are still interesting to tourists. There's a few such places in San Francisco. It would be a shame to remove the names of those things from the map. Although, im not sure there is a better solution, but its still something to consider. |
sent from a phone
On 4. Dec 2018, at 02:53, jeisenbe ***@***.***> wrote:
So this suggests that we could solve this problem by removing the code to render names for features that are tagged tourism=attraction without another tag.
Thoughts on this option?
I am in favor. Many people look at osm-carto to check their mapping, if the attraction tag alone doesn’t lead to renderer they will often add more (descriptive) tags.
|
I've looked into this bug, and I suspect it is related to the amenity-low-priority layer, for man_made=cross and historic=wayside_cross (the other features in this layer do not have a name label rendering) There are a couple possible solutions: 1) Add and icon and text-dy for tourism=attraction
2) Remove rendering of the name label for tourism=attraction
I believe option 2) is the best, so I will ask on the tagging mailing list, to confirm if the current wiki page description is correct. It might also be possible to remove man_made=cross and historic=wayside_cross from the low priority layer, move to higher priority position in amenity-points.mss
|
ref #3446 |
This tag has now been discussed on the tagging mailing list. https://lists.openstreetmap.org/pipermail/tagging/2018-December/ Many people felt that all tourism=attraction can be tagged with a more specific tag. Taginfo shows a number of popular combinations https://taginfo.openstreetmap.org/tags/tourism=attraction#combinations However, there are over 10,000 combined with attraction=, mostly attraction=animal (to tag a specific animal exhibit in a zoo). Attraction is also frequently used with water_slide, roller_coaster, amusement_ride, and carousel. These seem to be fairly reasonable uses of the tourism=attraction tag, though perhaps attraction= alone would be sufficient. While we could switch to rendering only features also tagged with attraction=*, it would be less disruptive to switch to rendering tourism=attraction only at z17 and higher, and no longer rendering it early when tagged on large areas. A generic marker should also be added to show the location of the attraction. I'd suggest using @tourism color to match zoos and amusement parks. This will appropriately render attractions such as animals in zoos and amusement rides in theme parks, but should encourage mappers to look for better ways to tag large areas. I found that I can resolve the initial issue by moving 'tourism' below man_made_cross in project.mml, so that it renders after man_made=cross and historic=wayside_cross. Test area, currently: |
@jeisenbe, how come you do test renderings with style maps (or whatever their called) instead of using the actual map map in Kosmtik? I noticed you did the same thing with roads. It would be interesting to know if it might give different results that way or what the pros/cons are. I'm sure whatever your using is a lot smaller in file size then the average shape file at least. |
I still think violet is good for both attraction and zoo/theme park. |
how come you do test renderings with [test data] instead of using the
actual map data?
As you guessed, it saves internet data. In this case I had already added
these features in JOSM while trying to find if this issue occurred with
other features, or just with man_made=cross and historic=wayside_cross, so
it was easy to show a test image this way
For highway=construction it is impossible to find all types of
construction=* in one area. It is much easier to test with artificial data.
I still think violet is good for both attraction and zoo/theme park.
I agree!
Should we do that PR first or do we need to change the boundary color first?
…On Thu, Dec 20, 2018 at 6:01 AM kocio-pl ***@***.***> wrote:
I still think violet is good for both attraction and zoo/theme park.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3545 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshOZxuFqYBZWDFBpm8g5NffDCKJyEks5u6qk-gaJpZM4Y9Gsv>
.
|
I would start with boundary. That would be also needed for merging #3521 at last. |
I still don't fully understand the problem in this issue - could somebody give me a short summary of the cause? |
I believe I understand the problem.
Man_made=cross and historic=wayside cross have name renderings, but they
are in the low-priority amenities layer
Tourism=attraction is in the regular layer, which is rendered first (or at
higher priority?) based on its position in project.mml
But tourism=attraction features currently render as maroon text without an
icon. There is no text-dy so the cross icon blocks the name, which would
otherwise render at the same place. (I’ve seen this clearly at meta tile
boundaries while testing)
So to fix this, I’ve recommended we
move tourism_attraction to the low-priority layer
- this is sensible because it is often a secondary tag.
- but it is also sometimes a feature, eg a rollercoaster or a zoo animal,
and should render when there is no other tag.
…On Sun, Dec 30, 2018 at 7:53 PM Matthijs Melissen ***@***.***> wrote:
I still don't fully understand the problem in this issue - could somebody
give me a short summary of the cause?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3545 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshL7B4OX12imdnkR-HNHDJFq6aneZks5u-JtEgaJpZM4Y9Gsv>
.
|
@jeisenbe I still don’t follow. Which feature blocks rendering of the man_made cross name? |
Ah, I guess I get it now. So part of the issue is that for objects that are both man_made=cross and tourist=attraction, the label is rendered in the latter style? Perhaps we could solve this by change this order? |
Right. It was only a problem with man_made=cross and
historic=wayside_cross, because these are rendered at lower priority and do
have a name label.
In the PR I moved the tourism_attraction line down below the other features
in the text-point and text-poly layers in project.mml and this fixed the
issue.
Actually, I just remembered that it isn’t necessary to have tourism
attraction in the amenity_low_priority layers now, because we are not going
to render the icon. So I’ve removed these two lines from project.mml
…On Mon, Dec 31, 2018 at 3:10 AM Matthijs Melissen ***@***.***> wrote:
Ah, I guess I get it now. So part of the issue is that for objects that
are both man_made=cross and tourist=attraction, the label is rendered in
the latter style? Perhaps we could solve this by change this order?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3545 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshGSxXai_orzJHecAn3ppuQcEU6eWks5u-QF3gaJpZM4Y9Gsv>
.
|
Expected behavior
Related to: https://www.openstreetmap.org/node/1980961590
Combining
man_made=cross
andtourism=attraction
should not refrain the feature from rendering itsname
beneath the cross icon.Actual behavior
See history: https://www.openstreetmap.org/node/1980961590/history
At the version 1, the node had only
tourism=attraction
andname=Morro da Santa
. I remember its name rendered at the node.Once I added
man_made=cross
, it started to render the cross icon but, on the other hand, its name no longer renders.Now, compare with https://www.openstreetmap.org/node/5185486387 which has
man_made=cross
andname
. Its name is rendered beneath the cross icon. My guess is that, the problem is ontourism=attraction
side.Links and screenshots illustrating the problem
The text was updated successfully, but these errors were encountered: