[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