[gdal-dev] Layer operations, a proposal

[Even Rouault]

Selon Tyler Mitchell <Tyler.Mitchell at actian.com>:

>
>
> Jason Roberts wrote:
> ...
> > For scenarios involving large numbers of features, I suspect it is much
> > harder to do it fast and within available memory. It is probably necessary
> > to do a multi-pass approach, where the first step operates only on the
> > spatial indexes of the layers involved. It is probably too slow--or at
> least
> > very suboptimal--to even read all of the features into memory, much less
> > call GEOS on them; all of that would happen in a later pass, when a subset
> > of features was identified via the spatial index pass....
>
> I was intrigued to read the earlier thread you pointed out Jason, and to see
> also
> Jan's comment about spatial index handling.  I would really love to see a
> common
> approach to adding spatial index files to my files (and even database
> connections
> done via a VRT) -

FYI : if the VRT just wraps the underlying datasource, the underlying spatial
index should already currently be used when setting a spatial filter. You could
verify than easily with a VRT with an anderlying shapefile with a .qix, or a
postgis DB with a spatial index.

> and then having OGR understand how to use those indexes.
>
> That'd be pretty awesome in my opinion... not that I'm able to implement
> anything
> myself, but thought I'd raise a cheer around the idea ;-)

As far as a general spatial indexing for any OGR datasource, I don't know how it
would be possible because a spatial index only makes sense if you can have
random access to the features. And a lot of OGR formats currently don't support
(efficient) random access, due to the nature of the storage (any text based
format for example). Or it would require significant work in drivers so they are
able to partially parse the file given a file offset (would be difficult for XML
parsers).

So if you want a spatial index to be efficient, the easiest whay would be to
store the features themselves in RAM (which doesn't scale), or transform into a
format/storage that natively support random feature access.

>
> Tyler
>
>