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 - compiled with VS2013, VS2012 probably is ok, too, no other compilers tried, but there's no ms or intel specific or exotic stuff, really. - uses exceptions (at least from constructor). - uses a simple template (internally). - very frustrating I cannot achieve complete identity in spite of some (serious) trying. - relies now on a tweaked version of SHPReadObject() which avoids reading the vertices (just extents and ID). - not a single thought about M and Z features (may or may not be relevant). - has not been tested exhaustively. - have not written a function to maintain an index structure during editing. Doing so will certainly require work. Please let me know whether being able to (SBN)index shapefiles from OGR, even though the resulting indexfiles may differ slightly, is an attractive prospect. Jan
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
