[postgis-devel] ST_AsMVTGeom() feature size limit

[Marco Boeringa]

I think this is a much more generic issue with any generalization vector 
algorithm relying on crude minimum area filtering as part of its toolchain.

You see the effect in most current vector tile services, where e.g. a 
highly forested country like Slovenia, is often displayed without 
woodland polygons at low or medium zoom scales, despite the forest 
coverage of the country likely being over 50% or more. Only when you 
zoom in, do the forest patches pop-up in view. This is a consequence of 
the highly detailed digitization of the forest polygons in Slovenia, 
with many small patches as well, and a rather generic minimum area 
filtering.

Most current approaches to solve this issue either rely on external 
sources like Natural Earth for low zoom scale, with both hand drawn or 
satellite derived low zoom data, or to process the vector data by 
rasterizing it, and using raster processing algorithms to simplify and 
generalize the data, subsequently converting it back to vector.

However, what is actually required to tackle such issues in a pure 
vector based approach, is a process to dissolve records. However, that 
has its own major issues and isn't straight forward as well with 
OpenStreetMap data as a basis.

E.g. here in The Netherlands, many large forest areas are cut up in very 
small (0.1 - 4 hectare) forest patches, that are actually physically 
separated by a tiny gap where forest tracks and paths run through the 
forest. This means that a dissolve process alone will fail to merge the 
polygons, as they are not topologically connected. It requires a buffer 
step to merge them.

Dissolving often works better for urban landuse areas, as at least tiny 
"landuse=residential" areas representing single house plots - often 
detailed governmental data being added in some countries or specific 
cities - usually are topologically connected, and can be successfully 
dissolved.

In order to solve the "woodland problem", I personally spend a very 
significant amount of time and effort, to develop a new completely 
vector based approach involving a complex hybrid toolchain of PostGIS 
and ArcGIS geoprocessing tools, that involves a buffer & dissolve step 
and multi-stage minimum area filtering and generalization. I showed some 
of this in the 'openstreetmap-carto' repository, with some screenshots 
of the resulting "woodland" polygons as well:

https://github.com/gravitystorm/openstreetmap-carto/issues/4110

This toolchain actually manages to cut down > 12M "forest polygons" for 
the entire globe, to just over 1000 for "Z0" type rendering. More than 6 
GB of complex polygon data, is in the process reduced to less than 3,5 
MB, while retaining what I believe is a pretty acceptable result.

This approach has its own limitations though. It works only well for the 
kind of data represented by forests or glaciers: data displayed largely 
on its own on the lower zoom level scales, like Z0-Z11. You can't use it 
to generalize dozens of landuse types for midzoom scale display, as the 
buffering approach would cause issues with overlaps between landuses 
(although simply dissolving without buffering will work for mid zoom 
scale display and still significantly reduce the total number of 
features...).

In addition, needless to say, the processing involved and the total 
processing time needed for a toolchain like this, is very significant, 
think a few days on slightly outdated, but professional workstation 
level hardware. It it therefor best suited for "batch" type occasional 
updating, not a continuously updated map, like most modern map systems 
try to achieve.

Marco

Op 19-5-2021 om 00:31 schreef Paul Ramsey:
> I was interested to find that ST_AsMVTGeom drops features that fall below 1/2 a pixel in size.
>
> postgis30=# select st_astext(st_asmvtgeom('LINESTRING(10 10, 11 10)', 'LINESTRING(0 0, 16384 16384)'::geometry));
>   st_astext
> -----------
>   
> (1 row)
>
> There's no configuration option to avoid this behaviour, and if you map a large enough area that your feature size falls below a pixel you end up with big blanks in your map. Have there been no complaints about this before?
>
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel