Hi Jan,
thank you very much for looking at this issue.
I had already managed to restore the .shx index file, as reported in my
first message [1] [2] by fixing the GDAL/OGR SHPRestoreSHX routine [3].
Even Rouault also further improved it adding extra sanity checks, a
better logic and better error messages [4].
Obviously, SHPRestoreSHX routing doesn't take care of the the mismatch
between the shape and dbf records number.
An old but still working Shapefile recovery tool (which also handle the
shp / dbf mismatch) is the "Shape Checker" [5].
The .idx file may have been created by AutoCAD [6], as the user reported
that he tried to open the corrupted Shapefile layer with AutoCAD after
the corruption occurred.
Best regards.
Andrea
[1] https://lists.osgeo.org/pipermail/gdal-dev/2023-May/057229.html
[2] https://github.com/qgis/QGIS/issues/53058#issuecomment-1547740971
[3] https://github.com/OSGeo/gdal/pull/7774
[4] https://github.com/OSGeo/gdal/pull/7778
[5]
https://web.archive.org/web/20091024035556/http://geocities.com/SiliconValley/Haven/2295/howto_shapechk.html
[6]
https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/Required-files-that-make-up-a-shapefile.html
Il 17/05/2023 12:39, Jan Heckman ha scritto:
Hi all,
As noted in the QGis issues <https://github.com/qgis/QGIS/issues/53058>,
the shx has problems that ogr2ogr (or QGis Repair Shapefile) will not fix;
The error I get in cmdline with SHAPE_RESTORE_SHX=YES is "ERROR 4: Error
parsing .shp to restore .shx".
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
