On 03/12/2011 07:50 PM, Rich Shepard wrote:
On Sat, 12 Mar 2011, Micha Silver wrote:
What do these show:
v.info -t at_risk_species
GRASS 6.5.svn (Nevada-aea):~/grassdata > v.info -t at_risk_species
nodes=26
points=0
This ^^^^^^ is why the first run "db.out.ogr" failed
lines=0
boundaries=13
centroids=13
areas=13
islands=13
faces=0
kernels=0
primitives=26
map3d=0
For the record, I was trying to use db.out.ogr, not v.out.ogr.
And with area features db.out.ogr won't work.
Furthermore, if you're going to change the whole project over to
database stored attribs, then the best method is to set the new
database connection for your mapset (db.connect + db.login) then just
run db.copy on all your vectors. All the new "copies" will have their
data tables in the (now default) database.
Having all attribute data in postgres will let me establish the db
connection and location as defaults and not worry about which
attribute data
are located where.
Something like:
$ for v in `g.mlist vect sep=space`; do g.rename vect=$v,$v_old; done
$ for v in `g.mlist vect sep=space pat="*_old"`; do g.copy
vect=$v,`basename $v _old`; done
# This should leave you with a set of dbf based vectors named like:
a_vector_old
# And a second set, postgres based, named like "a_vector"
If the vector files are already in GRASS and dbf, why do I need a
renamed
copy there? Perhaps it's because I cannot remove only the dbf-hosted
You won't need the renamed copy. Once you have a new set of GRASS
vectors with their attributes in postgres, chuck out the originals.
--
Micha Silver
Arava Development Co. +972-52-3665918
http://www.surfaces.co.il
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
