Details Ticket 4343


Comment | Reply | Take | Resolve


Serial Number 4343
Subject db.in.ascii: new module
Area wish6
Queue grass
Requestors hamish_nospam@yahoo.com
Owner none
Status open
Last User Contact Mon Jul 17 17:52:58 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Wed Jul 19 13:09:27 2006 (2 yr ago)
Created Wed Apr 26 12:54:16 2006 (2 yr ago)

Transaction History Ticket 4343


Wed, Apr 26 2006 12:54:16    Request created by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 26 Apr 2006 22:54:12 +1200
From Hamish <hamish_nospam@yahoo.com>
To grass-bugs@intevation.de
Subject Fw: [GRASSLIST:887] Re: v.segment
Message-Id <20060426225412.15de327e.hamish_nospam@yahoo.com>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
X-Spam-Level
[WISH6]

Begin forwarded message:

Date: Tue, 25 Apr 2006 22:42:06 -0700
From: Michael Barton
To: Hamish, Trevor Wiens
Cc: dylan beaudette, grasslist
Subject: [GRASSLIST:887] Re: v.segment


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
> Date: Wed, 26 Apr 2006 17:32:11 +1200
> 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


Wed, Apr 26 2006 14:02:25    Area changed to wish6 by hbowman  
Wed, Apr 26 2006 14:02:56    Subject changed to db.in.ascii: new module by hbowman  
Wed, Apr 26 2006 14:04:01    Comments added by hbowman  
v.in.ascii isn't limited to DBF AFAIK, and neither would a derivative db.in.ascii.
Hamish
Wed, Apr 26 2006 23:14:50    Mail sent by guest  
Hi,

to generate a DBF file from CSV ASCII, you can use

ogr2ogr:
http://www.gdal.org/ogr/drv_csv.html

Note that this driver accepts a .csvt file to describe the
column types (see there).

The resulting DBF can be then put copied with db.copy
to another, e.g. SQL based, table format (or use ogr2ogr).

Markus

PS: From the posting it's not really clear to me what for
db.in.ascii is desired.
Wed, May 10 2006 08:32:58    Comments added by hbowman  
there is a comment in the v.in.garmin script asking for it.


Hamish
Mon, Jul 17 2006 17:52:58    Mail sent by mneteler  
# "COPY table FROM 'filename.txt'" does not work for DBF and there is no
#   db.in.ascii yet, so we use a hack ...

...just run v.in.ogr with CSV driver, should work ok.
http://ogr.maptools.org/drv_csv.html

Don't miss the csvt file to describe the types.
I guess we can close the report.

Markus
Wed, Jul 19 2006 13:09:27    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 19 Jul 2006 23:09:19 +1200
From Hamish <hamish_nospam@yahoo.com>
To Markus Neteler via RT <grass-bugs@intevation.de>
Subject Re: [bug #4343] (grass) db.in.ascii: new module
Message-Id <20060719230919.1dbc96ed.hamish_nospam@yahoo.com>
In-Reply-To <20060717155258.0ED271006C7@lists.intevation.de>
References <20060717155258.0ED271006C7@lists.intevation.de>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-1.73 tagged_above=-999 required=3 tests=[AWL=1.175, BAYES_00=-5, FORGED_YAHOO_RCVD=2.095]
X-Spam-Level
> # "COPY table FROM 'filename.txt'" does not work for DBF and there is
> # no
> #   db.in.ascii yet, so we use a hack ...
> 
> ...just run v.in.ogr with CSV driver, should work ok.
> http://ogr.maptools.org/drv_csv.html
> 
> Don't miss the csvt file to describe the types.


the idea was to import tables without geo-columns. (no x,y)

see the v.in.garmin script, "### <hack>" section for an example.



Hamish


Comment | Reply | Take | Resolve

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request