[gdal-dev] SBN shapefile indexing

[Even Rouault]

Le mercredi 18 juin 2014 18:44:17, Jan Heckman a écrit :
> Hi all,
> 
> Starting from https://github.com/drwelby/hasbeen I've implemented an SBN
> shapefile indexing routine in C++. I'm happy, so far, with the results;
> I've used it for a few weeks now.
> With some work it could be integrated into OGR.
> Question is, how much interest, considering pros and cons of my
> implementation?
> 
> On the plus side:
> - except for occasional differences in the promotion level of lonely
> features (see hasbeen), the results are identical to Esri. Differences do
> not result in any features/shape being 'lost' or invisible. Achieves
> identical results in the 'block_groups' shape example (see also
> spatial_Idx_kit.zip
> <https://code.google.com/p/pyshp/downloads/detail?name=spatial_idx_kit.zip&
> can=2&q=>). though.
> - Esri AG can use the indexes, as well as SBNsearch.
> - Fast.
> - produces .sbx on request.
> 
> On the minus side:
> - uses a lambda function, so limits compilerchoice

It would be best if we can avoid too fancy C++ features like that one (within 
GDAL code, anything more complicated than simple templates is fancy)

> - compiled with VS2013, VS2012 probably is ok, too, no other compilers
> tried, but there's no ms or intel specific or exotic stuff, really.

We currently support compilers at least down to VC 7.1 (2003) and GCC 4.4.

> - uses exceptions (at least from constructor).

If exceptions are thrown, they should be caught somewhere within GDAL since it 
is callable from C. But ideally the code should go to shapelib which is C 
only, although it might be OK to keep C++ and GDAL only

> - uses a simple template (internally).
> - very frustrating I cannot achieve complete identity in spite of some
> (serious) trying.

What do you mean ?

> - relies now on a tweaked version of SHPReadObject() which avoids reading
> the vertices (just extents and ID).

We want to keep the signature and behaviour of SHPReadObject() unchanged. So 
perhaps add a variant function for your behaviour : SHPReadObjectExtent() ? 
(possibly original SHPReadObject() and SHPReadObjectExtent() relying on an 
internal unique function)

> - not a single thought about M and Z features (may or may not be relevant).

SBN indexing is 2D only, or isn't it ?

> - has not been tested exhaustively.
> - have not written a function to maintain an index structure during
> editing. Doing so will certainly require work.

It might be OK to rebuild completely the index when editing a shapefile.

> 
> Please let me know whether being able to (SBN)index shapefiles from OGR,

We might want to have a special SQL syntax to explicitely require .sbn 
building. Something like
"CREATE SPATIAL INDEX ON foo ALGORITHM SBN"

> even though the resulting indexfiles may differ slightly, is an attractive
> prospect.
> 
> Jan

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html