[gdal-dev] ogr.Feature field access

[Ari Jolma]

On 11/23/2011 08:53 AM, Frank Warmerdam wrote:
> 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.

Interesting. This kind of access to various types of attributes has been 
in Perl bindings (SetField/GetField or simply Field methods) a long 
time. I just added the support for FETCH and STORE, i.e., 
$feature->{field} syntax - which is not as pretty as Python's but is 
useful in some cases.

Ari

>
> 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,