[GRASS-dev] v.in.ogr broken (\w shp)
neteler at itc.it
Mon Sep 4 07:24:21 EDT 2006
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).
> What do you think?
Such a message would be very useful.
>  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:
More information about the grass-dev