If I read the command history correctly, GRASS truncated column names and
ended up with two columns with the same name so it bailed out on me. This is
a 1999-vintage hydrography file (but nothing's changed in the topography and
waterbodies since then). I don't know what to do to over come this error.
Advice wanted.
Command history:
(Tue Mar 20 09:31:58 2012) v.in.e00 -v --overwrite file=/home/rshepard/GIS/data/Washington/hydrography/kettle_river/b7020002.e00 type=area vect=kettle_river_waterbodies
An error may appear next which will be ignored...
E00 Compressed ASCII found. Will uncompress first...
...converted to Arc Coverage in current directory
Importing areas...
Vector map <kettle_river_waterbodies> already exists and will be overwritten
Over-riding projection check
Vector map <kettle_river_waterbodies> already exists and will be overwritten
Table <kettle_river_waterbodies> linked to vector map <kettle_river_waterbodies> does not exist
Vector map <kettle_river_waterbodies_tmp> already exists and will be overwritten
Layer: LAB
Column name changed: 'B7020002#' -> 'B7020002_'
Column name changed: 'B7020002-ID' -> 'B7020002_ID'
DBMI-DBF driver: column name 'B7020002_ID' truncated to 'B7020002_I'
DBMI-DBF driver: column name 'WTRBDY_TYPE_CD' truncated to 'WTRBDY_TYP'
Counting polygons for 47 features...
Importing map 47 features...
Layer: ARC
Column name changed: 'B7020002#' -> 'B7020002_'
Column name changed: 'B7020002-ID' -> 'B7020002_ID'
DBMI-DBF driver: column name 'B7020002_ID' truncated to 'B7020002_I'
DBMI-DBF driver: column name 'WTRBDY_SL_LWR_AD' truncated to 'WTRBDY_SL_'
DBMI-DBF driver: column name 'WTRBDY_SL_UPR_AD' truncated to 'WTRBDY_SL_'
DBMI-DBF driver error:
Column 'WTRBDY_SL_' already exists (duplicate name)
Cannot create table.
Error in db_execute_immediate()
ERROR: Unable to create table: 'create table kettle_river_waterbodies_2 (cat integer, UserId integer, FNODE_ integer, TNODE_ integer, LPOLY_ integer, RPOLY_ integer, LENGTH double precision, B7020002_ integer, B7020002_ID integer, WTRBDY_NR varchar ( 13 ), WTRBDY_SL_LWR_AD double precision, WTRBDY_SL_UPR_AD double precision, WTRBDY_SL_TYP_CD integer)'
ERROR: An error occurred. Halting.
(Tue Mar 20 09:31:59 2012) Command finished (0 sec)
dbf can only have 8 characters as column name.
try a sql database as vector database backend:
Helmut,
I'm trying to use postgres for all vector map attributes and have read
everything in the on-line docs several times.
What I'm finding is that when I import a new map (such as the waterbody
.e00 that started this thread) the attributes end up in a .dbf table rather
than a new postgres table. Therefore, I need to straighten out the contents
of the dot-files: ~/.grasslogin64, ~/.grassrc6, and ~/.grasswx6.
I'm running -6.5svn, and I see what appears to be overlapping and
conflicting information in the first two dot-files. For the two large
spatial analyses projects I have two postgres databases, each with its own
set of tables.
~/.grasslogin64 has the results of db.connect and db.login for both
databases. ~/.grassrc6 has the GISDBASE, LOCATION_NAME, MAPSET, DEBUG,
MONITOR, and GRASS_GUI for one of the two projects.
What should be in both of these dot-files? And, do I duplicate the project
information in .grassrc6 for the second project?
I'm trying to use postgres for all vector map attributes and have read
everything in the on-line docs several times.
What I'm finding is that when I import a new map (such as the waterbody
.e00 that started this thread) the attributes end up in a .dbf table rather
than a new postgres table.
dbf seems to be the default database backend for this mapset.
db.connect - Prints/sets general DB connection for current mapset and exits.
- if you import a vector (v.in.ogr,v.in.e00,etc.), vector attribute data
should be then stored in the default database backend for this mapset.
AFAIK no need to manually edit ~/.grasslogin64, ~/.grassrc6, and ~/.grasswx6
etc.
AFAICT another "easy" way to create a mapset with i.e. sqlite as the
database backend for a mapset is to start a grass7-session and create a new
mapset.
in grass7 the default vector database backend is sqlite.
dbf seems to be the default database backend for this mapset.
Helmut,
Yes, that must be what happened.
what I would do:
- create a new mapset
I suspect what's happened is the automatic connection to the database was
lost so grass started without being aware of it. I've fixed that association
now so I'll re-import the map and then re-project it again.
in grass7 the default vector database backend is sqlite.
I like sqlite for single-user, embedded applications but use postgres for
more complex, multi-user applications.