[gdal-dev] Check validity of geometries before writing them into vector tiles?

Even Rouault even.rouault at spatialys.com
Thu Feb 15 09:29:29 PST 2018


On mercredi 14 février 2018 15:53:38 CET Rahkonen Jukka (MML) wrote:
> Even Rouault wrote:
> > Perhaps you could play with the SIMPLIFICATION and SIMPLIFICATION_MAX_ZOOM
> > options ?
> Sure, as I wrote I admit that my test did not make much sense, but trying
> things before reading the manual sometimes reveals something interesting.  
> > Perhaps you should also use an already simplified layer for the lowest
> > zoom level (see the CONF option)
> For sure yes, coordinate space of 4096x4096 is far too small for this
> dataset.
> > Are you sure you get polygons with less than 4 points ? Normally they
> > should be discarded.
> Quite sure yes by looking at what the ST_IsValidReason from the SQLite
> dialect prints  ST_IsValidReason(geometry) (String) = Invalid: Toxic
> Geometry ... too few points
> 
> There are other variants of invalid geometries and actually a few valid as
> well. Here is one example with an invalid component
> 
>   MULTIPOLYGON (((516384 6815744,516384 6815744,532768 6815744,516384
> 6815744)), ((516384 6815744,516384 6815744)),((516384 6815744,516384
> 6815744)))
> 
> My zero tile is here http://www.latuviitta.org/downloads/0.pbf

OK, I reproduced the issue with Jukka's provided input dataset. The issue was that for zoom 
level 0 the maximum tile size limit of 500 KB was reached, and the algorithm that reduces 
coordinate precision in the hope of decreasing the tile size didn't validate geometries as well 
as the normal code path. Now fixed, for most cases. The remaining invalid cases are validity 
issues specifici of multipolygons: each polygon should be valid, but duplicate rings / 
intersecting polygons might still appear. This could proably be fixed by unioning the polygons 
and re-encoding the resulting polygon.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20180215/d008eea1/attachment.html>


More information about the gdal-dev mailing list