[geos-devel] use of STRtree functions in C API

[Howard Butler]

On May 4, 2010, at 10:54 AM, Martin Davis wrote:
> Sure, why not?  At least for in-memory indexes - there are no plans to extend this to disk-based indexes.
> 
> Reasons are:
> i) The code is there and well-tested
> ii) The index is designed to work well with GEOS objects (although as you point out, indexes are fairly independent)
> iii) This reduces the need for dependencies on other librarries (as I think you have just recommended)
> 

Reasons against:
i) Why not the quadtree or interval tree too?  
ii) Once it's in the C API, we can't take it back, and I think the design is wrong (why not GEOSIndex instead of GEOSSTRtree, etc)
iii) I was arguing that each library should focus on what it does best.  GDAL's approach of embedding just about every library it uses that doesn't have licensing restrictions preventing it has been extremely limiting.


> Of course as you say this exposes an interface which will need to be maintained in the future.  But there's a fairly low cost to maintaining the simple indexes currently provided (and there are no current plans to stop using them in GEOS itself).

It doesn't matter at this point, I guess.  We can't remove it from the C API or we will break ABI compatibility, which was the whole point of the C API in the first place.  But we should be a bit more careful about adding stuff to the C API because a) people will want to use it b) once it's there we can't practically change it and c) it will never be removed.

> PreparedGeometry optimizes the computation between two individual geometries, but it doesn't optimize the situation of processing two sets of geometries in pairwise fashion.  For that you need a spatial index.

Thanks for the description.  For some reason I thought they could do set operations.