Switch to ST_PointOnSurface?

[pnorman]

In vector tiles, polygons cannot be used for labeling, as polygons are clipped to the vector tile bounds.

This is a particular problem for non-PostGIS datasources, but for PostGIS ones, the standard solution is to use ST_PointOnSurface. #349 found that it was not really better or worse than Mapnik label placement.

#349 (comment) raised the possibility of performance concerns. I am not sure, but there are a couple of ways this can be addressed

1. Appropriate use of !bbox!. (SELECT ST_PointOnSurface(way) AS way FROM planet_osm_polygon) AS p does not work because the geometry filtering condition used is ST_PointOnSurface(way) && !bbox!.

   The appropriate way to write the query is

   (SELECT
   ST_PointOnSurface(way)
   FROM planet_osm_polygon
   WHERE way && !bbox!
     AND name IS NOT NULL
   ) AS p

   This will then use indexes to limit the data fetched, with a second filtering taking place in the outer select added by Mapnik. A functional index on ST_PointOnSurface(way) WHERE name IS NOT NULL could also help.

   I don't know if @mrwojo did this when testing. If not, it could easily explain any performance differences.

2. Where this is both a point and a polygon layer, these can be combined into one query with UNION ALL

[imagico]

Note resorting to ST_PointOnSurface() to accommodate vector tiles workflows would codify the current bad quality label placement even if mapnik should in the future allow better quality - you would be limited in possible improvements to such offered by the database engine which are unlikely to be within its scope. Ultimately good quality labeling is simply diametrical to the idea of a strictly tiled approach to rendering.

[pnorman]

I'm reopening this since a few things have changed and we should look at the decision in light of them

• We're finding more cases where Mapnik's label placement results in strange incorrect results (water label placement offset #1465 and connected tickets)
• Invalid geometries should be gone with osm2pgsql versions from the last few years
• Combining the point and polygon queries into one layer is a step that forks want to take (e.g. @rorym's work)
• Doing polygon to point conversion in SQL allows for different placement methods in the future (e.g. PIA)

[imagico]

The argument in #1644 (comment) still applies i think but this is based on the assumption that Mapnik would eventually offer more sophisticated label placement - which is unlikely given that Mapnik is essentially a dead horse.

The idea that you could generate points from polygons from within SQL that are universally significantly better for labeling is probably not realistic though - this too much depends on font size, actual label text, surrounding labels and other stuff.

[pnorman]

The idea that you could generate points from polygons from within SQL that are universally significantly better for labeling is probably not realistic though - this too much depends on font size, actual label text, surrounding labels and other stuff.

Both Mapnik and ST_PointOnSurface just generate a point and place the label. If at some point there were an option that considered label size and surroundings, we could look at it, but for now, that doesn't matter.

[imagico]

Well - i guess my main point here is that ultimately ST_PointOnSurface() is going to be a dead end regarding quality label placement but Mapnik likely is as well so it really does not matter.

[kocio-pl]

There are more ideas to improve Mapnik algorithm:

mapnik/mapnik#3550 (comment)

The question is if someone will try to code a better solution and which one is acceptable regarding speed and complexity.

[matthijsmelissen]

I added this issue to the vector tiles project.

[jeisenbe]

PRs #3233, #3690, #3712, #3781, and #3874 have switched the layers springs, stations, amenity=points, buildings, and amenity-low-priority to use ST_PointOnSurface.

But it was noted that addr:housenumber now displays at a different location than building names in #962 (comment)

It looks like the addresses layer should also be switched. Are there other layers that should still be changed, or will this issue then be closed?

[jeisenbe]

I believe all relevant layers have been switched to ST_PointOnSurface, so this issue is resolved.