refactor and fix amenity-points #1093
Conversation
fixes #870, fixes #959 script used to find bad text-dy is available at https://gist.github.com/mkoniecz/9451a41ec0ae38b23b54 the proper way to test it is using mapnik-legendary, but it depends on currently broken Ruby-Mapnik
|
there is also small text-dy fix in roads.mss Maybe I will have time to add more #710 related commits into this PR (text-wrap-width would be the next issue). |
| @@ -1153,6 +1160,7 @@ | |||
| [way_pixels > 12000] { text-size: @landcover-font-size-big; } | |||
| [way_pixels > 48000] { text-size: @landcover-font-size-bigger; } | |||
| text-fill: darken(@campsite, 50%); | |||
| text-dy: 15; | |||
There was a problem hiding this comment.
Is this also sufficient for the larger font sizes?
There was a problem hiding this comment.
Probably no, my script was checking only for rendering of nodes. I am planning on making next one that will be able to do the same with areas.
|
Out of curiosity, which method did you use to calculate the text-dy? |
I used hackish script (linked in the commit description) to check whatever name appears. On object where name "a" appeared and name "ÉÉÉÉÉÉ" was not appearing I manually increased text-dy by one and repeated it till also "ÉÉÉÉÉÉ" appeared. Main improvement is that I automated reporting of the problem that was affecting most POIs. |
|
I added commit setting standard wrap-width - in some cases it was previously not set, or was really small (for shops it caused wrapping for names like "Pasaż 13"[1], or was really big). [1] http://www.openstreetmap.org/?mlat=50.06048&mlon=19.93801#map=19/50.06048/19.93801 In dense areas really long lines were easier to display than better looking blocks of text so some labels disappeared. http://www.openstreetmap.org/#map=18/50.06218/19.93544
|
|
NOTE: removed from this PR as for for some reason some people are convinced that bays should be tagged as nodes. Now natural=bay label also depends on way_area like other waterbody labels what fixes problem with labels for big and really small bays appearing at the same time. This change should encourage mappers to map bays, rather than placing natural=bay nodes where they want label to be rendered - as natural=bay nodes will appear at z17 rather than as it is currently on z14. Also, code duplication is now reduced. http://www.openstreetmap.org/#map=14/60.1678/5.0645
|
|
I am not planning on making additional changes in this PR, I will make next PR related to #710 after this PR is merged/rejected. |
|
I have tested this PR, and I think it can be merged. |
|
It is, didn't notice it was in the commit message already. |
|
Note starting to render node based natural=bay not earlier than z=17 essentially means ceasing to render them since bays are typically in the km to hundred km size range. This would mean removing support for more than 30000 features currently rendered. I don't want to repeat arguments from the discussion on the tagging ML here but this is clearly not an improvement for the map and has nothing to do with the fix this pull request is about. The distance of the node to the coastline would be a perfectly good indicator for the size of the bay - and much less prone to manipulation than the polygon area since you cannot manipulate it without also moving the label. Of course the coastline is currently not available in the database but this is not a good reason to pressure mappers to generate polygons for >30000 nodes. |
|
As this PR was supposed to be about obvious and completely uncontroversial changes I will remove the natural=bay commit. |
|
Thanks, much appreciated. In principle i see nothing wrong with showing the large bays mapped as polygons at z<14. This would be an improvement for the map although i personally would dislike the side effect of encouraging mappers to map large bays as areas. |
refactor and fix amenity-points
next part of #710
This is proposed as single pull request to prevent merge conflicts, other alternative was to make single PR after every merge cycle what would slow down fixing #710 what blocks changes like #1040 and #1041.
Resolves #870, resolves #959.