[GRASSLIST:6115] Re: Problem with d.vect.pg

[Bruno GUILLAUME]

This is a sum-up of the problem encountered with d.vect.pg:

I imported a sample of my own the same way as Michael suggests and it 
appears that I am also constrainted in the choice of the category 
(referenced as 'column' here) which can be used for a selection in the 
SELECT[column] of the sql file or in key=[column] of the d.vect.pg 
statement.

In fact, it is quite normal, because proceeding as we did, with v.to.pg, 
the categories are not imported in the PostGreSQL database !

Indeed, only 4 fields have been imported in the postgreSQL database:
- num which is of type 'integer' and corresponds to the number of the 
polygon,
- boundary which is of non native type 'polygon',
- id the identifier,
- and ex which is a boolean (what signification ?).

So it seems that it only imports the vector shape and not the database 
of categories that should b associated !

Otherwise, the 'pg.in.dbf' command is able to import the categories in 
the PostgreSQL database (in fact, that is what I did previously) but not 
in the same table as with 'v.to.pg' and then 'd.vect.pg' used with this 
new table does not know the concerned areas to map them !!

So, can anyone help ? Is there no possibility of importing the vector 
boundaries AND the vector categories together, in the same table of 
PostGreSQL database ? Is this problem solved in GRASS5.1 ?

Michael Ash wrote:

>>I use GRASS 5.0.1 and I encountered a problem with
>>d.vect.pg It sends the SQL request to the PostGreSQL
>>database without problem, it also returns the number of
>>rows that it has found in the database, but then it does
>>not display anything on the monitor.
>>
>>Has anybody encountered this problem? Is there a solution?
>>    
>>
>
>I am very glad that you asked this question because I, too,
>hope for some clarification on using the GRASS/PostGreSQL
>interface from GRASSLIST participants.
>
>As for your problem, is it possible that the column in the
>database table referenced either as key=[column] in the
>d.vect.pg statement or in the SELECT [column] of the sql
>file does not correspond to the vector category values for
>the map designated with map=[map] in the d.vect.pg
>statement?
>
>My understanding is that the SQL statement should return
>exactly one column of numbers that correspond to the the
>vector category values for the map designated with map=[map]
>in the d.vect.pg statement.
>
>I am attaching a script that I wrote that will
>1) import a m.in.e00 file
>2) correct dangles (necessary with the test data files)
>3) assign a useful connection between categories and names
>4) load the vector file into a postgresql database file
>5) run a simple query
>
>
>######################################################
># Import a .e00 and create a postgresql database table
># Assumes location has been created for North America
># Assumes both postgresql and the GRASS/postgresql connection
># are working and database has been selected
>
># Script imports a .e00 file from the U.S. Census
># http://www.census.gov/geo/www/cob/bdy_files.html
># http://www.census.gov/geo/www/cob/st2000.html
># Corrects the dangles (in Texas)
># Loads the vector file into a postgresql database for querying
>
>m.in.e00 input=st99_d00.e00 action=vector
>g.region.sh vector=st99_d00 nsres=0.1 ewres=0.1
>v.support -r map=st99_d00 err=err
>v.rm.dangles input=st99_d00 output=st99_d00.corrected
>cp ~/grass/usaLL/mash/dig_att/st99_d00 ~/grass/usaLL/mash/dig_att/st99_d00.corrected
>cp ~/grass/usaLL/mash/dig_cats/st99_d00.name ~/grass/usaLL/mash/dig_cats/st99_d00.corrected
>v.support -r map=st99_d00.corrected
>
># Create database table st99_d00_bnd (bnd assigned, for "boundary")
># Choose name of key column; I chose "id"
>v.to.pg -t tab=st99_d00 type=area map=st99_d00.corrected key=id
>
>g.table.pg
>g.column.pg table=st99_d00_bnd
>
># Select most of Maine
>d.vect.pg -f map=st99_d00.corrected tab=st99_d00_bnd key=id where='id=100' color=red
>
>######################################################
>
>
>
>Some requests for clarification:
>
>1. Which file in dig_cats contains the category values for
>[map]?  Sometimes the first category value appears to be "1"
>and sometimes "2". I think that I may be confused about
>feature-ID and feature-# , and whether I should use the "-i"
>option with m.in.e00.  The documentation seems to suggest
>that "-i" is more reliable for matching, but I got funny
>results (Nevada where California should be, for example)
>
>2. Is there an efficient way to load the categories that
>come with a .e00 file (and become separate files in
>dig_cats) into one or more database tables?  Without loading
>the more useful columns, e.g., name, the only possible
>selections are on the internal category ID, not very useful
>for joining with other data.
>
>
>  
>