[gdal-dev] Shapefile with corrupted index: SHAPE_RESTORE_SHX=YES doesn't correctly repairs it.

Jan Heckman jan.heckman at gmail.com
Thu May 18 01:24:05 PDT 2023


Ok, great.
I don't use AutoCad, seems to be a good explanation for the idx, although I
have not found out whether it is
a spatial index or an .shx replacement. See
https://forums.autodesk.com/t5/autocad-map-3d-forum/2018-shape-file-idx-issue/td-p/8300100
discussing (sharing) problems with this .idx file in autocad.
I was at first convinced that some action on the .dbf was the cause of the
problem, anyway, that does not seem
too likely anymore as the dbf rows have an id field and the rows (still)
ordered ascendingly as you would expect.
Therefore the order of the shp and the dbf is likely the same.
Only the last dbf row has damage.
I am a bit unsure whether you have a valid shapefile again/still.
Unless you have a fully recovered/backed up shapefile by now, I suggest you
take a (second) look at the link
<https://www.dropbox.com/s/wj0loe0m7apuszz/test.zip?dl=0> I gave above.
I could repair the last weirdness (lines sticking out westward) and now it
looks ok, and complete.
See https://www.dropbox.com/s/bh6pfvk2haddoqf/result.png?dl=0 for a quick
glance.
In dark the shapefile as it was first shown in QGis, in pink the
(additional) objects that have been recovered.
Best regards,
Jan

On Wed, May 17, 2023 at 4:59 PM Andrea Giudiceandrea via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> 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 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/20230518/f2021b82/attachment.htm>


More information about the gdal-dev mailing list