-
Notifications
You must be signed in to change notification settings - Fork 819
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
Rework admin boundaries and show admin_level=5/6/7 sooner, level=10 later #4100
Conversation
Change admin-boundaries color to #965b95 lch 47-40-327
slightly wider mid and high zoom lines
Adjust state-name and county-name and country-name color too
Adjust admin3/4 dash pattern Simplify admin_level=3 and 4 pattern Adjust admin_level 9 and 10 dash pattern
My concerns with this are:
In terms of design strategy i am also not sure if it is such a good idea to introduce a more sophisticated drawing style composed of several colors first before coming to a decision regarding the boundary color first (#3489). |
Oh, I suppose it is industrial and commercial, since these are close in hue. However, I don't think this will be a problem in practice, and I am avoiding any line patterns that would be easily mistaken for a physical feature or man-made object. |
I think this PR is finally complete. Yogyakarta now looks better with the latest changes, though it will still not have a reasonable rendering at z11 to z12 until the Indonesian community changes the tagging (the admin_level=7 and admin_level=8 areas are much smaller than the median) Now admin5/6 name labels are shown at > 12k way_pixels instead of 3k, and with lower priority than placenames-small. But Now 196,000 way_pixels is set as the minimum for all admin-text (the labels along the lines), to simplify the code and allow this to be set in the conditions in project.mml, and so there would not be too many admin labels on minor admin boundaries. The line widths are also adjusted, to make admin_level=5 a little stronger and admin_level=7/8 thinner, and 9/10 a little thinner, so that it is easier to distinguish between admin5-8. And I reduced the number of dots from 4 to 3 max (for admin_level=8), by using an alternating long-dash/short-dash pattern for admin_level=5 (and admin_level=2), and 1 dot only for admin_level=6. I found that even 4 dots was too much to follow; 1 or 2 dots is best. YogyakartaLuxembourgWamenaLatviaPapua New Guinea |
I'm willing to consider making bigger changes to the |
That's an admin_level=8 boundary, which is first shown at z12, so I've rendered it quite thin at z12, to show admin 5, 6 and 7 more clearly. In most of North America this is not a problem, but in Yogyakarta and other places in the tropic which have all 4 admin levels (5/6/7/8) they can be hard to tell apart at z12 and z13, if they are similar line width: But it would be possible to increase the width of all the lines by a small amount at z11 to z13, if needed. |
I pushed 3 more commits which fixed a few minor problems with the background lines, and made the minor boundary lines wider for admin_level=5-10 at z10-14. Now the admin_level=5 line reaches 2.4 pixels wide at z14, and the narrowest lines are 1.2 pixes (admin_level=10), so most are about 0.4 pixel wider, especially at z12 to z14. I made z14 the last level where there are changes, since all the admin boundaries are shown then and most other linear features. And the width jumps a bit at z12 - it's 0.5 or 0.6 pixels wider than before, since that's when minor roads are first shown, as well as admin_level=8 - and admin8 is now 1.4 pixels wide, instead of only 0.8 which was too thin. I also adjusted the pattern for admin_level=8 to make the dots longer at z12 and z14. Hopefully these changes make the lines more legible. Since the color is less saturated than before, I don't think this rendering is too prominent in areas with landcover mapping, though it will still stand out a little strongly in areas that are only partially mapped - that can't be helped. Test:Luxembourg: |
I'm also willing to consider rendering all of admin_level=5-10 one zoom level later than in this PR, if necessary. That would render admin_level5 at z9 (2 levels sooner), admin_level=6/7 would be unchanged at z11/12, but it would move admin_level-8 to z13, admin_level=9 to z14, and admin_level=10 to z15. This would be beneficial in Java, where admin_level=7 to 10 are all much smaller than the median, but it might not work well at high lattitude is sparsely populated areas, where these admin levels can be quite larg And here in eastern Indonesia, admin_level=5 really should be shown at z8, or the larger areas will already by >192,000 way_pixels at z9 when they are first shown, so the central text lable could never be rendered in an appropriate way. The same issue happens with counties (admin_level=6) in the Western USA, where they are quite large features. So, I would like to see this deployed first, and if there are problems we can adjust the levels again. Or we could test it with the whole planet first. Does anyone have a global rendering server available which could test this branch in production, especially z10 to z14? @rrzefox? |
This is what I've been focusing on when testing. My home server has the planet loaded. |
Fixes:
Part of #4004 potentially
Fixes #310
Fixes #1137
Fixes #3698
Fixes #3971
Mostly Fixes #4016
Partially addresses #3678
Changes proposed in this pull request:
Discussion
The administrative boundaries are challenging, because we should try to distinguish 9 different levels. While admin_level=2 is clearly more significant, and admin_level=3/4 are also different enough from the others to deserve a special rendering, the remaining levels are quite similar, from a global perspective, but each level should be distinguished. Since there are 6 levels, this is quite challenging.
Currently admin_level=5 and 6 have only a slightly different pattern, while admin_level=7/8 are identical, as are admin_levels=9/10, so there are only 7 different patterns in the current style.
In this PR, admin_level=2 has been changed to have a more gradual progression of widths. At z10 and above (where more features began to be rendered), it is wide enough that I've introduced a centerline with long dashes and short dots. This helps make it clear where the geometry is precisely, and makes it harder to confuse these boundaries with roads or other features.
A similar style is used for admin_level=3 from z10 and for admin_level=4 from z12: a dashed wide line with lower opacity and also a dashed and dotted inner line, with higher opacity (and slightly darker). This requires using separate
::narrowline
and::wideline
attachments. Admin_level=2 has 2 dots but is continuous, admin_level=3 has one dot and long dashes, and admin_level=4 has no dots, but shorter dashes.At low zoom levels, I've extended the dashes for admin_level=4 back to z5, so that it's possible to distinguish admin_level=3 and 4 - currently the subtle difference in width alone is not very clear. This also makes the admin_level=4 rendering more consistent. I would also consider showing the dashes at z4, but this needs testing.
These use a separate attachment
::firstline
so they will render behind the more important boundaries, and so they can have a higher opacity tha the wideline but lower opacity than the narrowline. When usingcomp-op: darken
(which we use along with a white background line, so that the different patterns will not overlap), it's not possible to adjust the opacity of each line or feature separately, as far as I can tell, so I've done it in each attachment.I've used a progressive pattern for levels 5 to 8: each is slightly thinner, and has more dots (up to 4) but shorter lines between. This worked out quite well. However, it cannot be extended to admin_level=9 and 10, since 5 dots or more are too hard to count without thinking about it.
Instead, admin_level=9 and 10 have dropped the dash, using a longer gap instead. The are also much thinner than before.
At levels 7 to 10 the 3 and 4 dot patterns have a subtle difference, where two dots are longer and 1 or 2 are shorter - this helps make it easier to distinguish the 3 and 4 dot varients.
These changes make it feasible to render admin_level=5 from z8 and admin_level=6 from z10, while admin_level=7 is also rendered one zoom level sooner. In contrast, admin_level=10 is moved one later to z14. This will fix issues #310 and #3698
Currently this PR includes rendering a central text label for the names of admin_level=5 and =6, as requested in issue #4004 - but this needs further testing for level 6 especially, since often these are municipalities with the same name as the central
place=town
orplace=city
. It may be best to remove this change from the PR, and then add it in a separate PR, but I wanted to include it for testing.I've tested these changes with several different colors of admin-boundaries, but this PR does not include changes to the color, this that would distract from the other changes. However, I will show some examples in the comments, rendered with less saturated purple or less saturated green, to show that these line signatures will work with other colors.
Test renderings
Examples with test data, compared to different landcovers and lines (Railways, paths, etc)
Before z15
After z15
** Before z13**
After z13
** Before z12**
After z12
** Before z10**
After z10
** Before z8**
After z8
Luxembourg
Before z16
After z16
** Before z14**
After z14
** Before z12**
After z12
** Before z11**
After z11
** Before z10 **
After z10
** Before z9**
After z9