<div dir="ltr"><div>Hi Even,</div><div><br></div>C/C++:<div>- lambda can probably be avoided by a (recursive) function and some additional parameter passing.</div><div>- SBNIndex() uses a class internally. Only the function (SBNIndex()) is exported. So I hope to retain this to avoid reprogramming.<br>
<div class="gmail_extra">
- exception(s) can be caught internally.</div><div class="gmail_extra">- I use std::vector which should be ok with VS7.1 (<a href="http://msdn.microsoft.com/en-us/library/9xd04bzs(v=vs.71).aspx" target="_blank">http://msdn.microsoft.com/en-us/library/9xd04bzs(v=vs.71).aspx</a>), gcc 4 (<a href="https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a00739.html" target="_blank">https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a00739.html</a>) and sort(). Vector can be rewritten to dynamic arrays and qsort(), but I don't really want to.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">- 'What do you mean': I meant the .sbn files created by my implementation differ occasionally from the .sbn files Esri produces. Esri integrates bins with few features with bins higher up in the tree, to some degree. The differences I'm talking about are that in some cases features in my index are 'pulled up' somewhat higher than Esri does. I cannot quite infer the rules Esri follows in this. However, since the SBNSearch() routines follow the tree, the features will be found; the consequences for index-efficiency are a little hard to predict. Basically, there is a balance between bins with a few features which may have a larger extent (for the entire bin), vs bins with many features which should have a narrow extent. I expect the efficiency difference to be marginal or unnoticeable.</div>
<div class="gmail_extra">- SBN 2D: As far as I know it's strictly 2D, but I've never found proof of this, have to check Esri SBN index of an ZM shapefile.</div><div class="gmail_extra">- SHPReadObjectExtent() can be done by some easy copying and pasting from SHPReadObject. We/you might consider using the new function in SHPReadObject() for economy, but it would not be a big deal, since this code is unlikely to change.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">So, I can adapt my implementation, retaining C++ internally (class, template, exceptions, std::vector and sort()) and exporting SBNIndex() as a __cdecl/SHPAPI_CALL as if pure C; and implement SHPReadObjectExtent(), for the time being within SBNIndex.cpp.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">SBNIndex() would be called with the shapefilename (with or without extension) and the shapefile would be assumed to be closed; an error when opening the shape for (non-shared) reading would be returned to the caller.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Maybe I should add a searchroutine which just returns the (fid's of) features in a specific bin to facilitate testing.</div><div class="gmail_extra"><br></div>
<div class="gmail_extra">Jan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 18, 2014 at 7:48 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Le mercredi 18 juin 2014 18:44:17, Jan Heckman a écrit :<br>
<div>> Hi all,<br>
><br>
> Starting from <a href="https://github.com/drwelby/hasbeen" target="_blank">https://github.com/drwelby/hasbeen</a> I've implemented an SBN<br>
> shapefile indexing routine in C++. I'm happy, so far, with the results;<br>
> I've used it for a few weeks now.<br>
> With some work it could be integrated into OGR.<br>
> Question is, how much interest, considering pros and cons of my<br>
> implementation?<br>
><br>
> On the plus side:<br>
> - except for occasional differences in the promotion level of lonely<br>
> features (see hasbeen), the results are identical to Esri. Differences do<br>
> not result in any features/shape being 'lost' or invisible. Achieves<br>
> identical results in the 'block_groups' shape example (see also<br>
> spatial_Idx_kit.zip<br>
</div>> <<a href="https://code.google.com/p/pyshp/downloads/detail?name=spatial_idx_kit.zip&" target="_blank">https://code.google.com/p/pyshp/downloads/detail?name=spatial_idx_kit.zip&</a><br>
> can=2&q=>). though.<br>
<div>> - Esri AG can use the indexes, as well as SBNsearch.<br>
> - Fast.<br>
> - produces .sbx on request.<br>
><br>
> On the minus side:<br>
> - uses a lambda function, so limits compilerchoice<br>
<br>
</div>It would be best if we can avoid too fancy C++ features like that one (within<br>
GDAL code, anything more complicated than simple templates is fancy)<br>
<div><br>
> - compiled with VS2013, VS2012 probably is ok, too, no other compilers<br>
> tried, but there's no ms or intel specific or exotic stuff, really.<br>
<br>
</div>We currently support compilers at least down to VC 7.1 (2003) and GCC 4.4.<br>
<div><br>
> - uses exceptions (at least from constructor).<br>
<br>
</div>If exceptions are thrown, they should be caught somewhere within GDAL since it<br>
is callable from C. But ideally the code should go to shapelib which is C<br>
only, although it might be OK to keep C++ and GDAL only<br>
<div><br>
> - uses a simple template (internally).<br>
> - very frustrating I cannot achieve complete identity in spite of some<br>
> (serious) trying.<br>
<br>
</div>What do you mean ?<br>
<div><br>
> - relies now on a tweaked version of SHPReadObject() which avoids reading<br>
> the vertices (just extents and ID).<br>
<br>
</div>We want to keep the signature and behaviour of SHPReadObject() unchanged. So<br>
perhaps add a variant function for your behaviour : SHPReadObjectExtent() ?<br>
(possibly original SHPReadObject() and SHPReadObjectExtent() relying on an<br>
internal unique function)<br>
<div><br>
> - not a single thought about M and Z features (may or may not be relevant).<br>
<br>
</div>SBN indexing is 2D only, or isn't it ?<br>
<div><br>
> - has not been tested exhaustively.<br>
> - have not written a function to maintain an index structure during<br>
> editing. Doing so will certainly require work.<br>
<br>
</div>It might be OK to rebuild completely the index when editing a shapefile.<br>
<div><br>
><br>
> Please let me know whether being able to (SBN)index shapefiles from OGR,<br>
<br>
</div>We might want to have a special SQL syntax to explicitely require .sbn<br>
building. Something like<br>
"CREATE SPATIAL INDEX ON foo ALGORITHM SBN"<br>
<div><div><br>
> even though the resulting indexfiles may differ slightly, is an attractive<br>
> prospect.<br>
><br>
> Jan<br>
<br>
</div></div><span><font color="#888888">--<br>
Geospatial professional services<br>
<a href="http://even.rouault.free.fr/services.html" target="_blank">http://even.rouault.free.fr/services.html</a><br>
</font></span></blockquote></div><br></div></div></div>