[GRASS5] Built-in vector documentation extended

neteler · March 16, 2006, 9:35pm

Hi,

I have extended the vector overview document in
6.1-CVS, find also here:

http://grass.itc.it/grass61/manuals/html61_user/vectorintro.html

While it covers most modules, each now in a thematic
context, it may be fine tuned, improved.
Text pieces welcome (preferably CVS patches).

The idea is to give a short overview.

Currently the page is even W3 conformant

Cheers

Markus

cmbarton · March 17, 2006, 4:39pm

Markus,

This is very helpful. It will make learning GRASS vector architecture much
easier for people.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Thu, 16 Mar 2006 22:35:22 +0100
To: grass developers list <grass5@grass.itc.it>
Cc: GRASS user list <grasslist@baylor.edu>
Subject: [GRASS5] Built-in vector documentation extended

Hi,

I have extended the vector overview document in
6.1-CVS, find also here:

http://grass.itc.it/grass61/manuals/html61_user/vectorintro.html

While it covers most modules, each now in a thematic
context, it may be fine tuned, improved.
Text pieces welcome (preferably CVS patches).

The idea is to give a short overview.

Currently the page is even W3 conformant

Cheers

Markus

Thomas_Adams2 · March 17, 2006, 5:37pm

Michael,

This is very helpful and answers many questions I have about the new vector format, especially points. I do want to confirm my understanding from "Vector data processing in GRASS GIS" (please pardon my being obtuse). So…

In order to get a Postgres table consisting of point coordinates and various attributes to import into my lat-long location using v.in.db, I had to put a "1" in the field for the "category column name (string required)"; when I put "lid" in the field, I got an error saying the type was not an integer. It seems GRASS is expecting a string for the field name that has integer as its type. My problem is that none of my fields meet this requirement for the key field, the only column that does, "lid", has type string.

Now, my question is, for 5030 records, how do I add an integer key field? My guess is that I would have to write a script that (1) created a new column (type integer) for the Postgres table and (2) looped, sequentially filling the new field for each record with a unique integer value — or I could drop the table, and do all of this outside of the Postgres/GRASS environment and reload the table. The problem I have with doing either is that the table design is not my own and is controlled by 'outsiders'.

Regards,
Tom

Michael Barton wrote:

Markus,

This is very helpful. It will make learning GRASS vector architecture much
easier for people.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Thu, 16 Mar 2006 22:35:22 +0100
To: grass developers list <grass5@grass.itc.it>
Cc: GRASS user list <grasslist@baylor.edu>
Subject: [GRASS5] Built-in vector documentation extended

Hi,

I have extended the vector overview document in
6.1-CVS, find also here:

http://grass.itc.it/grass61/manuals/html61_user/vectorintro.html

While it covers most modules, each now in a thematic
context, it may be fine tuned, improved.
Text pieces welcome (preferably CVS patches).

The idea is to give a short overview.

Currently the page is even W3 conformant

Cheers

Markus

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

cmbarton · March 17, 2006, 5:43pm

Thomas,

See below.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Thomas Adams <Thomas.Adams@noaa.gov>
Date: Fri, 17 Mar 2006 12:37:20 -0500
To: Michael Barton <michael.barton@asu.edu>
Cc: Markus Neteler <neteler@itc.it>, grass developers list
<grass5@grass.itc.it>, Multiple recipients of list <grasslist@baylor.edu>
Subject: Re: [GRASS5] Built-in vector documentation extended

Michael,

This is very helpful and answers many questions I have about the new
vector format, especially points. I do want to confirm my understanding
from "Vector data processing in GRASS GIS" (please pardon my being
obtuse). SoŠ

In order to get a Postgres table consisting of point coordinates and
various attributes to import into my lat-long location using v.in.db, I
had to put a "1" in the field for the "category column name (string
required)"; when I put "lid" in the field, I got an error saying the
type was not an integer. It seems GRASS is expecting a string for the
field name that has integer as its type. My problem is that none of my
fields meet this requirement for the key field, the only column that
does, "lid", has type string.

The GRASS vector key field ("category") MUST be an integer. The matching key
field in your attribute table must also be integer to make a join.

