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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
