[GRASS-dev] v.in.ogr broken (\w shp)

[Markus Neteler]

On Mon, Sep 04, 2006 at 03:54:07AM -0700, Brad Douglas wrote:
> On Sun, 2006-09-03 at 19:59 +1200, Hamish wrote:
> > Brad Douglas wrote:
> > > Is there an easy fix for this?  I'm trying to import a shapefile and
> > > I'm not terribly familiar with this part of the GRASS architecture.
> > > 
> > > GRASS 6.3.cvs (hamilton):~/hamilton > v.in.ogr dsn=. output=roads
> > > layer=17
> > > Projection of input dataset and current location appear to match.
> > > Proceeding with import...
> > > Layer: 17
> > > DBMI-DBF driver error:
> > > Column 'ADMIN_CLAS' already exists (duplicate name)
> > > Cannot create table.
> > > Error in db_execute_immediate()
> > > 
> > > ERROR: Cannot create table: create table roads (cat integer, PREFIX
> > > varchar
> > >        ( 2 ), NAME varchar ( 30 ), TYPE varchar ( 4 ), SUFFIX varchar
> > > ( 2
> > >        ), FCC varchar ( 3 ), FIPS varchar ( 11 ), ID integer,
> > >        FULL_NAME varchar ( 40 ), ADMIN_CLAS varchar ( 40 ), CATEGORY
> > >        integer, ST_CNTY_FI varchar ( 11 ), RD_CLASS varchar ( 4 ),
> > >        RTE_NUM1
> > > varchar
> > >        ( 4 ), RTE_NUM2 varchar ( 4 ), ADMIN_CLAS integer, AREA double
> > >        precision, LEN double precision)
> > > GRASS 6.3.cvs (hamilton):~/hamilton >
> > 
> > 
> > DBF limits column names to 10 chars; you end up with "ADMIN_CLAS" twice
> > in the above list. Either change DB column names or user the v.in.ogr
> > cnames= option to rename columns to something unique. (hint, cut & paste
> > above list with modification). Maybe changing DB to SQLite or something
> > helps too?
> 
> Ahh!  Thanks!
> 
> However, this does present a usability issue.  This is a problem many,
> people will encounter.  I was trying to import a standard USGS product.
> 
> How about when v.in.ogr encounters this, offer a suggestion to fix,
> rather than simply erroring out?  We could almost cut and paste your
> answer above.  At least something a little less terse than, "ERROR:
> Cannot create table: [SQL statement]".  That describes nothing about the
> problem encountered (duplicate columns)[1].
> 
> What do you think?

Such a message would be very useful.

> [1] Yes, I do [now] realize that upon close inspection and decent
> knowledge of SQL92, one can readily solve the problem. :-)

Another option is to change the last char of the offending
col(s) to an incrementing number:

ADMIN_CLAS
ADMIN_CLA1
...

Markus