Is there an efficient way to create an attribute table for point file
created with v.segment?
T
--
Trevor Wiens
twiens@interbaun.com
The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)
Use v.category to attach categories.
V.to.db to add information to attribute table? I don't know if this works
with v.segment output or not. In fact, I can't figure out how v.segment
works either.
Create a dbf file using a spreadsheet (OO or Excel -- OO works better). Call
the first column "cat", make it an integer, and fill it with a sequence of
numbers equal to the number of points you have. Then use v.db.connect to
link them up.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Trevor Wiens <twiens@interbaun.com>
Date: Mon, 24 Apr 2006 13:53:07 -0600
To: GRASSLIST <grasslist@baylor.edu>
Subject: [GRASSLIST:850] v.segmentIs there an efficient way to create an attribute table for point file
created with v.segment?T
--
Trevor Wiens
twiens@interbaun.comThe significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)
On Mon, 24 Apr 2006 23:00:15 -0700
Michael Barton <michael.barton@asu.edu> wrote:
Use v.category to attach categories.
V.to.db to add information to attribute table? I don't know if this works
with v.segment output or not. In fact, I can't figure out how v.segment
works either.Create a dbf file using a spreadsheet (OO or Excel -- OO works better). Call
the first column "cat", make it an integer, and fill it with a sequence of
numbers equal to the number of points you have. Then use v.db.connect to
link them up.
Michael,
Thanks, but not really what I wanted to hear.
I wrote a script to make stops on Breeding Bird Survey route lines at
equal intervals, and manipulated the category values to be meaningful.
Unfortunately, v.segment doesn't create an attribute table so I used
v.build with the cdump option to get a list of the categories and then
used db.execute to add them one by one into a table. Very slow.
I can see now I could get a list easier using v.category, but
unfortunately it won't automagically create an attribute table with the
categories in it.
I was hoping for an easy way to do this as it would make the script a
lot more elegant and faster, but it appears that my ugly hack is the
only solution.
Thanks
T
--
Trevor Wiens
twiens@interbaun.com
The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)
Trevor,
If you've got the cat values from v.build the main issue is to get them into
something that GRASS can recognize as an attribute table. You could simply
import them into a spreadsheet and export them as dbf. Then use
v.db.connect. Even better if there was a txt2dbf utility. Maybe someone
knows of one. Or you could try a MySQL or SQLite routine to get the data
into one of those formats.
However, if you want to script this you might try the following:
Redirect the stdout to a file datafile.csv
I think you'd need to add a field name line to the beginning
Replace all the "|" with "," using sed
Use v.in.ogr to read in the csv file
Use v.db.connect to the new attribute file.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Trevor Wiens <twiens@interbaun.com>
Date: Tue, 25 Apr 2006 00:26:41 -0600
To: Michael Barton <michael.barton@asu.edu>
Cc: Multiple recipients of list <grasslist@baylor.edu>
Subject: Re: [GRASSLIST:855] Re: v.segmentOn Mon, 24 Apr 2006 23:00:15 -0700
Michael Barton <michael.barton@asu.edu> wrote:Use v.category to attach categories.
V.to.db to add information to attribute table? I don't know if this works
with v.segment output or not. In fact, I can't figure out how v.segment
works either.Create a dbf file using a spreadsheet (OO or Excel -- OO works better). Call
the first column "cat", make it an integer, and fill it with a sequence of
numbers equal to the number of points you have. Then use v.db.connect to
link them up.Michael,
Thanks, but not really what I wanted to hear.
I wrote a script to make stops on Breeding Bird Survey route lines at
equal intervals, and manipulated the category values to be meaningful.Unfortunately, v.segment doesn't create an attribute table so I used
v.build with the cdump option to get a list of the categories and then
used db.execute to add them one by one into a table. Very slow.I can see now I could get a list easier using v.category, but
unfortunately it won't automagically create an attribute table with the
categories in it.I was hoping for an easy way to do this as it would make the script a
lot more elegant and faster, but it appears that my ugly hack is the
only solution.Thanks
T
--
Trevor Wiens
twiens@interbaun.comThe significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)
Trevor,
not sure if this would do what you want, but I made a module called d.bearing for the creation of transects, with some notes on dividing up the main line segment into points along that line:
http://casoilresource.lawr.ucdavis.edu/drupal/node/149
cheers,
Dylan
On Apr 24, 2006, at 11:26 PM, Trevor Wiens wrote:
On Mon, 24 Apr 2006 23:00:15 -0700
Michael Barton <michael.barton@asu.edu> wrote:Use v.category to attach categories.
V.to.db to add information to attribute table? I don't know if this works
with v.segment output or not. In fact, I can't figure out how v.segment
works either.Create a dbf file using a spreadsheet (OO or Excel -- OO works better). Call
the first column "cat", make it an integer, and fill it with a sequence of
numbers equal to the number of points you have. Then use v.db.connect to
link them up.Michael,
Thanks, but not really what I wanted to hear.
I wrote a script to make stops on Breeding Bird Survey route lines at
equal intervals, and manipulated the category values to be meaningful.Unfortunately, v.segment doesn't create an attribute table so I used
v.build with the cdump option to get a list of the categories and then
used db.execute to add them one by one into a table. Very slow.I can see now I could get a list easier using v.category, but
unfortunately it won't automagically create an attribute table with the
categories in it.I was hoping for an easy way to do this as it would make the script a
lot more elegant and faster, but it appears that my ugly hack is the
only solution.Thanks
T
--
Trevor Wiens
twiens@interbaun.comThe significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341
On Tue, 25 Apr 2006 08:32:13 -0700
Dylan Beaudette <dylan.beaudette@gmail.com> wrote:
Trevor,
not sure if this would do what you want, but I made a module called
d.bearing for the creation of transects, with some notes on dividing up
the main line segment into points along that line:
Dylan,
Thanks for the link. I may use it in the future. I modified my script
to use. v.categories to add the category information (it was cleaner
than using v.build). Making the stops with v.segment is fast. The slow
part was building the attribute table at the end. It is still a bit slow
(1 - 2 minutes for every 1000 points on my fairly new AMD box) but
works. v.segment was great because the BBS (Breeding Bird Survey)
routes are not straight, but follow road lines. They digitized the
routes, but didn't have the stop information (observation locations), so
I needed to break them up and number them so I can relate the bird
information to the right piece of landscape. My solution wasn't
perfect, but the day it took to figure it out was a lot quicker than
going out with GPS unit to 173 routes scatted across Alberta. My
v.makestops script needs some cleanup, but I will post it to the wiki
later. I think it is potentially useful for others.
Thanks
T
--
Trevor Wiens
twiens@interbaun.com
The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)
> not sure if this would do what you want, but I made a module called
> d.bearing for the creation of transects, with some notes on dividing
> up the main line segment into points along that line:
>
> http://casoilresource.lawr.ucdavis.edu/drupal/node/149
..
Thanks for the link. I may use it in the future. I modified my script
to use. v.categories to add the category information (it was cleaner
than using v.build). Making the stops with v.segment is fast. The slow
part was building the attribute table at the end. It is still a bit
slow (1 - 2 minutes for every 1000 points on my fairly new AMD box)
but works. v.segment was great because the BBS (Breeding Bird Survey)
routes are not straight, but follow road lines. They digitized the
routes, but didn't have the stop information (observation locations),
so I needed to break them up and number them so I can relate the bird
information to the right piece of landscape. My solution wasn't
perfect, but the day it took to figure it out was a lot quicker than
going out with GPS unit to 173 routes scatted across Alberta. My
v.makestops script needs some cleanup, but I will post it to the wiki
later. I think it is potentially useful for others.
Dylan, Trevor,
you may want to check out Radim's v.lrs.* modules new in CVS.
http://mpa.itc.it/radim/lrs/index.html
As for speeding up table filling, I think it is faster to write all
SQL statements to a file, then use just a single "db.execute input="
call. If this does speed it up significantly, let us know & we can add
the hint to db.execute help page. (insert "time" on the command line
before the command to benchmark)
Michael:
You could simply import them into a spreadsheet and export them as
dbf. Then use v.db.connect. Even better if there was a txt2dbf
utility. Maybe someone knows of one.
"db.in.ascii"
All the code to write it is already in v.in.ascii, see these threads:
http://thread.gmane.org/gmane.comp.gis.grass.user/6038
http://thread.gmane.org/gmane.comp.gis.grass.devel/5155
(I thought this was in the bug tracker already as a wish, guess not)
see also v.in.db.
Hamish
Hamish,
I followed this thread and was surprised to find my post as the last comment
(it WAS over 6 months ago...). I'll repeat it as it still is relevant...
For my 2 cent's worth, db.in.ascii is where a user would logically look
first to find a way to get an ascii file into the default dbf format. The
2nd most logical place to look (IMHO) would be v.in.ascii (with the flag
that you or someone else mentioned).
That said, making this doable anyplace is better than the current lack of
this functionality in a straightforward form.
Any chance to get this in before 6.2?
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Hamish <hamish_nospam@yahoo.com>
Date: Wed, 26 Apr 2006 17:32:11 +1200
To: Trevor Wiens <twiens@interbaun.com>
Cc: <dylan.beaudette@gmail.com>, <grasslist@baylor.edu>,
<michael.barton@asu.edu>
Subject: Re: [GRASSLIST:859] Re: v.segmentnot sure if this would do what you want, but I made a module called
d.bearing for the creation of transects, with some notes on dividing
up the main line segment into points along that line:..
Thanks for the link. I may use it in the future. I modified my script
to use. v.categories to add the category information (it was cleaner
than using v.build). Making the stops with v.segment is fast. The slow
part was building the attribute table at the end. It is still a bit
slow (1 - 2 minutes for every 1000 points on my fairly new AMD box)
but works. v.segment was great because the BBS (Breeding Bird Survey)
routes are not straight, but follow road lines. They digitized the
routes, but didn't have the stop information (observation locations),
so I needed to break them up and number them so I can relate the bird
information to the right piece of landscape. My solution wasn't
perfect, but the day it took to figure it out was a lot quicker than
going out with GPS unit to 173 routes scatted across Alberta. My
v.makestops script needs some cleanup, but I will post it to the wiki
later. I think it is potentially useful for others.Dylan, Trevor,
you may want to check out Radim's v.lrs.* modules new in CVS.
http://mpa.itc.it/radim/lrs/index.htmlAs for speeding up table filling, I think it is faster to write all
SQL statements to a file, then use just a single "db.execute input="
call. If this does speed it up significantly, let us know & we can add
the hint to db.execute help page. (insert "time" on the command line
before the command to benchmark)Michael:
You could simply import them into a spreadsheet and export them as
dbf. Then use v.db.connect. Even better if there was a txt2dbf
utility. Maybe someone knows of one."db.in.ascii"
All the code to write it is already in v.in.ascii, see these threads:
http://thread.gmane.org/gmane.comp.gis.grass.user/6038
http://thread.gmane.org/gmane.comp.gis.grass.devel/5155(I thought this was in the bug tracker already as a wish, guess not)
see also v.in.db.
Hamish
On Wed, 26 Apr 2006 17:32:11 +1200
Hamish <hamish_nospam@yahoo.com> wrote:
As for speeding up table filling, I think it is faster to write all
SQL statements to a file, then use just a single "db.execute input="
call. If this does speed it up significantly, let us know & we can add
the hint to db.execute help page. (insert "time" on the command line
before the command to benchmark)
I ran a test and it is much faster.
Using a temporary file including the time to write it and run the
insert command against PostgreSQL for 537 records was < 1 second.
Running each command individually against the same database for the
same 537 records took 18 seconds.
Definitely a hint should be placed in the db.execute help page.
Thanks
T
--
Trevor Wiens
twiens@interbaun.com
The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)
> As for speeding up table filling, I think it is faster to write all
> SQL statements to a file, then use just a single "db.execute input="
> call. If this does speed it up significantly, let us know & we can add
> the hint to db.execute help page. (insert "time" on the command line
> before the command to benchmark)I ran a test and it is much faster.
great.
Using a temporary file including the time to write it and run the
insert command against PostgreSQL for 537 records was < 1 second.Running each command individually against the same database for the
same 537 records took 18 seconds.Definitely a hint should be placed in the db.execute help page.
done.
Hamish