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
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user

Reply via email to