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

[Brad Douglas]

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?

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

-- 
Brad Douglas <rez touchofmadness com>                      KB8UYR
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785