[gdal-dev] Fwd: Gdal - multipolygon - geometry errors instead holes

Tobias Wendorff tobias.wendorff at tu-dortmund.de
Tue Oct 29 02:37:19 PDT 2019


No! Please NEVER buffer with 0.

There are tons of tests on the web that proof that this recommendation of 1980ies GIS experts is destroying data.

There are modern feature, like „fix geometries“ in GEOS and others (pprepair).

We really need the web to forget about this recommendation.

— 
Von einem iPhone gesendet und wird daher Fehler enthalten.

> Am 29.10.2019 um 10:18 schrieb Marco <deduikertjes at xs4all.nl>:
> 
> Hi,
> 
> Validity checks don't check the file format. They check the validity of the geometries once they are read from the file into the software.
> 
> The shape file format is a partly documented format. It is very easy to write a shape file which is not according to the specs. To my experience ESRI software will do that every now and again. Very probably you have one of those shape files.
> 
> You might ask the person who created the files to:
> - buffer the geometries with a distance of 0 and the save the resulting file again.
> - and/or export to a different file format (eg geopackage)
> 
> Regards, MArco
> 
>> On 29-10-19 09:19, Casper Børgesen wrote:
>> Hi Pepa
>>  
>> I have tried loading and exporting the multipolygons as WKT using OGR/python and it looks like the holes are interpreted as polygons.
>>  
>> FME displays the data (correctly?) with holes and its validation engine doesn’t find any errors. BUT a year ago I sent a bug report to SAFE because FME did some automatic geometry repair when loading data => the various programs could be fixing issues automatic which means you won’t see them. Not to imply that ESRI does automatic geometry repair in the background, but which program can you definitely trust to correctly represent the contents of your data set?
>>  
>> I tend to trust GDAL/OGR (which means I also trust QGIS) because its open source and the developers are normally pretty good at reporting back how the software treats data.
>>  
>> My reply doesn’t fix your problem though, just a few thoughts from me.
>>  
>> Regards, Casper
>>  
>> From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> On Behalf Of Pepa Beneš
>> Sent: 29. oktober 2019 08:10
>> To: gdal-dev at lists.osgeo.org
>> Subject: [gdal-dev] Fwd: Gdal - multipolygon - geometry errors instead holes
>>  
>> HI, 
>>  
>> I recieved one shapefile. Gdal / Grass / QGIS finds two geometry errors in it. Other GIS SW (ArcMap, MapInfo (via Universal translator or opening shp natively)) theay can't see this geometries as errors. Instead errors they can see regular multipolygons with holes there. Author of this shp wants to see holes there too = in his opinion there are correct data only.   
>> 
>> Please, write me, how to work with such geometries in gdal / grass / QGIS / geos world to see holes too, instead errors?
>> 
>> In geometry_problem.zip there are:
>> 
>> geometry_problem.qgz .. vizualization in QGIS
>> 
>> original.shp .. original data prepared in ESRI
>> original_esri.png .. original.shp seen in ArcMap (With holes. Author of shp wants have holes there.)
>> 
>> original_errors.shp .. geometry errors prepared by "QGIS Desktop 3.8.3 with GRASS 7.6.1"
>> original_qgis.png .. original.shp seen in QGIS
>> 
>> MI/original_to_MI_by_UN.tab .. original.shp translated from shp to tab by MapInfo - UniversalTranslator (tried defferent versions with the same results).
>>  
>> Thanks 
>> Pepa Beneš
>> 
>> 
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20191029/22de7275/attachment.html>


More information about the gdal-dev mailing list