[GRASSLIST:887] Re: v.segment

Michael Barton michael.barton at asu.edu
Wed Apr 26 01:42:06 EDT 2006


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 at yahoo.com>
> Date: Wed, 26 Apr 2006 17:32:11 +1200
> To: Trevor Wiens <twiens at interbaun.com>
> Cc: <dylan.beaudette at gmail.com>, <grasslist at baylor.edu>,
> <michael.barton at asu.edu>
> Subject: Re: [GRASSLIST:859] Re: v.segment
> 
>>> 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




More information about the grass-user mailing list