Now, my question is, for 5030 records, how do I add an integer key
field? My guess is that I would have to write a script that (1) created
a new column (type integer) for the Postgres table and (2) looped,
sequentially filling the new field for each record with a unique integer
value ‹ or I could drop the table, and do all of this outside of the
Postgres/GRASS environment and reload the table. The problem I have with
doing either is that the table design is not my own and is controlled by
'outsiders'.

Use v.category to do this in GRASS.

Michael

Regards,
Tom

Michael Barton wrote:

Markus,

This is very helpful. It will make learning GRASS vector architecture much
easier for people.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Thu, 16 Mar 2006 22:35:22 +0100
To: grass developers list <grass5@grass.itc.it>
Cc: GRASS user list <grasslist@baylor.edu>
Subject: [GRASS5] Built-in vector documentation extended

Hi,

I have extended the vector overview document in
6.1-CVS, find also here:

http://grass.itc.it/grass61/manuals/html61_user/vectorintro.html

While it covers most modules, each now in a thematic
context, it may be fine tuned, improved.
Text pieces welcome (preferably CVS patches).

The idea is to give a short overview.

Currently the page is even W3 conformant

Cheers

Markus

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

David_Finlayson · March 17, 2006, 5:31am

Currently, the documentation does not contain graphics or tables (is
this true?). Would it be possible to add graphics?

For example, in this page it might be useful to diagram the
relationship between the geometry file and the RDBMS table(s) via the
category key.

In other modules (hydraulic ones for example), it would be useful to
show how flow moves from cell-to-cell or how a moving kernel sweeps
across the rasters, etc.

David

On 3/16/06, Markus Neteler <neteler@itc.it> wrote:

Hi,

I have extended the vector overview document in
6.1-CVS, find also here:

http://grass.itc.it/grass61/manuals/html61_user/vectorintro.html

While it covers most modules, each now in a thematic
context, it may be fine tuned, improved.
Text pieces welcome (preferably CVS patches).

The idea is to give a short overview.

Currently the page is even W3 conformant

Cheers

Markus

--
David Finlayson

David_Finlayson · March 17, 2006, 7:31am

I answered my own question:

From grass-6.cvs/doc/html_documentation.txt:

- modules:
   - write a file 'description.html' (see other modules for how to do that)
   - you can add figures (PNG format), the figure name prefix
     should be the module name

On 3/16/06, David Finlayson <david.p.finlayson@gmail.com> wrote:

Currently, the documentation does not contain graphics or tables (is
this true?). Would it be possible to add graphics?

For example, in this page it might be useful to diagram the
relationship between the geometry file and the RDBMS table(s) via the
category key.

In other modules (hydraulic ones for example), it would be useful to
show how flow moves from cell-to-cell or how a moving kernel sweeps
across the rasters, etc.

David

On 3/16/06, Markus Neteler <neteler@itc.it> wrote:
> Hi,
>
> I have extended the vector overview document in
> 6.1-CVS, find also here:
>
> http://grass.itc.it/grass61/manuals/html61_user/vectorintro.html
>
> While it covers most modules, each now in a thematic
> context, it may be fine tuned, improved.
> Text pieces welcome (preferably CVS patches).
>
> The idea is to give a short overview.
>
> Currently the page is even W3 conformant
>
> Cheers
>
> Markus
>
>

--
David Finlayson

--
David Finlayson

neteler · March 17, 2006, 9:40am

On 3/16/06, David Finlayson <david.p.finlayson@gmail.com> wrote:

Currently, the documentation does not contain graphics or tables (is
this true?). Would it be possible to add graphics?

It depends, a couple of modules come with images (so, yes,
possible and desired for interesting cases):

cd $GISBASE/docs/html/

l *.png
-rw-rw-r-- 1 neteler ssi 11718 Mar 15 23:50 photo.camera.png
-rw-rw-r-- 1 neteler ssi 618 Mar 15 23:50 rterraflow_dir3.png
-rw-rw-r-- 1 neteler ssi 403 Mar 15 23:50 rterraflow_dir2.png
-rw-rw-r-- 1 neteler ssi 55502 Mar 15 23:51 d_polar_aspect.png
-rw-rw-r-- 1 neteler ssi 3267 Mar 15 23:51 d.out.png
...

So, photo.camera, r.terraflow, d.polar and others already
have images. We should take care to not insert big files.

