Slicing a GDAL layer should scan layer once only

[wongcht]

In django.contrib.gis.gdal.layer's Layer.__getitem__, if a layer (with n features) does not support random read, slicing the layer would call _make_feature at most n times which this method scan the whole layer until feature id matched.

E.g. Slicing a layer for 3 features (id= 1,2,3) would scan the layer 3 times: [1] for id=1, [1,2] for id=2, [1,2,3] for id=3. Worst case would call __iter__ (capi.get_next_feature) for n(n+1)/2 times

A better iteration should scan the layer once only to get all features required. A possible ​fix FYR

[David Smith]

A benchmark script for performance improvements is helpful to assess both the current situation and to compare any improvements against.

I wonder if a simplification of the current code is enough. ​get_featre() has a fallback if random read is not supported and therefore we could rely on the underlying c library. Reducing the number of c api calls is likely to be beneficial, but would need to have a benchmark to prove.

That is _make_feature() could become.

    def _make_feature(self, feat_id):
        """
        Helper routine for __getitem__ that constructs a Feature from the given
        Feature ID. 
        """
        try:
            return Feature(capi.get_feature(self.ptr, feat_id), self)
        except GDALException:
            pass
        raise IndexError("Invalid feature id: %s." % feat_id)

I'll mark as needs info - a benchmark script showing the performance issue would be the next step here. Do you have the capacity to write one up?