On Sat, 12 Mar 2011, Micha Silver wrote:
The second line is just meant as a check that the attribs are indeed uploaded
to the PostgreSQL database...
Micha,
Makes sense but not blatantly obvious for us newcomers.
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
lines=0
boundaries=13
centroids=13
areas=13
islands=13
faces=0
kernels=0
primitives=26
map3d=0
v.info -c at_risk_species
GRASS 6.5.svn (Nevada-aea):~/grassdata > v.info -c at_risk_species
Displaying column types/names for database connection of layer 1:
INTEGER|cat
INTEGER|EO_ID_NUM
DOUBLE PRECISION|EO_NUM
CHARACTER|SNAME
CHARACTER|SCOMNAME
CHARACTER|ID_CONFIRM
CHARACTER|POP_COUNT
DOUBLE PRECISION|OBS_AREA_A
DOUBLE PRECISION|OBS_AREA_H
CHARACTER|SURVEYDATE
CHARACTER|FIRSTOBS
CHARACTER|LASTOBS
CHARACTER|BESTSOURCE
CHARACTER|DIRECTIONS
DOUBLE PRECISION|MIN_ELEV_F
DOUBLE PRECISION|MIN_ELEV_M
DOUBLE PRECISION|MAX_ELEV_F
DOUBLE PRECISION|MAX_ELEV_M
CHARACTER|LATITUDE
CHARACTER|LONGITUDE
CHARACTER|WETLAND
CHARACTER|SAND_DUNES
CHARACTER|IMAGE_EO
CHARACTER|IMAGE_TAX
CHARACTER|DIGITIZED
CHARACTER|DIGITIZER
CHARACTER|SHP_EDITED
CHARACTER|EDIT_COM
CHARACTER|SHP_MOD
CHARACTER|SHP_MOD_BY
CHARACTER|MAPPED
CHARACTER|MAPPER
CHARACTER|MAP_QC
CHARACTER|SEP_COM
CHARACTER|P_MAPPED
CHARACTER|P_MAPPER
CHARACTER|CREATED
CHARACTER|CREATOR
CHARACTER|TSCRIBED
CHARACTER|TSCRIBER
CHARACTER|VERS_DATE
CHARACTER|VERS_AUTH
CHARACTER|REC_MOD
CHARACTER|REC_MOD_BY
The script above is a wrapper around v.out.ogr. If I understand correctly,
you want to have a new GRASS point vector with the data table held in
Postgres? So maybe v.out.ogr is the easier approach.
The theme has been successfully imported into GRASS from a Shapefile. Now,
all the statewide data are in the PERMANENT mapset. When I have everything
there I can create mapsets for each project and use only the relevant
portions of each theme. But, it seems to make more sense to keep all
attribute data in postgres rather than some in postgres and the rest in
GRASS. In addition to having all my eggs in one rdbms basket, I can remove
columns that have no relevance to me (such as many of those above that
might have meaning to the creating agency but not to us external users.)
For the record, I was trying to use db.out.ogr, not v.out.ogr.
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
attribute data so both geographic features and attribute data need to be
copied so there's a set of geographic features with attributes in postgres
and another set of features with attributes in dbf. Then running g.remove
takes both features and attributes from the original, dbf-hosted, version.
# Now test that the new tables exist:
psql -c 'SELECT * FROM <a vector>' -d <your_postgres_db> -U
<your_db_username>
# If everything looks OK, remove the old (dbf based) vectors
$ g.mremove vect="*_old"
This does seem more efficient than using db.out.ogr (which isn't working
for me and the reason I posted the thread origin).
Toda raba,
Rich
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
