[GRASS-user] I'm in a hole and want to stop digging

GRASS GRASS user
1

   I'm starting a very large project that involves GRASS, R, and postgres and
I'm running into difficulties just trying to copy vectors and rasters from
the PERMANENT mapset into a project-specific mapset. (Setting the region
also is giving me issues, as will become clear in my explanation.) All this
with -6.5svn on linux.

   I have DEM raster data and some vector data stored in the internal GRASS
.dbf format. The rest of the vector data are postgres tables. When I invoke
grass65, I immediately run 'db.connect driver=pg database=nevada' so g.list
vect shows me all vector map tables. But, it does not distinguish between
those in postgres and those in GRASS.

   An example: looking at the output of 'g.list vect' I see the county
boundary ('county_bnd'), but a table list in postgres shows 'county_bnd_arc'
and 'county_bnd_lab'. When I try to use g.copy I get errors whether I use
'county_bnd' or 'county_bnd_arc'. So, I put that aside and try to copy map
huc10:

GRASS 6.5.svn (Nevada-SPCS):~/grassdata > g.copy vect=huc10@PERMANENT,huc10
Copy vector <huc10@PERMANENT> to current mapset as <huc10>
DBMI-Postgres driver error:
Cannot create table:
create table huc10 ( cat integer, gaz_id integer, area_acres double
precision, area_sqkm double precision, states varchar(50), loaddate
varchar(10), huc_10 varchar(10), hu_10_name varchar(120), hu_10_type
varchar(1), hu_10_mod varchar(50), shape_leng double precision, shape_area
double precision )
ERROR: relation "huc10" already exists

WARNING: Unable to create table <huc10>
WARNING: Unable to copy table <huc10>
WARNING: Cannot copy <huc10@PERMANENT> to current mapset as <huc10>

   Well, huc10 _does_ exist in postgres (I imported it to the PERMANENT
mapset), but it's not available in the jerritt mapset.

   Because working with both the internal and an external dbms for vector
data is new to me I'd greatly appreciate pointers to what I need to read to
learn how to get past this hurdle so I can motor up to the next hurdle.
There's a lot of learning on my part, and client pressure to start producing
analytical results.

Rich

2

On Wed, 27 Jul 2011, Micha Silver wrote:

Not sure what you mean by this. WHy not just abandon the DBF format altogether?

Micha,

   That's what I thought I had done.

First create a new LOCATION and MAPSET, then, *before* importing any
spatial data, run your db.connect command (and db.login also). Then import
your vector data. This way *all* attribute tables will be in PostgreSQL,
some will be attributes for GRASS vectors and some will be "just"
non-spatial data. You won't have to deal with DBF at all.

   This is what I thought I did. When I look at the contents of the
../PERMANENT/dbf/ directory, nothing's there. When I look at
../PERMANENT/vector/ I see all 54 maps. Looking at the tables in the
postgres database, all those maps are there, plus an additional 27
non-spatial data tables.

   The PERMANENT/ mapset has state-wide entents. I created a new mapset
specific to this project and I want to copy both the DEM (the only raster
map) and vector maps (as needed) to the project mapset and define a smaller
extent for them. This is where I ran into blocks that I reported in my
original message. And I don't use GRASS sufficiently frequently that I
remail fluent in its subtleties so I have not worked out a solution on my
own.

   The county_bnd map is one example. I can provide specific steps I take and
the results when they fail if that would help diagnose what I'm doing
incorrectly.

Thanks,

Rich