[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