Thanks muchly.<br><br>I implemented the fieldname launderer and the warning suppression - and all tests pass:<br><a href="https://github.com/AIFDR/riab/commit/ced28719d4878d4dfc3a70a08aebbd5f98bca744">https://github.com/AIFDR/riab/commit/ced28719d4878d4dfc3a70a08aebbd5f98bca744</a><br>
<a href="https://github.com/AIFDR/riab/commit/a1e3632fc452af58d6288771b8528432403b8d0c">https://github.com/AIFDR/riab/commit/a1e3632fc452af58d6288771b8528432403b8d0c</a><br><br><br>Thanks heaps for all your help<br>Ole<br>
<br><br><div class="gmail_quote">On Wed, Sep 7, 2011 at 12:16 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Le mercredi 07 septembre 2011 02:36:35, Ole Nielsen a écrit :<br>
<div class="im">> Yes this seems to work. However, I get a huge amounts of warnings of the<br>
> form<br>
><br>
> >>> lyr.CreateField(fd)<br>
><br>
> Warning 6: Normalized/laundered field name: 'A slightly long name' to 'A<br>
> slightly'<br>
> 0<br>
><br>
> They obviously tell what name has been derived, but I don't want this<br>
> output to clutter, and since that name is already available through your<br>
> procedure they really should be suppressed. Can that be done?<br>
<br>
</div>Yes, you can surround the CreateField() call with :<br>
<br>
gdal.PushErrorHandler('CPLQuietErrorHandler')<br>
...<br>
gdal.PopErrorHandler()<br>
<div><div></div><div class="h5"><br>
> Many thanks<br>
> Ole<br>
><br>
> On Tue, Sep 6, 2011 at 10:10 PM, Even Rouault<br>
><br>
> <<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>>wrote:<br>
> > Selon Ole Nielsen <<a href="mailto:ole.moller.nielsen@gmail.com">ole.moller.nielsen@gmail.com</a>>:<br>
> > > Thanks - I was hoping I could rely on the library to do the intelligent<br>
> > > truncation, but couldn't work it out.<br>
> > > Can I just clarify that the name to use with SetField would then be<br>
> > > what<br>
> ><br>
> > is<br>
> ><br>
> > > provided by your last line?<br>
> > ><br>
> > > layer_defn.GetFieldDefn(last_field_idx).GetNameRef()<br>
> ><br>
> > Yes<br>
> ><br>
> > > Cheers and thanks<br>
> > > Ole<br>
> > ><br>
> > > On Tue, Sep 6, 2011 at 9:26 PM, Even Rouault<br>
> > ><br>
> > > <<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>>wrote:<br>
> > > > Selon Ole Nielsen <<a href="mailto:ole.moller.nielsen@gmail.com">ole.moller.nielsen@gmail.com</a>>:<br>
> > > > > Hi Even<br>
> > > > ><br>
> > > > > Thanks again for all your help - all tests now pass using either<br>
> > > > > gdal<br>
> ><br>
> > 1.6<br>
> ><br>
> > > > or<br>
> > > ><br>
> > > > > 1.8. Just to summarise, there were three issues as I see them:<br>
> > > > > 1. Bounding boxes for raster data are computed differently (but<br>
> > > ><br>
> > > > better)<br>
> > > ><br>
> > > > > in newer versions<br>
> > > ><br>
> > > > Specific to PixelIsPoint in the GTiff driver.<br>
> > > ><br>
> > > > > 2. While v1.6 of ogre would allow an single number of type<br>
> > > ><br>
> > > > numpy.ndarray<br>
> > > ><br>
> > > > > this is no longer allow. Casting it to a float solves the<br>
> > > > > problem.<br>
> > > ><br>
> > > > I wasn't aware it could work before. There's perhaps now an ambiguity<br>
> ><br>
> > on<br>
> ><br>
> > > > which<br>
> > > > method to use, due to the addition of new possibilities for<br>
> > > > SetField() (just a<br>
> > > > bling guess).<br>
> > > ><br>
> > > > > 3. New versions of ogre will not allow attribute names of length<br>
> > > ><br>
> > > > longer<br>
> > > ><br>
> > > > > than 10 (at least when using the ESRI driver). Formerly, I think<br>
> ><br>
> > it<br>
> ><br>
> > > > > silently<br>
> > > > ><br>
> > > > > truncated, now it is up to the user. That's at least what I did.<br>
> > > ><br>
> > > > I've a looked quickly a bit at your code and I've the feeling that<br>
> > > > you truncate<br>
> > > > yourself, instead of relying on OGR. The Shapefile driver does more<br>
> ><br>
> > than<br>
> ><br>
> > > > truncating. It also ensures uniqueness of the truncated names. For<br>
> ><br>
> > example,<br>
> ><br>
> > > > if<br>
> > > > you try creating "a_very_long_name" and "a_very_long_name_again",<br>
> > > > they<br>
> ><br>
> > will<br>
> ><br>
> > > > be<br>
> > > > respectively truncated to "a_very_lon" and "a_very_l_1". A safer<br>
> ><br>
> > solution<br>
> ><br>
> > > > to get<br>
> > > > the field name that got to the file would be to :<br>
> > > ><br>
> > > > field_defn = ogr.FieldDefn("a_very_long_name", ogr.OFTString)<br>
> > > > lyr.CreateField(field_defn)<br>
> > > > layer_defn = lyr.GetLayerDefn()<br>
> > > > last_field_idx = layer_defn.GetFieldCount() - 1<br>
> > > > real_field_name =<br>
> > > > layer_defn.GetFieldDefn(last_field_idx).GetNameRef()<br>
</div></div></blockquote></div><br>