[Gdal-dev] ogr.py enhancement proposal

[Frank Warmerdam]

On Wed, 02 Feb 2005 10:11:26 -0600, Howard Butler <hobu at iastate.edu> wrote:
> Folks,
>
> The major enhancement that I made was to allow slicing and index access to
> Layer and DataSource.  Here is an example of what I mean:

Howard, 

The slicing/indexing on the ogr.Datasource to get a list 
of ogr.Layers sounds fine to me.   Feel free to commit. 

> The same enhancement was made to the Layer object as well.  It is important
> to note, however, that you are not *guaranteed* sequential access to the
> Features in a layer.  This approach will work for the majority of cases,
> but if you have a funky DataSource/Layer, you might not always get what you
> expect.

As we discussed in IRC, I think you should hold off on this.
Slicing by FID is error prone for discontiguous layers.  This
includes odd formats (like DGN) with discontigious fids, as well
as normal formats that have discontigous fids due to having 
a spatial or attribute filter in place. 

You mentioned that you could implement iterator support 
using GetNextFeature() if you used a feature of a newer 
Python.  I think this would be OK though we would need to 
ensure that this feature is disabled for older Pythons. 

As mentioned before I would like to keep ogr.py working
with pythons back as far as 2.0 if possible, though it would
be acceptable to have a few advanced features only available
with newer pythons. 

I would add that I am currently working on a SetNextByIndex()
method on the OGRLayer.   This method can be used to 
essentially move around in a resultset by index rather than
fid.  So calling SetNextByIndex(10) on a layer would mean
that the next GetNextFeature() on that layer would return the
10th feature in the current resultset (taking into account any
filters in place).  For some datasources this method will be
implemented efficiently though the fallback implementation is
just to do a ResetReading() and then GetNextFeature() for
the indicated number of times.  So performance will be variable.

The only way to be sure of respectible performance accross all
formats and configurations is to jus make one pass through data
using GetNextFeature(). 
 
> # again, we get looping and slicing for free
> for i in lyr[0:10]:
>      print i.GetField(0)

I would certainly love to be able to iterate invisibly on a 
layer to get features as long as it is internally using GetNextFeature()
for the stepping, not fetching by fid. 

eg. 

for feat in lyr:
    print feat.GetFID()

> #--------------------------------------------------------------
> 
> Feature Enhancement Proposal
> 
> I would like to extend Feature to support run-time attribute
> lookup.  Thanks to Frank's enhancement to allow features to clean up after
> themselves, it would now be straightforward to allow you to access field
> information as a direct attribute of the feature, rather than being forced
> to look up the field's index and then request the information.  For example:

As we discussed in IRC I am fine with this change as long as you take
care to ensure it's implementation does not add noticable overhead to 
normal use of a feature. 

> Second, does accessing things this way muddy up what a
> "Feature" is and how things are accessed?  When I request a Field, like
> feat.Column2, am I getting back the *value* of the Feature in that Field,
> or the definition of the Column2 field?

The attribute values of a feature are it's properties.  If you want the 
field definitions you should be examining the ogr.FeatureDefn returned
by ogr.Layer.GetLayerDefn().  It would be nice to have some sort of
convenient access to these. 

Note that all these Python specific syntaxes will require some degree
of documentation since they aren't completey obvious by examining
the C++ API.  But I think they are a great step forward. 

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent