Openstreetmap-carto: Administrative boundary text labels are displayed inconsistently

[jeisenbe]

Expected behavior

• Administrative boundary text labels should repeat along the border a couple of times per screen, in a regular fashion, similar to the behavior of labels on waterways and roads
• Text labels should not be displayed twice in row
• There should not be any gaps bigger than 1000 pixels between repeated labels

Actual behavior

• Boundary text labels are often displayed several times in succession
• The spacing does not seem consistent
• Sometimes there labels are more than 1600 pixels apart, even in areas with no other objects mapped

Likely cause and solution

• the code in admin.mss does not contain text-spacing: or text-repeat-distance: as used for roads and waterways. Adding these missing properties should improve the rendering
• (The lack of labels is not always apparent when test rendering in Kosmtik, because the meta tiles are 512 x 512 pixels and the labels are shown once per metatile. However the meta-tiles on the openstreetmap.org servers are much larger. Test renderings do show the repeated adjacent labels however, if they fit in the metatile.)

Links and screenshots illustrating the problem

Near Wamena, Papua, Indonesia (_Screenshots_)
https://www.openstreetmap.org/#map=17/-4.07715/138.97202

https://www.openstreetmap.org/#map=17/-4.08183/138.95416

Damhead Railway, Northern Ireland (_Screenshot from openstreetmap.org)
https://www.openstreetmap.org/#map=17/55.11269/-6.59828

Canberra, Australia (_Exported from Kosmtik_):

[jeisenbe]

Also, when two admin levels share the same way, the names are often too close together. This can be confusing when one of the admin levels has a multi-word name, eg Jayawijaya (admin_level 5) & Aso Tipo (admin_level 6) (screenshot from kosmtik):
https://www.openstreetmap.org/#map=16/-4.2006/139.0261

[jeisenbe]

The french style has a well-developed rendering for administrative boundaries which addresses most of these issues, and also displays province and national borders sooner:

  [zoom>=11][admin_level<=6],
  [zoom>=13][admin_level<=8],
  [zoom>=15]  /* limites administratives locales (élément de relation) */
  {
...
    text-name: [name];
    text-fill: @admin-boundaries;
    text-size: 10;
    text-placement: line;
    text-face-name: @oblique-fonts;
    text-halo-radius: 1.5;
    text-halo-fill: fadeout(white, 30%);
    text-max-char-angle-delta: 15;
    text-dy: 4;
    text-spacing: 750;
  }

It would be a good idea to try text-spacing: 750; and text-max-char-angle-delta: 15;, in addition to text-repeat-distance and text-margin.

Normally text-margin could reduce the number of nearby features that could be placed on the map, but since admin-text and nature-reserve-text are the last two layers (except for low priority amenities), there is no harm in increasing the text-margin to provide some white space between adjacent text labels (for example, when there are multiple admin_levels sharing the same way)

I'm also interested in testing display of the text border labels at earlier zoom levels. The French example seems to be fine-tuned for French admin levels, but I believe text labels could be shown for admin_level=4 at >= z12 or z13, and admin_level=6 at z14 or z15.

[jeisenbe]

OK, I spent most of yesterday feeling frustrate that text-spacing: 750 was not rendering the labels less often than about every 300 to 500 pixels in my test renderings (kosmtik with docker). And my test images with the current master branch were not the same as screenshots from openstreetmap.org

I finally realized that the metatile size is 512 by 512 pixels when testing, but the servers at openstreetmap.org use a much larger metatile size. The labels are repeating every metatile, even without text-spacing, and it appears that text-spacing does not work correctly across metatile borders.

Does anyone know the tile size used for openstreetmap.org? @pnorman?

This wiki page, which may be outdated, suggests 2048 x 2048 pixels, which would probably lead to one border label every 1600 to 2200 pixels (depending on the orientation of the border) on average https://wiki.openstreetmap.org/wiki/Meta_tiles

How can I change the settings on my test server to match this metatile size?

Edited: I figured out one option. Changing metatile: 2 to metatile: 8 matches the rendering. Probably this can be done with a localconfig.js file?

EG:
z16 three-way border between Morobe, Madang and Eastern Highlands provinces in Papua New Guinea: https://www.openstreetmap.org/#map=16/-5.9977/145.8634

Kosmtik rendering with 512px meta-tiles (master branch):

• The extra lines are the meta-tile borders
  

