Shapefile has repeated fields, ogr2ogr bails on defining the second in postgis

[tylermitchell@…]

This file sucks and I don't expect ogr2ogr to handle buggy data, but it would 
be nice if it could handle this inconsistency rather than letting PostGIS halt 
the process.  Could ogr2ogr handle checking for problematic field names (i.e. 
duplicates) rather than leaving it up to PostGIS to complain? 
It'd be even greater if it could rename repeated attributes before getting 
that far.  Perhaps there is already an lco that I'm not aware of? 
 
> ogr2ogr -f "PostgreSQL" "PG:dbname=project1" pres_nov28.shp 
ERROR 1: ALTER TABLE "pres_nov28" ADD COLUMN "state_fips" CHAR(12) 
ERROR:  column "state_fips" of relation "pres_nov28" already exists 
 
ERROR 1: ALTER TABLE "pres_nov28" ADD COLUMN "cnty_fips" CHAR(13) 
ERROR:  column "cnty_fips" of relation "pres_nov28" already exists 
 
ERROR 1: INSERT command for new feature failed. 
ERROR:  new row for relation "pres_nov28" violates check constraint "$2" 
 
ERROR 1: Terminating translation prematurely after failed 
translation of layer pres_nov28

[warmerdam]

Tyler, 

I reviewed the file and I see what you mean about duplicate field names. 
I'm not really sure what to do about this.  I could write code into the
shapefile driver to mutate the names to make them unique but then I will be
faced with similar problems for all other drivers.  I could try and mutate
the field names when adding them in Oracle, but that will likely cause alot
of difficulties keeping track of the original and new name and doesn't help for
other output drivers. 

For now I will keep this bug report open while I think about what to do. 

Best regards,

[neteler@…]

Frank,

just FYI: the v.in.ogr in GRASS comes with 'cnames' parameter which
permits to rename fields on the fly while importing.

http://grass.itc.it/grass60/manuals/html60_user/v.in.ogr.html

Markus