Use ST_Boundary for admin-text & protected-areas-text

[jeisenbe]

Related to #3201 - Migration to vector tiles

Changes proposed in this pull request:

• Use ST_Boundary for admin-text & protected-areas-text

This creates a line geometry from the polygon in planet_osm_polygon for rendering the text labels along the boundaries of protected areas and administrative boundary areas.

This is necessary for rendering vector tiles properly

Test rendering is unchanged
(Remember to test with metatile set to 8 in localconfig.json e.g.:

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

Before

After

[imagico]

This is necessary for rendering vector tiles properly

Could you enaborate on that? What software exactly at what point depends on ST_Boundary() for correct labeling?

I am somewhat wary that any software stack that is incapable of properly rendering polygons with an outline (and corresponding outline labels) without manual trickery from the style designer is not ready for production use and should not lead us to adjust to its limitations here.

[jeisenbe]

Vector tiles are kinda dumb: since they are designed to render one (meta)-tile at a time, the data source for each tile is cut off at the edges, so polygons can end up chopped up into 4 pieces if they are at a corner, according to this presentation: https://rory.github.io/sotm-2016-talk-vector-tiles/#/13 - see the next 7 slides, including this solution in slide 20

This is the same reason we've switched to ST_PointOnSurface for text labels that should be near the center of a polygon.

In this case, admin-text and protected-areas-text render text labels along the administrative boundary or protected area boundary (national parks, nature reserves), so we want a line instead of a point. (Explanation for those following along)

[imagico]

My question was not why there are additional technical difficulties for software developers when rendering tiled polygon data, i am interested in the specific software stacks that requires manual trickery like this to be able to correctly label polygon outlines.

When you say

Vector tiles are kinda dumb

That is not true - the software products you want to generate and interpret vector tiles with might be kinda dumb and i wanted to know which products those are to assess if it actually makes sense for us to invest work in working around those limitations.

Right now the most serious limitations we have in terms of style design are the limitations imposed by the software we use. It seems natural to me that based on that experience we take a critical look at what kind of limitations might be imposed by software we might move to in the future.

This is the same reason we've switched to ST_PointOnSurface

No, this is a choice that has been discussed at length in the past and which is not tied to a specific design limitation of certain software products but is based on the fundamental difficulty to make good labeling decisions from local information only.

[jeisenbe]

I don't know. However, I'm basing this off of the email from @pnorman which I recently paraphrased in #3201 (comment):

"SOTM was this weekend, and attending were several people involved in
osm-carto and tiled maps: Andy, Christoph, Matthijs, Rory, and myself.
...
"Our discussions were focused on getting to the first step of server-
side vector tiles.

The following was the plan that emerged from my conversations with
everyone, with some details added and steps that we missed added:

1. Identify a vector tile generator

The options can be divided into ST_AsMVT based or not. I prefer
ST_AsMVT, because it avoids a single-company maintainer of the
complicated part of vector tile generation.

PosTile is the leading candidate here, as it supports .tm2source files

2. Identify a vector to raster tile server

Tessera should work. All options are painful because they involve node-
mapnik."

3. Complete ... ST_PointOnSurface move ...

4. Use ST_Border to filter admin geoms

See https://rory.github.io/sotm-2016-talk-vector-tiles/#/20 for
rationale, but this will cut down on the data being passed to mapnik"

I don't know anything about the software option mentioned above, yet.

I had assumed that the move to server-side vector tiles had been discussed and planned by the other maintainers before I was involved.

[imagico]

I had assumed that the move to server-side vector tiles had been discussed and planned by the other maintainers before I was involved.

No, so far there has been no discussion that led to any kind of (even preliminary) decision on concrete software use yet. And the outline sent by @pnorman placed the decision on vector tile generator and renderer before the coding related things - for good reason IMO.

Any larger technical changes that are made exclusively to facilitate use of this style on a different software stack should IMO be done after forking. Any changes that actually benefit current development can and should of course be made now.

Note of course this specific change is not a big deal and i would not mind merging it - my concerns are more of principal nature - not to cargo cult a lot of changes based on what someone has indicated at some point but without a thorough understanding of the need for it.

[jeisenbe]

It appears this PR is not needed until a fork to a new vector-based style, so I will close it

[gravitystorm]

I am somewhat wary that any software stack that is incapable of properly rendering polygons with an outline (and corresponding outline labels) without manual trickery from the style designer is not ready for production use and should not lead us to adjust to its limitations here.

I wouldn't call it manual trickery, so much as working within the limitations of vector tiles.

The problem here is the offset labels rather than the polygon outline. Since the vector tile contains clipped polygons, there are additional (false) edges to the polygons. These are normally offscreen by a few pixels (depending on the buffer size) so don't usually cause problems with outlines, but an offset label can easily appear within the main draw area, unless the text size plus offset is smaller than the buffer.

(In these illustrations, the main draw area is the solid gray square, and the buffer indicated by dashed lines. The green feature has been clipped to the buffer as a necessary part of the conversion to vector tiles).

You can see that, depending on the buffer width and text size, bits of the text can appear in the draw area, like the tops of the T's in the example.

Rather than having to have enormous buffers (to give full flexibility to the style designer, who might want e.g. 20px text with 20px offset) an alternative is to convert the polygon into a line, with st_boundary. That way when the line is clipped, there are no 'false' labels lurking in the buffer zone.

Of course the same problem occurs with polygon outlines, where the size of the buffer restricts the maximum width of the outline. But in most situations a buffer of roughly 8 pixels (giving a maximum outline with of 15 pixels) is plenty since super-fat polygon outlines are rare in most styles. Offset text is harder to deal with, without incurring a major bloat in buffer sizes.

[imagico]

I understand the technical problem but i consider this to be specific to software products currently on the market. This is not a hard technical reason why a vector tile based renderer could not - when rendering clipped polygon outlines or outline labels - refrain from rendering the artificial clipped parts of the outline that align with the buffer edge - either by evaluating this alignment during the rendering step or by generating and including this information when generating the vector tiles. Current vector tiles generating/rendering software might not be able to do that but it could.

The real issue is something different:: You cannot generate consistent line labeling (or also line dashing) from clipped geometries without storing a phase/start length parameter on every clipped line that is used for adjusting the rendering. From what i see in various vector tile based maps this problem is not usually addressed - see for example:

https://www.openstreetmap.org/#map=14/48.0476/7.5927&layers=C
https://c.tile.thunderforest.com/cycle/14/8537/5691.png
https://a.tile.thunderforest.com/cycle/14/8537/5692.png

See also:

mapbox/mapbox-gl-js#5395

Now solving that seems a prerequisite for any mature rendering framework capable of generating high quality maps and doing so equally for lines and polygon outlines seems only a minor additional difficulty.

I understand that existing frameworks probably do not meet this perfectionist requirement and i am fine with that. But as said i think if the decision is made to go with a framework with certain limitations and workarounds on the style development level are necessary to deal with that this is a choice to be made after selecting the specific software and in a fork made specifically for that and not preemptively in anticipation of such choice.

[gravitystorm]

Current vector tiles generating/rendering software might not be able to do that but it could.

Sure, in theory, anything is possible - in theory!

But waiting for options than MVT (or new versions of the MVT spec with cross-tile line-dash offset consistency information, or per-edge polygon attribute information) might involve a substantial wait.

While the rendering software and vector tile creation software are both open questions, I think the vector tile format, and the limitations inherent in that format, are realistically a foregone conclusion.

[imagico]

While the rendering software and vector tile creation software are both open questions, I think the vector tile format, and the limitations inherent in that format, are realistically a foregone conclusion.

Quite possible - i lack the in depth knowledge of the software market here to assess that.

To be clear: The reason for my comments here is not to push into a certain direction, it is to urge us to make conscious choices and not make step-by-step non-committing choices over time to then in the end declare the committing choices 'alternativlos'.

Ultimately someone or some group of people needs to step up and say: We want to concretely start a fork of this project for rendering maps based on a vector tiles process. We pursue the following goals with it and for that we choose the following software stack. If such a step is supported by making changes like this that might be pointless for this project as is but that would minimize code differences and thereby simplify and support kicking off such a project i would be for it. But it should be clear that this is not a replacement for someone stepping up and investing time and thought into this, in particular also the non-technical aspects of it.