[GRASS-user] db.out.ogr: Syntax Correction
rshepard at appl-ecosys.com
Sat Mar 12 12:50:56 EST 2011
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...
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
> 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:
> 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:
> # 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
> # 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).
More information about the grass-user