For example, in this page it might be useful to diagram the
relationship between the geometry file and the RDBMS table(s) via the
category key.

Sounds to be useful.

In other modules (hydraulic ones for example), it would be useful to
show how flow moves from cell-to-cell or how a moving kernel sweeps
across the rasters, etc.

Contributions are welcome (as always)!

Markus

neteler · March 17, 2006, 10:21am

David Finlayson wrote:

I answered my own question:

From grass-6.cvs/doc/html_documentation.txt:

- modules:
  - write a file 'description.html' (see other modules for how to do that)
  - you can add figures (PNG format), the figure name prefix
    should be the module name

BTW: A suggestion: Please keep the HTML tags simple (all pages are
handcrafted
currently). Some HTML editors tend to add tons of useless tags, fonts, ...

Markus

Thomas_Adams2 · March 17, 2006, 7:55pm

Michael,

Your instructions did not help... I'm sorry to be a bother about this, so, I'll restate the problem I'm having.

I have a Postgres database with a table called 'location', which consists of meteorological observation points with lat-long coordinates along with various other attributes:

Please notice that only one field is type integer, namely, the 'post' field; it is a boolean (1 or 0).

When I use the GRASS v.in.db command:

v.in.db driver=pg database=host=dell3-tir,dbname=hd_ob6tir table=location x=-1*lon y=lat z=elev key=1 where=rfc='OHRFC' output=locations

I am forced to supply key=???; the only thing that works for me is key=0 or key=1, etc. since I have no integer field with unique integer values. If I run v.in.db (above), I get:

GRASS_INFO_MESSAGE(19616,1): 5030 points written to vector
Building topology ...egistering lines: 1000 2000 3000 4000 5000
5030 primitives registered
Building areas:

0 areas built
0 isles built
Attaching islands:
Attaching centroids:
Topology was built.
Number of nodes : 4729
Number of primitives: 5030
Number of points : 5030
Number of lines : 0
Number of boundaries: 0
Number of centroids : 0
Number of areas : 0
Number of isles : 0

GRASS_INFO_MESSAGE(19616,2): Vector import complete

Which, I guess, looks OK. If I then use v.category:

v.category input=locations output=locations_new type=point,line,boundary,centroid,area option=add cat=1 layer=1 step=1
DBMI-Postgres driver error:
Cannot create index:
create unique index locations_new_1 on locations_new ( 1 )
ERROR: syntax error at or near "1" at character 56

GRASS_INFO_WARNING(19064,1): Cannot create index
0 new centroids placed in output map
Building topology ...egistering lines: 1000 2000 3000 4000 5000
5030 primitives registered
Building areas:

0 areas built
0 isles built
Attaching islands:
Attaching centroids:
Topology was built.

Number of nodes : 4729
Number of primitives: 5030
Number of points : 5030
Number of lines : 0
Number of boundaries: 0
Number of centroids : 0
Number of areas : 0
Number of isles : 0

Which has errors, and does nothing for solving my problem. If I use the GRASS query tool for the 'locations' or my newly created 'locations_new' vector maps, the x,y,z data is correct from v.in.db, but all the category data is the same, namely, for the first record of my Postgres table.

Consequently, trying to re-project the points into a LCC location using v.proj fails. Not to mention the fact that all the attribute data for my points in my lat-long location is useless because it's all the same.

How do I deal with this? Your help is appreciated.

Regards,
Tom

Michael Barton wrote:

Thomas,

See below.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Thomas Adams <Thomas.Adams@noaa.gov>
Date: Fri, 17 Mar 2006 12:37:20 -0500
To: Michael Barton <michael.barton@asu.edu>
Cc: Markus Neteler <neteler@itc.it>, grass developers list
<grass5@grass.itc.it>, Multiple recipients of list <grasslist@baylor.edu>
Subject: Re: [GRASS5] Built-in vector documentation extended

Michael,

This is very helpful and answers many questions I have about the new
vector format, especially points. I do want to confirm my understanding
from "Vector data processing in GRASS GIS" (please pardon my being
obtuse). SoŠ

