[gdal-dev] Fwd: NotImplementedError: Wrong number of arguments for overloaded function 'Feature_SetField'.

[Ole Nielsen]

Hi Even

Thanks again for all your help - all tests now pass using either gdal 1.6 or
1.8. Just to summarise, there were three issues as I see them:


   1. Bounding boxes for raster data are computed differently (but better)
   in newer versions
   2. While v1.6 of ogre would allow an single number of type numpy.ndarray
   this is no longer allow. Casting it to a float solves the problem.
   3. New versions of ogre will not allow attribute names of length longer
   than 10 (at least when using the ESRI driver). Formerly, I think it silently
   truncated, now it is up to the user. That's at least what I did.

For those interested, the updated class dealing with vector data for our
risk modelling application is available on github at
https://github.com/AIFDR/riab/blob/develop/impact/storage/vector.py

Thanks again for a great piece of software
Ole Nielsen

On Tue, Sep 6, 2011 at 1:05 PM, Even Rouault
<even.rouault at mines-paris.org>wrote:

> >    - What are the official ogr steps required to store a vector layer
> >    (represented as e.g. a list of x, y values and associated feature
> > attributes (name, value))? In particular, is CreateField perhaps
> obsoleted
> > by something else?
>
> Nothing obsoleted here. CreateField() and CreateFeature() are the way to go
>
> >    - Is the truncation to 10 characters hard and fast or driver dependent
> -
> >    and how should one deal with this truncation? Your example (which does
> > not use CreateField) would suggest names can be longer than 10
> characters.
>
> Yes, it is specific to the shapefile driver. This is a in fact a limitation
> of
> the DBF format itself : http://www.gdal.org/ogr/drv_shapefile.html
>
> And the implementation of the truncation has indeed changed in recent
> versions. I somehow remember that in previous versions CreateField() only
> truncated in the field name in the DBF file but not in the feature
> definition
> just after calling it. Now its behaviour is more consistant, but can indeed
> be
> a bit strange where one is not aware of it.
>
> > - Where can i find some documentation of the OGR Python bindings?
>
> You'll find a lot of ressources here :
> http://trac.osgeo.org/gdal/wiki/GdalOgrInPython
>
> Best regards,
>
> Even
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110906/49f247f2/attachment.html