[gdal-dev] the same names of attribute types in shapefile after ogr2ogr: a problem for us

[Tamas Szekeres]

I'd add that using the OGR SQL option you could explicitly rename any
of the fields by using the AS keyword either when using ogr2ogr or the
scripting interfaces.

Best regards,

Tamas



2008/3/11, Frank Warmerdam <warmerdam at pobox.com>:
> Vitali Diatchkov wrote:
>  > Hello!
>  >
>  > We use GDAL library (actually OGR part of it) for conversion from TAB to
>  > Shapefile. This functionality is called from JVM through JNI (Java Native
>  > Interface): we wrapped necessary functionality of ogr2ogr with required
>  > changes into java native methods and call OGR routines from java code. This
>  > is a background. This solves our specific tasks. But we  have a problem that
>  > our customers have many TAB files where there are attribute types with the
>  > same long prefix in name. During conversion the attribute type name is cut
>  > for 10 characters (may be because of DBF spec) and as a result a shapefile
>  > has several attribute types with the same names. OGR library produces this
>  > kind of files without worrying but later on ShapefileDataStore (a GeoTools'
>  > java library driver for shapefiles) fails to handle them.
>  >
>  > What is the easiest solution to catch these cases at the stage of conversion
>  > inside of OGR and rename attribute types on the fly based on some simple
>  > rules?   The exact matching of names is unimportant; the shapefile with
>  > unique (fixed) attribute type names is required.
>
>
> Vitali,
>
>  I'm a bit confused because if you are using JNI calls into the OGR bindings
>  you can manipulate the field names yourself before creating them on the
>  shapefile datasource.
>
>  I do think that the OGR Shapefile driver likely ought to check for repeated
>  field names (after trimming) and either fixup the field name to be unique
>  using some schema or issue an error.  I see the CreateField() method has
>  an "Approximate OK" flag.  We might fix things up if ApproxOK is true, and
>  issue an error if ApproxOK is false.
>
>  I'd note that ogr2ogr already has problems properly copying features where
>  the field names change due to field name laundering because the
>  OGRFeature::CopyFrom() method is field name based rather than knowing in
>  advance what field goes where.  So even improving the shapefile driver
>  will not immediately fix ogr2ogr.
>
>  I would encourage you to file a ticket on the shapefile driver suggestion
>  if you feel reasonably strongly about it - though I'm not sure when the issue
>  will be acted on.
>
>  Best regards,
>
> --
>  ---------------------------------------+--------------------------------------
>  I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
>  light and sound - activate the windows | http://pobox.com/~warmerdam
>  and watch the world go round - Rush    | President OSGeo, http://osgeo.org
>
>
>  _______________________________________________
>  gdal-dev mailing list
>  gdal-dev at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/gdal-dev
>