[gdal-dev] Invalid node descriptor size in .sbn

[Dennis Gocke]

Hi Even,

Thanks for the quick reply.

regarding the last part:
Here is some pseudo code to illustrate:
I'm normally using the C# wrapper so Failures result in an exception.

When doing the following:
OpenShape()
GetSpatRef()
SetSpatialFilter()
GetNextFeature() -> Exception "Invalid node descriptor size in .sbn"

when doing the same just without GetSpatRef():
OpenShape()
SetSpatialFilter()
GetNextFeature() -> No Exception

This seemed strange to me.

With the increased Maximum value it is probably unlikely that this will
still happen, but should this Problem with the SBN really result in a
Failure or wouldn't be a Warning enough?

Kind regards,
Dennis



On Wed, Feb 12, 2014 at 2:53 PM, Even Rouault
<even.rouault at mines-paris.org>wrote:

> Le mercredi 12 février 2014 13:40:38, Dennis Gocke a écrit :
> > Hi,
> >
> >
> >
> > I found a problem with the shape file driver that occurs when reading
> > features with a spatial filter from a large shapefile that has a spatial
> > index (sbn).
> >
> >
> >
> > The problem can be reproduced with this shapefile
> > http://geofuse.geoeye.com/static/shp/GE1_2012.zip but it's not only this
> > shapefile, I have others that show the problem, all of them are rather
> big.
> > Recalculating the spatial index (with ArcGIS) doesn't solve the problem,
> > the files seem to be valid.
> >
> >
> >
> > When calling CPLGetLastError..() after the first GetNextFeature() a
> failure
> > is returned with the message "Invalid node descriptor size in .sbn :
> > 503800".
> >
> > It seems one could just ignore the Failure and continue reading the
> > features. Everything seems fine (although it probably did not use the
> > spatial index for filtering).
> >
> > Perhaps a Warning instead of a Failure would suffice.
> >
> >
> >
> > The error is generated in sbnsearch.c because "nNodeDescCount>
> nMaxNodes".
> > It seems the maximum tree depth of 15 is not enough.
> >
> > Perhaps the maximum should be increased.
>
> Yes. Fixed by http://trac.osgeo.org/gdal/ticket/5383. The limitation to
> 15 was
> not really justified.
>
> >
> >
> >
> > While testing this I also noticed a strange behavior. Sometimes
> > GetLastError..() returned a failure and sometimes it did not. When not
> > calling layer.GetSpatialRef() before calling GetNextFeature() the first
> > time no failure was returned although it still of course had problems
> > reading the sbn and "hSBN->sHooks.Error( szErrorMsg );" was still called.
>
> Hum not sure to follow you completely. But sometimes the error flag may be
> cleared. The first time you call GetSpatialRef() it reads the .prj file
> and I
> can see that for some reason the routine that does it clears the error
> flag.
>
> >
> >
> > This happens with the current development Version, but is also there in
> the
> > 1.10.0 Version.
> >
> > Best Regards,
> >
> > Dennis
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140212/94aca4d7/attachment.html>