In order to get a Postgres table consisting of point coordinates and
various attributes to import into my lat-long location using v.in.db, I
had to put a "1" in the field for the "category column name (string
required)"; when I put "lid" in the field, I got an error saying the
type was not an integer. It seems GRASS is expecting a string for the
field name that has integer as its type. My problem is that none of my
fields meet this requirement for the key field, the only column that
does, "lid", has type string.

The GRASS vector key field ("category") MUST be an integer. The matching key
field in your attribute table must also be integer to make a join.

Now, my question is, for 5030 records, how do I add an integer key
field? My guess is that I would have to write a script that (1) created
a new column (type integer) for the Postgres table and (2) looped,
sequentially filling the new field for each record with a unique integer
value ‹ or I could drop the table, and do all of this outside of the
Postgres/GRASS environment and reload the table. The problem I have with
doing either is that the table design is not my own and is controlled by
'outsiders'.

Use v.category to do this in GRASS.

Michael

Regards,
Tom

Michael Barton wrote:


Markus,

This is very helpful. It will make learning GRASS vector architecture much
easier for people.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Thu, 16 Mar 2006 22:35:22 +0100
To: grass developers list <grass5@grass.itc.it>
Cc: GRASS user list <grasslist@baylor.edu>
Subject: [GRASS5] Built-in vector documentation extended

Hi,

I have extended the vector overview document in
6.1-CVS, find also here:

http://grass.itc.it/grass61/manuals/html61_user/vectorintro.html

While it covers most modules, each now in a thematic
context, it may be fine tuned, improved.
Text pieces welcome (preferably CVS patches).

The idea is to give a short overview.

Currently the page is even W3 conformant

Cheers

Markus

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

neteler · March 17, 2006, 8:08pm

Thomas,

On Fri, Mar 17, 2006 at 02:55:52PM -0500, Thomas Adams wrote:

Michael,

Your instructions did not help... I'm sorry to be a bother about this,
so, I'll restate the problem I'm having.

I have a Postgres database with a table called 'location', which
consists of meteorological observation points with lat-long coordinates
along with various other attributes:

CHARACTER|lid
CHARACTER|county
CHARACTER|coe
CHARACTER|cpm
CHARACTER|detail
DOUBLE PRECISION|elev
CHARACTER|hdatum
CHARACTER|hsa
CHARACTER|hu
DOUBLE PRECISION|lat
DOUBLE PRECISION|lon
CHARACTER|lremark
DATE|lrevise
CHARACTER|name
CHARACTER|network
CHARACTER|rb
CHARACTER|rfc
DATE|sbd
CHARACTER|sn
CHARACTER|state
CHARACTER|waro
CHARACTER|wfo
CHARACTER|wsfo
CHARACTER|type
CHARACTER|des
CHARACTER|det
INTEGER|post
CHARACTER|stntype
CHARACTER|tzone

Please notice that only one field is type integer, namely, the 'post'
field; it is a boolean (1 or 0).

... so 'post' is unsuitable. key must be an unique ID column.

When I use the GRASS v.in.db command:

v.in.db driver=pg database=host=dell3-tir,dbname=hd_ob6tir
table=location x=-1*lon y=lat z=elev key=1 where=rfc='OHRFC'
output=locations

Funny, that v.in.db accepts this input:

database=host=dell3-tir,dbname=hd_ob6tir
-> database="host=dell3-tir,dbname=hd_ob6tir"

x=-1*lon
-> x=lon (what does -1*lon mean? The command wants a column *name*)

key=1
-> key=columname (apparently you don't have a column with unique
ID, so you will have to add one with
ALTER TABLE ..., see db.execute)

I am forced to supply key=???; the only thing that works for me is key=0
or key=1, etc. since I have no integer field with unique integer values.

If you don't have it, you will have to modify the table.
There is no other way IMHO.

All which is done here it telling v.in.db how the columns are named.
Any calculation must be done beforehand in the table, using SQL
or other ways (depends on the data storage).

Apparently the manual page of v.in.db is unclear, I would appreciate
suggestions how to improve it.

Markus

Thomas_Adams2 · March 17, 2006, 8:45pm

Markus,

