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

[Ole Nielsen]

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?
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()
> > >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110907/3901c0cd/attachment.html