[gdal-dev] ogr.Feature field access

[Frank Warmerdam]

Folks,

Tonight I have made some changes to the OGR Python bindings such that
there is a SetField2() method that tries to support a wider variety of
value types that can be assigned to a field, including the list types.

I also implemented __setattr__, __getitem__ and __setitem__ so that you
can do things like:

   feat.area = 123
   feat['area'] = 123
   print feat['area']

Note that __getattr__ was already implemented so you could already use
feat.area if there was a field called 'area'.

I did the new accessors mostly so that I can have them call SetField2()
and take advantage of the new value semantics in a clean way.  With this
is it now possible to do something like:

   feat.my_list_field = [1,2,3]

assuming 'my_list_field' is a field of type ogr.OFTInteger.

I have also added a new test file (autotest/ogr/ogr_feature.py) that checks
how different types of field values are assigned by SetFrom().  This is
preliminary to my trying to improve how the C++ OGRFeature::SetFrom() method
assigns between different field types. I want to improve it so that some
obvious things are possible.  For instance assigning an integer to an
integer list should create a one length list.

This work will likely take me a while.  Even - I know you could leap out
and finish that work before wake up, but I'd appreciate it if you could give
me a couple weeks to do it at my pace. :-)

Feedback on whether the Python changes are causing problems or are expected
to are welcome.  They are:

   http://trac.osgeo.org/gdal/changeset/23416
   http://trac.osgeo.org/gdal/changeset/23417

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/warmerda
and watch the world go round - Rush    | Geospatial Software Developer