Great! Thank you very much (now I know I'm not insane, well... as it relates to this topic anyhow). This is the conclusion I had come to, that is, that I needed to change the Postgres table. My problem is that the Postgres table schema is not under my control, so I'll have to create a new one.

You asked about:

x=-1*lon
-> x=lon (what does -1*lon mean? The command wants a column *name*)

Pretty funny actually, in the 'wisdom' of the database designers, they assumed the longitude would always be in the Western Hemisphere at least for the *application* of the database values. So, negative longitude values can not be used. The "x=-1*lon", as it turns out, actually will convert the positive longitude values to negative in the SQL query -- it works.

Cheers!
Tom

Markus Neteler wrote:

Thomas,

On Fri, Mar 17, 2006 at 02:55:52PM -0500, Thomas Adams wrote:


Michael,

Your instructions did not help... I'm sorry to be a bother about this, so, I'll restate the problem I'm having.

I have a Postgres database with a table called 'location', which consists of meteorological observation points with lat-long coordinates along with various other attributes:

CHARACTER|lid
CHARACTER|county
CHARACTER|coe
CHARACTER|cpm
CHARACTER|detail
DOUBLE PRECISION|elev
CHARACTER|hdatum
CHARACTER|hsa
CHARACTER|hu
DOUBLE PRECISION|lat
DOUBLE PRECISION|lon
CHARACTER|lremark
DATE|lrevise
CHARACTER|name
CHARACTER|network
CHARACTER|rb
CHARACTER|rfc
DATE|sbd
CHARACTER|sn
CHARACTER|state
CHARACTER|waro
CHARACTER|wfo
CHARACTER|wsfo
CHARACTER|type
CHARACTER|des
CHARACTER|det
INTEGER|post
CHARACTER|stntype
CHARACTER|tzone

Please notice that only one field is type integer, namely, the 'post' field; it is a boolean (1 or 0).

... so 'post' is unsuitable. key must be an unique ID column.

When I use the GRASS v.in.db command:

v.in.db driver=pg database=host=dell3-tir,dbname=hd_ob6tir table=location x=-1*lon y=lat z=elev key=1 where=rfc='OHRFC' output=locations

Funny, that v.in.db accepts this input:

database=host=dell3-tir,dbname=hd_ob6tir
-> database="host=dell3-tir,dbname=hd_ob6tir"

x=-1*lon
-> x=lon (what does -1*lon mean? The command wants a column *name*)

key=1
-> key=columname (apparently you don't have a column with unique
                  ID, so you will have to add one with ALTER TABLE ..., see db.execute)

I am forced to supply key=???; the only thing that works for me is key=0 or key=1, etc. since I have no integer field with unique integer values.

If you don't have it, you will have to modify the table.
There is no other way IMHO.

All which is done here it telling v.in.db how the columns are named.
Any calculation must be done beforehand in the table, using SQL
or other ways (depends on the data storage).

Apparently the manual page of v.in.db is unclear, I would appreciate
suggestions how to improve it.

Markus

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

cmbarton · March 17, 2006, 10:27pm

Thomas,

You must have an integer key field. I looked in the v.in.db
documentation--generally a good idea. It says that for Postgres you can use
the object id in the following way.

2) Creating a map from PostGIS:
To extract coordinate values from PostGIS, functions have to be used:

v.in.db driver=pg database="host=myserver.itc.it,dbname=mydb,user=name" \
table=station x="x(geom)" y="y(geom)" z="z(geom)" key=id
out=meteostations

If an ID column is not not present in the PostgreSQL table, the 'object ID'
of PostgreSQL can be used. In this case set:

cat=OID

Otherwise you must create a key field. The key=# argument is for you to
specify which field in your data table will serve as the key field. You are
putting in an integer VALUE rather than the name of a column in your table.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Thomas Adams <Thomas.Adams@noaa.gov>
Date: Fri, 17 Mar 2006 14:55:52 -0500
To: Michael Barton <michael.barton@asu.edu>
Cc: Markus Neteler <neteler@itc.it>, Multiple recipients of list
<grasslist@baylor.edu>
Subject: Re: [GRASS5] Built-in vector documentation extended

Michael,

Your instructions did not help... I'm sorry to be a bother about this,
so, I'll restate the problem I'm having.

I have a Postgres database with a table called 'location', which
consists of meteorological observation points with lat-long coordinates
along with various other attributes:

