Tobias,
Buffer 0 (by the creator of the dataset) is there to prevent that VALID
geometries being written to the shapefile in an INVALID way.
Buffer 0 on VALID geometries should IMHO never lead to data loss.
Buffer 0 on INVALID geometries IMHO can lead to good results depending
on the nature of the invalidity. To my experience repeating points,
wrong coordinate ordering and holes touching outer shells in one point
are being repaired well without data loss.
Please enlighten me with a few links to the tons of tests on the web
showing that buffer 0 is destroying data. My Google skills are not up to it.
Regards, Marco
On 29-10-19 10:37, Tobias Wendorff wrote:
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 <[email protected]
<mailto:[email protected]>>:
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 <[email protected]> *On Behalf Of
*Pepa Beneš
*Sent:* 29. oktober 2019 08:10
*To:* [email protected]
*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
<https://drive.google.com/file/d/1oRJQVKYDkZji-GLmobov995m9vF00vwf>
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
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
