GRASS 6.5.svn (Nevada-utm27):~/grassdata > v.in.ascii -b --o
in=/home/rshepard/GIS/data/Nevada/nv_wells.txt out=water_wells format=point
fs='|' skip=1 columns='well_log varchar(8), x double precision, y double
precision' x=2 y=3 z=0 cat=0
Scanning input for column types...
Maximum input row length: 39
Maximum number of columns: 3
Minimum number of columns: 3
Column: 1 type: string length: 8
Column: 2 type: double
Column: 3 type: double
Importing points...
100%
Populating table...
ERROR: Could not close attribute table. The DBMI driver did not accept all
attributes
The source table contains three columns: the well_log ID, utm_easting, and
utm_northing. Seems to me that only the first would be an attribute for the
table. How do I determine what the problem is?
GRASS 6.5.svn (Nevada-utm27):~/grassdata > v.in.ascii -b --o
in=/home/rshepard/GIS/data/Nevada/nv_wells.txt out=water_wells format=point
fs='|' skip=1 columns='well_log varchar(8), x double precision, y double
precision' x=2 y=3 z=0 cat=0
Scanning input for column types...
Maximum input row length: 39
Maximum number of columns: 3
Minimum number of columns: 3
Column: 1 type: string length: 8
Column: 2 type: double
Column: 3 type: double
Importing points...
100%
Populating table...
ERROR: Could not close attribute table. The DBMI driver did not accept all
attributes
The source table contains three columns: the well_log ID, utm_easting, and
utm_northing. Seems to me that only the first would be an attribute for the
table. How do I determine what the problem is?
first, enable debugging
g.gisenv set=DEBUG=5
and re-run the command.
Martin,
Populating table...
D2/5: Commit transaction
D2/5: save_table 0
D2/5: save_table 1
D2/5: save_table 2
D2/5: Write table to tempfile:
'/home/rshepard/grassdata/Nevada-utm27/PERMANENT/.tmp/salmo/27870.dbf'
D2/5: Write 110339 rows
D2/5: Written 110339 records
D2/5: db_close_database() result: 0 (0 means success)
D2/5: db_shutdown_driver() failed
ERROR: Could not close attribute table. The DBMI driver did not accept all
attributes
So, it looks like the problem is within db_shutdown_driver(), eh?
Which OS and DB driver you are using?
db.connect -p
GRASS 6.5.svn (Nevada-utm27):~/grassdata > v.in.ascii -b --o
in=/home/rshepard/GIS/data/Nevada/nv_wells.txt out=water_wells format=point
fs='|' skip=1 columns='well_log varchar(8), x double precision, y double
Any rows with the well_log longer than 8 characters?
With 100,000 rows you really should consider shifting from dbf to either sqlite or postgresql...
precision' x=2 y=3 z=0 cat=0
Scanning input for column types...
Maximum input row length: 39
Maximum number of columns: 3
Minimum number of columns: 3
Column: 1 type: string length: 8
Column: 2 type: double
Column: 3 type: double
Importing points...
100%
Populating table...
ERROR: Could not close attribute table. The DBMI driver did not accept all
attributes
The source table contains three columns: the well_log ID, utm_easting, and
utm_northing. Seems to me that only the first would be an attribute for the
table. How do I determine what the problem is?
Any rows with the well_log longer than 8 characters?
Micha,
No; they range from 1 to 6 numbers. Because they need to be explicitly
quoted I changed the column size to 8.
With 100,000 rows you really should consider shifting from dbf to either sqlite or postgresql...
The basic table is in postgres. I've not before used postgres with a grass
project and I thought that the proper approach was to first extract a
separate table containing only the well_log primary key and the spatial
location for the grass geographic information. Second would be my learning
how to link the postgres attribute table to this map.
If this is not the proper way then I need to learn how to do this
properly.
As evident by my questions this past week, some table rows have no
geographic coordinates, some have 0.000000 as geographic coordinates, and
one (perhaps more) has 0.000000 as the easting coordinate and NULL for the
northing. I would be just as satisfied to use the base postgres table as
long as grass did not try to assign points to those rows with invalid or
missing coordinates.
No; they range from 1 to 6 numbers. Because they need to be explicitly
quoted I changed the column size to 8.
With 100,000 rows you really should consider shifting from dbf to either
sqlite or postgresql...
better to avoid dbf at all
The basic table is in postgres. I've not before used postgres with a grass
project and I thought that the proper approach was to first extract a
separate table containing only the well_log primary key and the spatial
location for the grass geographic information. Second would be my learning
how to link the postgres attribute table to this map.
Set up default DB backend. Newly produced vector data will store it's
attributes in this backend.
Will do. I've used sqlite extensively the past few years in the
approximate reasoning models I've developed. For use with GRASS, however,
postgres is the better tool because I can share tables among different
projects. I'm thinking of either having a single database for each state, or
using schemas (schemae?) so data (such as these water well logs) can be
shared with different GRASS mapsets (one mapset per project).
I always assumed this was based on dBASE or, perhaps, BerkeleyDB.
Set up default DB backend. Newly produced vector data will store it's
attributes in this backend.
This is a good time for me to ask about postGIS. I've looked superficially
at it over the years, yet I still have no deep understanding of what it
provides that postgres and grass do not. It seems to me that postGIS, QGIS,
and similar tools are alternatives to postgres + grass. No?
I always assumed this was based on dBASE or, perhaps, BerkeleyDB.
default driver in GRASS 6 is dbf [1] (dBASE)
Set up default DB backend. Newly produced vector data will store it's
attributes in this backend.
This is a good time for me to ask about postGIS. I've looked superficially
at it over the years, yet I still have no deep understanding of what it
provides that postgres and grass do not. It seems to me that postGIS, QGIS,
and similar tools are alternatives to postgres + grass. No?
it's very vague to say that, PostGIS implement OGC Simple Features [2]
for PostgreSQL. It's extension for PostgreSQL which enables this
database system to store, process, and analyze spatial data. PostGIS
is spatial database. GRASS is a desktop GIS environment.
> Populating table...
> ERROR: Could not close attribute table. The DBMI driver did not
> accept all attributes
Hi, for the record, I just came across the same problem in 6.5svn on linux.
svn up + rebuilding grass made it go away.
see https://trac.osgeo.org/grass/ticket/1159
Micha wrote:
With 100,000 rows you really should consider shifting from
dbf to either sqlite or postgresql...
actually I think dbf has such low overhead that it is quite efficient
with large datasets. It has all sorts of other warts, but it came from
an era in the 80s where it /had/ to be efficient.
I imagine it dies a horrible death with >2gb files though.