CHARACTER|lid
CHARACTER|county
CHARACTER|coe
CHARACTER|cpm
CHARACTER|detail
DOUBLE PRECISION|elev
CHARACTER|hdatum
CHARACTER|hsa
CHARACTER|hu
DOUBLE PRECISION|lat
DOUBLE PRECISION|lon
CHARACTER|lremark
DATE|lrevise
CHARACTER|name
CHARACTER|network
CHARACTER|rb
CHARACTER|rfc
DATE|sbd
CHARACTER|sn
CHARACTER|state
CHARACTER|waro
CHARACTER|wfo
CHARACTER|wsfo
CHARACTER|type
CHARACTER|des
CHARACTER|det
INTEGER|post
CHARACTER|stntype
CHARACTER|tzone

Please notice that only one field is type integer, namely, the 'post'
field; it is a boolean (1 or 0).

When I use the GRASS v.in.db command:

v.in.db driver=pg database=host=dell3-tir,dbname=hd_ob6tir
table=location x=-1*lon y=lat z=elev key=1 where=rfc='OHRFC'
output=locations

I am forced to supply key=???; the only thing that works for me is key=0
or key=1, etc. since I have no integer field with unique integer values.
If I run v.in.db (above), I get:

GRASS_INFO_MESSAGE(19616,1): 5030 points written to vector
Building topology ...egistering lines: 1000 2000 3000 4000 5000
5030 primitives registered
Building areas:

0 areas built
0 isles built
Attaching islands:
Attaching centroids:
Topology was built.
Number of nodes : 4729
Number of primitives: 5030
Number of points : 5030
Number of lines : 0
Number of boundaries: 0
Number of centroids : 0
Number of areas : 0
Number of isles : 0

GRASS_INFO_MESSAGE(19616,2): Vector import complete

Which, I guess, looks OK. If I then use v.category:

v.category input=locations output=locations_new
type=point,line,boundary,centroid,area option=add cat=1 layer=1 step=1
DBMI-Postgres driver error:
Cannot create index:
create unique index locations_new_1 on locations_new ( 1 )
ERROR: syntax error at or near "1" at character 56

GRASS_INFO_WARNING(19064,1): Cannot create index
0 new centroids placed in output map
Building topology ...egistering lines: 1000 2000 3000 4000 5000
5030 primitives registered
Building areas:

0 areas built
0 isles built
Attaching islands:
Attaching centroids:
Topology was built.

Number of nodes : 4729
Number of primitives: 5030
Number of points : 5030
Number of lines : 0
Number of boundaries: 0
Number of centroids : 0
Number of areas : 0
Number of isles : 0

Which has errors, and does nothing for solving my problem. If I use the
GRASS query tool for the 'locations' or my newly created 'locations_new'
vector maps, the x,y,z data is correct from v.in.db, but all the
category data is the same, namely, for the first record of my Postgres
table.

Consequently, trying to re-project the points into a LCC location using
v.proj fails. Not to mention the fact that all the attribute data for my
points in my lat-long location is useless because it's all the same.

How do I deal with this? Your help is appreciated.

Regards,
Tom

Michael Barton wrote:

Thomas,

See below.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Thomas Adams <Thomas.Adams@noaa.gov>
Date: Fri, 17 Mar 2006 12:37:20 -0500
To: Michael Barton <michael.barton@asu.edu>
Cc: Markus Neteler <neteler@itc.it>, grass developers list
<grass5@grass.itc.it>, Multiple recipients of list <grasslist@baylor.edu>
Subject: Re: [GRASS5] Built-in vector documentation extended

Michael,

This is very helpful and answers many questions I have about the new
vector format, especially points. I do want to confirm my understanding
from "Vector data processing in GRASS GIS" (please pardon my being
obtuse). SoŠ

In order to get a Postgres table consisting of point coordinates and
various attributes to import into my lat-long location using v.in.db, I
had to put a "1" in the field for the "category column name (string
required)"; when I put "lid" in the field, I got an error saying the
type was not an integer. It seems GRASS is expecting a string for the
field name that has integer as its type. My problem is that none of my
fields meet this requirement for the key field, the only column that
does, "lid", has type string.

The GRASS vector key field ("category") MUST be an integer. The matching key
field in your attribute table must also be integer to make a join.

