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

[Tom Russo]

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?

-- 
Tom Russo    KM5VY     SAR502  DM64ux         http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://www.qsl.net/~km5vy/
 "It is inhumane in my opinion to force people who have a genuine
  medical need for coffee to wait in line behind people who apparently
  view it as some kind of recreational activity."  -- Dave Barry