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

Frank Warmerdam warmerdam at pobox.com
Tue Mar 11 18:20:50 EDT 2008


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



More information about the gdal-dev mailing list