[GRASSLIST:2572] Re: v.in.ogr --- what does this error mean, and where's it coming from?

[Radim Blazek]

I have tried to create the table and it works. Could you also try 
to create the table by db.execute?:
echo "create table trails (cat integer, ....." | db.execute 
(use whole statement of course)

Radim

On Thursday 12 February 2004 06:52, Tom Russo wrote:
> I am using Grass 5.7.  I first built this using the CVS version on 21
> November 2003, and was able to use v.in.ogr and v.shape.register to
> import some shapefiles I've got of US Forest Service roads and trails.
> Today, using a CVS version of grass 5.7 I updated to in late January,
> I discovered that the previously imported or registered shapes weren't
> displaying, so I removed them and attempted to reimport.  It failed
> (the same way as below).  I have since done a CVS update this morning
> on both grass 5.7 AND gdal source trees, then rebuilt gdal/ogr and
> grass57, and continue to be unable to read in these shapefiles:
>
> Layer: USFS_SandiaRD_UTM
> DBMI-DBF driver error: (null)
> ERROR: Cannot create table: create table trails (cat integer, FNODE_
>   integer, TNODE_ integer, LPOLY_ integer, RPOLY_ integer, LENGTH double
>   precision, TRAIL_ integer, TRAIL_ID integer, TYPE varchar ( 1 ), CODE
> varchar ( 2 ), CODE_MEMO varchar ( 80 ), METHOD varchar ( 2 ), MISC varchar
> ( 1 ), TE_UNIT varchar ( 1 ), EXISTVEG varchar ( 1 ), FS_OWN varchar ( 1 ),
> TRAIL varchar ( 1 ), ROAD varchar ( 1 ), WATER varchar ( 1 ), STREAM
> varchar ( 1 ), PLSS varchar ( 1 ), ADM_DIST varchar ( 1 ), ADM_UNIT varchar
> ( 1 ), PASTURE varchar ( 1 ), SPEC_MGT varchar ( 1 ), HRTGSRVY varchar ( 1
> ), RD_RTE_NO varchar ( 35 ), TR_RTE_NO varchar ( 35 ), STRM_NAME varchar (
> 80 ), SURVEY_NUM varchar ( 13 ), CFF1 varchar ( 3 ), CFF2 varchar ( 3 ),
> CFF3 varchar ( 3 ), CFF4 varchar ( 3 ), CFF5 varchar ( 3 ), CFF6 varchar (
> 3 ), CFF7 varchar ( 3 ), CFF8 varchar ( 3 ), CFF9 varchar ( 3 ), CFF10
> varchar ( 3 ), NUMBER varchar ( 35 ), NUMBER0 varchar ( 35 ), LEVE varchar
> ( 20 ), TYPE0 varchar ( 20 ), ROAD_TYPE varchar ( 20 ), LANES varchar ( 20
> ), SURFACE varchar ( 20 ), PROBLEM varchar ( 20 ), CLOSURE varchar ( 20 ),
> DATE integer, TIME varchar ( 20 ), OPERATOR varchar ( 20 ), COMMENTS
> varchar ( 50 ), MAX_PDOP double precision, GPS_DATE integer, GPS_TIME
> varchar ( 20 ), GPS_LENGTH double precision, HORZ_PREC double precision,
> VERT_PREC double precision, HORZ_PRE0 double precision, VERT_PRE0 double
> precision, TRAIL_NO varchar ( 10 ), SOURCE varchar ( 10 ), MAPUSE varchar (
> 25 ), NAME varchar ( 30 ), MILES2 double precision, COOID varchar ( 10 ),
> STATUS integer)
>
> The vectors appear to be imported, but the dbf files aren't.
>
> The "DBMI-DBF driver error: (null)" is really helpful :-)  It does
> that even with the 'g.gisenv set="debug=3"' that I read about here
> earlier today.
>
> I can still use v.in.ogr to import much simpler shape files (such as
> those produced by xastir from APRS data, which are just polylines with
> a couple of attributes in the .dbf file), but I have no simpler
> version of these particular USFS data sets.
>
> BTW, these shapefiles are actually shapefile conversions (using FME Desktop
> Suite) of some .e00 files I got from the US Forest Service.  Just to see if
> it was something strange from the conversion to a shapefile, I was able to
> uncompress the .e00 files using e00compr, and convert them to AVCbin using
> avcimport (some open source tools for manipulating these files).  If I try
> to use the resulting AVCbin files instead of the shapefiles then I get a
> similar message:
>
> Proceeding with import...
> Layer: ARC
> WARNING: Column name changed from 'FNODE#' to 'FNODE_'
> WARNING: Column name changed from 'TNODE#' to 'TNODE_'
> WARNING: Column name changed from 'LPOLY#' to 'LPOLY_'
> WARNING: Column name changed from 'RPOLY#' to 'RPOLY_'
> WARNING: Column name changed from 'FOO#' to 'FOO_'
> WARNING: Column name changed from 'FOO-ID' to 'FOO_ID'
> DBMI-DBF driver error: (null)
> ERROR: Cannot create table: create table trails (cat integer, UserId
>        integer, FNODE_ integer, TNODE_ integer, LPOLY_ integer, RPOLY_
> integer, LENGTH double precision, FOO_ integer, FOO_ID integer,
> CORRECTION_TYPE varchar ( 1 ), SOURCE_CODE varchar ( 2 ), SOURCE_CODE_MEMO
> varchar ( 80 ) ,
>        METHOD varchar ( 2 ), MISC integer, TE_UNIT integer, EXISTVEG
> integer, FS_OWN integer, TRAIL integer, ROAD integer, WATER integer, STREAM
> integer, PLSS integer, ADM_DIST integer, ADM_UNIT integer, PASTURE intege
> r,
>        SPEC_MGT integer, HRTGSRVY integer, RD_RTE_NO varchar ( 35 ),
> TR_RTE_NO varchar ( 35 ), STRM_NAME varchar ( 80 ), SURVEY_NUM varchar ( 13
> ), CFF1 integer, CFF2 integer, CFF3 integer, CFF4 integer, CFF5 integer,
> CFF6 integer, CFF7 integer, CFF8 integer, CFF9 integer, CFF10 integer,
> FILE_NUMBER varchar ( 35 ), ROAD_NUMBER varchar ( 35 ), MAINTENANCE_LEVE
> varchar ( 20 ), VEHICLE_TYPE varchar ( 20 ), ROAD_TYPE varchar ( 20 ),
> NUMBER_LANES varchar ( 20 ), SURFACE varchar ( 20 ), RESOURCE_PROBLEM var
> char (
>        20 ), ROAD_CLOSURE varchar ( 20 ), DATE varchar ( 8 ), TIME varchar
> ( 20 ), OPERATOR varchar ( 20 ), COMMENTS varchar ( 50 ), MAX_PDOP double
> precision, GPS_DATE varchar ( 8 ), GPS_TIME varchar ( 20 ), GPS_LENGTH
> double precision, AVG_HORZ_PREC double precision, AVG_VERT_PRE C
>        double precision, WORST_HORZ_PREC double precision, WORST_VERT_PREC
> doubl e
>        precision, TRAIL_NO varchar ( 10 ), SOURCE varchar ( 10 ), MAPUSE
> varchar ( 25
>        ), NAME varchar ( 30 ), MILES2 double precision, COOID integer,
>        CONFLATE_STATUS integer)
>
>
> Help?  What has changed since November that would have caused these
> exact shapefiles to now be rejected?  Is there anything in this output
> that points to what it is that DBMI-DBF driver is hating?  Is there a
> way to make it happy?