Skip to content
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

Merged
merged 46 commits into from
Apr 10, 2020

Conversation

jeisenbe
Copy link
Collaborator

@jeisenbe jeisenbe commented Apr 1, 2020

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:

  • Change line rendering for admin boundaries: thinner and more consistent steps in most cases
  • Adds central dark line for admin_level=2,3,4 at mid and high zoom levels
  • Use lower opacity for the admin_level=2,3,4 wide line, but high opacity for thinner, minor boundaries
  • Render admin_level=5 from z8 (3 zoom levels sooner) - makes it possible to add central label
  • Render admin_level=6 from z10 (1 zoom level sooner) - possible to add central text label
  • Render admin_level=7 from z11 (1 zoom level sooner)
  • Render admin_level=10 from z14 (1 zoom level later)
  • Change admin boundaries color to be less saturated - final color selection is still a work in progress, and could be continued in another PR if needed.
  • Remove line-simplification for admin-boundaries lines

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 using comp-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 or place=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
z15-borders-master-test

After z15
z15-borders-test

** Before z13**
z13-border-master-test

After z13
z13-borders-test

** Before z12**
z12-borders-master-test

After z12
z12-test-borders

** Before z10**
z10-borders-master-test

After z10
z10-borderst-test

** Before z8**
z8-borders-master-test

After z8
z8-borders-test

Luxembourg

  • Shows admin_level=2, 6, 8 and 9
    Before z16
    master-borders-luxembourg-z16

After z16
z16-luxembourg-borders-after

** Before z14**
master-borders-luxembourg-z14

After z14
z14-luxembourg-borders-after

** Before z12**
master-borders-luxembourg-z12

After z12
z12-luxembourg-borders-after

** Before z11**
master-borders-luxembourg-z11

After z11
z11-luxembourg-borders-after

** Before z10 **
master-borders-luxembourg-z10

After z10
z10-luxembourg-borders-after

** Before z9**
master-borders-luxembourg-z9

After z9
z9-luxembourg-borders-after

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
@imagico
Copy link
Collaborator

imagico commented Apr 1, 2020

My concerns with this are:

  • reducing opacity of boundary lines will increase color mixing and aggravate problems related to that.
  • adding a centerline purely as an addition without using that to transport semantic information that is not already transported with the base line seems counterproductive.
  • rendering administrative boundaries at earlier zoom levels often negatively affects map readability. For example in your Luxembourg z10 example i think the additional borders are not readable and have a negative effect on the readability of the rest of the map.

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).

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Apr 2, 2020

What background colors will be a problem with the low-saturation hue 327

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.

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Apr 3, 2020

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 text-placements: "S,SE,SW,E,NE,W,NW,N"; is used to try to fit in the admin label.

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.

Yogyakarta

z9
yogyakara-borders-after5-z9

z10
yogyakara-borders-after5-z10

z11
yogyakara-borders-after5-z11

z12
yogyakara-borders-after5-z12

z13
yogyakara-borders-after5-z13

z14
yogyakara-borders-after5-z14

z15
yogyakara-borders-after5-z15

Luxembourg

z10
luxembourg-borders-after-5-z10

z11
luxembourg-borders-after-5-z11

z12
luxembourg-borders-after-5-z12

z13
luxembourg-borders-after-5-z13

z14
luxembourg-borders-after-5-z14

z15
luxembourg-borders-after-5-z15

Wamena

z8
wamena-borders-after5-z8

z9
wamena-borders-after5-z9

z10
wamena-borders-after5-z10

z11
wamena-borders-after5-z11

z12
wamena-borders-after5-z12

z13
wamena-borders-after5-z13

Latvia

z10
latvia-borders-after-5-z10

latvia-borders-after-5-z10b

z11
latvia-borders-after-5-z11

z12
latvia-borders-after-5-z12

latvia-borders-after-5-z12b

z13
latvia-borders-after-5-z13

z15
latvia-borders-after-5-z15

latvia-borders-after-5-z15b

Papua New Guinea

z8
png-borders-after-5-z8

z9
png-borders-after-5-z9

z10
png-borders-after-5-z10

z11a - admin_level=4 in upper right
png-borders-after-5-z11

z11b - admin_level=3 in lower left
png-borders-after-5-z11b

@jeisenbe jeisenbe requested a review from pnorman April 3, 2020 00:47
@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Apr 3, 2020

I'm willing to consider making bigger changes to the admin-boundaries color, but I think that could be the next PR, if this change does not go far enough.

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Apr 3, 2020

Here's the test area again, so you can see all the patterns side-by-side with the final commit:
z10
test-borders-after-5-z10

z13
test-borders-after-5-z13

z15
test-borders-after-5-z15

@pnorman
Copy link
Collaborator

pnorman commented Apr 3, 2020

I'm finding it too hard to see the border at z12
image

@pnorman pnorman dismissed their stale review April 3, 2020 03:51

more changes made

@pnorman pnorman added this to the v5.1 milestone Apr 3, 2020
@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Apr 3, 2020

I'm finding it too hard to see the border at z12

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:

z12 before
yogya-before-z12

z12 after
yogyakara-borders-after5-z12

But it would be possible to increase the width of all the lines by a small amount at z11 to z13, if needed.

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Apr 3, 2020

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:

z14
test-borders-after-6-z14

z13
test-borders-after-6-z13

z12
test-borders-after-6-z12

Luxembourg:

z10
luxembourg-borders-after-6-z11

z11
luxembourg-borders-after-6-z10

z12
luxembourg-borders-after-6-z12

z13
luxembourg-borders-after-6-z13

z14
luxembourg-borders-after-6-z14

@jeisenbe jeisenbe changed the title Rework admin boundaries and show admin_level=5/6/7 sooner, level=9 later Rework admin boundaries and show admin_level=5/6/7 sooner, level=10 later Apr 3, 2020
@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Apr 4, 2020

Rendering administrative boundaries at earlier zoom levels often negatively affects map readability

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?

@pnorman
Copy link
Collaborator

pnorman commented Apr 4, 2020

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.

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Apr 7, 2020

Thank you for testing this PR, @pnorman.

@imagico were your previous concerns addressed?

I'll merge this soon, if there are no objections.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment