[GRASS-user] db.out.ogr: Syntax Correction

[Micha Silver]

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