Now, my question is, for 5030 records, how do I add an integer key
field? My guess is that I would have to write a script that (1) created
a new column (type integer) for the Postgres table and (2) looped,
sequentially filling the new field for each record with a unique integer
value ‹ or I could drop the table, and do all of this outside of the
Postgres/GRASS environment and reload the table. The problem I have with
doing either is that the table design is not my own and is controlled by
'outsiders'.

Use v.category to do this in GRASS.

Michael

Regards,
Tom

Michael Barton wrote:


Markus,

This is very helpful. It will make learning GRASS vector architecture much
easier for people.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Thu, 16 Mar 2006 22:35:22 +0100
To: grass developers list <grass5@grass.itc.it>
Cc: GRASS user list <grasslist@baylor.edu>
Subject: [GRASS5] Built-in vector documentation extended

Hi,

I have extended the vector overview document in
6.1-CVS, find also here:

http://grass.itc.it/grass61/manuals/html61_user/vectorintro.html

While it covers most modules, each now in a thematic
context, it may be fine tuned, improved.
Text pieces welcome (preferably CVS patches).

The idea is to give a short overview.

Currently the page is even W3 conformant

Cheers

Markus

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

neteler · March 20, 2006, 7:55am

Michael Barton wrote:

Thomas,

You must have an integer key field. I looked in the v.in.db
documentation--generally a good idea. It says that for Postgres you can use
the object id in the following way.

2) Creating a map from PostGIS:
To extract coordinate values from PostGIS, functions have to be used:

v.in.db driver=pg database="host=myserver.itc.it,dbname=mydb,user=name" \
table=station x="x(geom)" y="y(geom)" z="z(geom)" key=id
out=meteostations

If an ID column is not not present in the PostgreSQL table, the 'object ID'
of PostgreSQL can be used. In this case set:

cat=OID

Otherwise you must create a key field. The key=# argument is for you to
specify which field in your data table will serve as the key field. You are
putting in an integer VALUE rather than the name of a column in your table.

Michael,

I had some troubles recently to use OID (that's why I removed this hint
from the manual
page). Maybe this is better?

ALTER TABLE mytable ADD id integer;
CREATE SEQUENCE mytabe_seq;
UPDATE mytabe SET id= nextval('mytable_seq');
SELECT * from mytable;

Markus

neteler · March 20, 2006, 10:43am

On Mon, Mar 20, 2006 at 08:55:52AM +0100, Markus Neteler wrote:

I had some troubles recently to use OID (that's why I removed this hint
from the manual
page). Maybe this is better?

ALTER TABLE mytable ADD id integer;
CREATE SEQUENCE mytabe_seq;
UPDATE mytabe SET id= nextval('mytable_seq');
SELECT * from mytable;

added to

http://grass.itc.it/grass61/manuals/html61_user/pg.html

Markus

Thomas_Adams2 · March 20, 2006, 2:19pm

Markus,

Thanks for your help and suggestions. I discussed the matter with someone in my office (Mark Fenbers) who is fairly adept with database systems, in general, and PostgreSQL, in particular. He suggested that we create a "View" which allows one to create *essentially* a virtual table, combining elements from one or many tables. Thus:

CREATE OR REPLACE VIEW /my_table_new /AS SELECT oid AS uid,* FROM /my_table/;

Parts in red are optional. Parts in italics are to be replaced with the name of your table. This uses the /oid/ as the required integer field, which, in this example, was named /uid/ as a new column in the VIEW. Consequently, v.in.db would use table=/my_table_new / and key=/uid/.

The advantage to using a VIEW, is that any changes to /my_table /will be reflected automatically in /my_table_new/. So, only one table needs to be maintained. I have tested this in GRASS 6.1cvs and it works perfectly. The problem I was having is that I could NOT alter the original table and I needed a solution to the problem that accounted for dynamic changes to the table I was reading.

Regards,
Tom

Markus Neteler wrote:

On Mon, Mar 20, 2006 at 08:55:52AM +0100, Markus Neteler wrote:

I had some troubles recently to use OID (that's why I removed this hint
from the manual
page). Maybe this is better?

ALTER TABLE mytable ADD id integer;
CREATE SEQUENCE mytabe_seq;
UPDATE mytabe SET id= nextval('mytable_seq');
SELECT * from mytable;

added to

http://grass.itc.it/grass61/manuals/html61_user/pg.html

Markus

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033