[gdal-dev] ogr2ogr with append fails to convert truncated fields

Even Rouault even.rouault at mines-paris.org
Sat Mar 2 09:45:00 PST 2013

Le vendredi 01 mars 2013 20:57:43, Tamas Szekeres a écrit :
> 2013/3/1 Even Rouault <even.rouault at mines-paris.org>
> > There's even a 4th option that doesn't require any code change. Create a
> > OGR
> > VRT file that renames the source fields to the truncated shapefile field
> > names (or
> > the reverse : creates a OGR VRT that renames the truncated shapefile
> > field names
> > to the original field names, since OGR VRT now supports since a few
> > versions
> > CreateFeature())
> This may probably work, but doesn't seem to be very user friendly. Actually
> I would prefer to include at least a flag to indicate that ogr2ogr should
> provide mapping the fields in the same order (don't lookup field index by
> name) for example:
> ogr2ogr -append -f "ESRI Shapefile" -nofieldreorder destination.shp
>  [source]
> or with the previous fieldmap approach
> ogr2ogr -append -f "ESRI Shapefile" -fieldmap "default" destination.shp
>  [source]

I'm fine with -fieldmap. It will be just another advanced option (I'm culprit 
for a bunch of other options...).  Perhaps "same_order" (or "identity" to be 
mathematically purist) instead of "default", since it's not actually the 
default behaviour (the default behaviour is to match the field names to build 
the field map). Some care should be done to check that the specified map is of 
the right size (number of fields of the source layer), or if 
"same_order"/"identity" is specified that the number of fields in the source and 
target layers are identical.

As ogr2ogr can accept several source layers, perhaps a word of caution in the 
doc of the option to mention that the specified map applies to all source 
layers, so if they don't have the same field definition, the option might not be 
relevant in that case.

> Best regards,
> Tamas

More information about the gdal-dev mailing list