Kosmtik rendering with proposed changes (text-spacing: 750; text-repeat-distance: 200; text-margin: 10;

Screenshots from openstreetmap.org (with much larger meta-tiles)

• The labels are very far apart here, with almost no other labels or icons in sight
  South
  
  East
  
  West
  

[Adamant36]

Hhmm really interesting. I always thought Kosmtik looked a little off. I always thought it was a slight difference in how zoomed in things are at a particular zoom level. Its possible the tiles are slightly stretched though.

[jeisenbe]

Here's what it looks like when I set metatile: 8 and render the current master, with my browser (safari) set to 50%. My monitor is only 1280 x 800, but this represents a low-resolution view of almost 2560 x 1600:

Current rendering:

After text-spacing: 750 and text-margin: 10

I wonder if it's worth changing metatile: 2 to metatile: 8 or at least 4, so that our test renderings more closely match the live rendering on openstreetmap.org

[jeisenbe]

Those renderings at 50% (zoomed out) look odd because my browser did not do
a good job at the edges between tiles
On Sun, Jan 20, 2019 at 12:05 PM Adamant36 [e-mail] wrote:

Hhmm really interesting. I always thought Kosmtik looked a little off. I
always thought it was a slight difference in how zoomed in things are at a
particular zoom level. Its possible the tiles are slightly stretched though.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/3649#issuecomment-455833581,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoxshOHIRPWH07ZLTxM6dQaZpmxps09nks5vE9zkgaJpZM4aH8NX
.

[vholten]

Code to change metatile size in localconfig.json:

[
  {
    "where": "metatile",
    "then": 8
  }
]

[jeisenbe]

Code to change metatile size in localconfig.json:

Thank you, that will be easier to maintain.
On Sun, Jan 20, 2019 at 9:53 PM vholten [e-mail] wrote:

Code to change metatile size in localconfig.json:

[
{
"where": "metatile",
"then": 8
}
]

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/3649#issuecomment-455864115,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoxshBy-nn1PZ7pFo8iRS9V_wcZ2WZ4Mks5vFGa9gaJpZM4aH8NX
.

[jeisenbe]

I believe I understand why the border labels are repeated several times in a row in some cases. It seems to be a Mapnik bug related to polygons and metatiles.

This happens where a small segment of border crosses into and then back out of the metatile, so there are two different sections of the border in the same metatile, but they are disconnected. Mapnik appears to use the entire length of border in the metatile to calculated how many labels should be placed. So if the spacing is set at 750 pixels and the total length of border in the metatile is 2500 pixels, then it attempts to place 3 text labels along the border. But it only attempts to place them along one of the segments. Often this is the shorter segment rather than the longer, which can lead to 3 or 4 labels in a row.

It is difficult to show examples, since you need to see the whole 2048 x 2048 pixel metatile to understand, but here is a screenshots of the results, with the metatile bounds shown:

https://www.openstreetmap.org/#map=17/-4.08183/138.95416

If you try rendering this with metatile: 8 and the current master branch you should be able to see how the admin_level=6 border of "Wamena" crosses out of and back into the metatile. Similar problems can be seen in nearby metatiles and at other zoom levels, especially z17.

Is this something that could be fixed in Mapnik?

[kocio-pl]

Is this something that could be fixed in Mapnik?

@talaj What do you think of that?

[talaj]

This seems like a bug with text-clip: true. Do you really need to clip the geometry? Labeling on clipped geometries is causing nondeterministic label placement across metatiles and cropped labels.

[jeisenbe]

This seems like a bug with text-clip: true;

Thank you, I will test changing this!

However, I am concerned that rendering performance could be worse if
geometries are not clipped. @pnorman ?

[jeisenbe]

As suggested, text-clip: false fixes the problem of multiple copies of a text label rendering along one line segment. With the addition of text-spacing: 750 and text-margin: 10 the rendering is quite good:

I didn't notice a significant change in performance, but I don't know how to test this.

[jeisenbe]

3652 has been merged, fixing most of the problems reported in this issue. However, since we couldn't yet use text-clip: true, due to slower performance, we need to wait till Mapnik is improved to better handle large geometries.

[pnorman]

However, I am concerned that rendering performance could be worse if geometries are not clipped. @pnorman ?

We've turned off clip in the past for lots of stuff. We need it for anything with dashes. Do we know it won't work on text from boundary polygons?

[jeisenbe]

We’ve turned off clip in the past for lots of stuff. We
need it for anything with dashes. Do we know it won't work on text from
boundary polygons?

This was tested in PR #3652 - see this comment
https://www.github.com/gravitystorm/openstreetmap-carto/pull/3652#issuecomment-457586484

It was 2 to 10 seconds slower per metatile to render areas near very long
borders (eg Poland admin_level=2), at least on my laptop. Smaller borders
were only a second slower.

Then @talaj said that he had a way to optimize text rendering on huge
geometries, so hopefully this will be improved in Mapnik.