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

[Even Rouault]

Le mercredi 07 septembre 2011 02:36:35, Ole Nielsen a écrit :
> Yes this seems to work. However, I get a huge amounts of warnings of the
> form
> 
> >>> lyr.CreateField(fd)
> 
> Warning 6: Normalized/laundered field name: 'A slightly long name' to 'A
> slightly'
> 0
> 
> They obviously tell what name has been derived, but I don't want this
> output to clutter, and since that name is already available through your
> procedure they really should be suppressed. Can that be done?

Yes, you can surround the CreateField() call with :

gdal.PushErrorHandler('CPLQuietErrorHandler')
...
gdal.PopErrorHandler()

> Many thanks
> Ole
> 
> On Tue, Sep 6, 2011 at 10:10 PM, Even Rouault
> 
> <even.rouault at mines-paris.org>wrote:
> > Selon Ole Nielsen <ole.moller.nielsen at gmail.com>:
> > > Thanks - I was hoping I could rely on the library to do the intelligent
> > > truncation, but couldn't work it out.
> > > Can I just clarify that the name to use with SetField would then be
> > > what
> > 
> > is
> > 
> > > provided by your last line?
> > > 
> > >  layer_defn.GetFieldDefn(last_field_idx).GetNameRef()
> > 
> > Yes
> > 
> > > Cheers and thanks
> > > Ole
> > > 
> > > On Tue, Sep 6, 2011 at 9:26 PM, Even Rouault
> > > 
> > > <even.rouault at mines-paris.org>wrote:
> > > > Selon Ole Nielsen <ole.moller.nielsen at gmail.com>:
> > > > > 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
> > > > 
> > > > Specific to PixelIsPoint in the GTiff driver.
> > > > 
> > > > >    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.
> > > > 
> > > > I wasn't aware it could work before. There's perhaps now an ambiguity
> > 
> > on
> > 
> > > > which
> > > > method to use, due to the addition of new possibilities for
> > > > SetField() (just a
> > > > bling guess).
> > > > 
> > > > >    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.
> > > > 
> > > > I've a looked quickly a bit at your code and I've the feeling that
> > > > you truncate
> > > > yourself, instead of relying on OGR. The Shapefile driver does more
> > 
> > than
> > 
> > > > truncating. It also ensures uniqueness of the truncated names. For
> > 
> > example,
> > 
> > > > if
> > > > you try creating "a_very_long_name" and "a_very_long_name_again",
> > > > they
> > 
> > will
> > 
> > > > be
> > > > respectively truncated to "a_very_lon" and "a_very_l_1". A safer
> > 
> > solution
> > 
> > > > to get
> > > > the field name that got to the file would be to :
> > > > 
> > > > field_defn = ogr.FieldDefn("a_very_long_name", ogr.OFTString)
> > > > lyr.CreateField(field_defn)
> > > > layer_defn = lyr.GetLayerDefn()
> > > > last_field_idx = layer_defn.GetFieldCount() - 1
> > > > real_field_name =
> > > > layer_defn.GetFieldDefn(last_field_idx).GetNameRef()