Details Ticket 5478


Comment | Reply | Take | Open


Serial Number 5478
Subject v.in.gpsbabel broken for attributes
Area grass6
Queue grass
Requestors neteler@itc.it
Owner none
Status resolved
Last User Contact Sat May 12 12:34:19 2007 (1 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Sat May 12 12:34:19 2007 (1 yr ago)
Created Tue Feb 6 00:15:37 2007 (2 yr ago)

Transaction History Ticket 5478


Tue, Feb 6 2007 00:15:37    Request created by guest  
Subject: v.in.gpsbabel broken for attributes

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources

Hi,

I tried v.in.gpsbabel today, but:

v.in.gpsbabel -t in=/dev/ttyUSB0 format=garmin out=mytracks
Downloading Tracks from GPS
'style=/home/neteler/soft/63grass_cvsexp/dist.i686-pc-linux-gnu/etc/grass_write_ascii.style'
is an unknown option to gpx.
Attempting waypoint projection transform with cs2cs
Importing with v.in.ascii
WARNING: The vector 'mytracks' already exists and will be overwritten.
Building topology ...
104 primitives registered
Building areas:  100%
0 areas built
0 isles built
Attaching islands:
Attaching centroids:  100%
Topology was built.
Number of nodes     :   198
Number of primitives:   104
Number of points    :   0
Number of lines     :   104
Number of boundaries:   0
Number of centroids :   0
Number of areas     :   0
Number of isles     :   0
v.in.ascii complete.
v.in.gpsbabel: line vector "mytracks@neteler" successfully created
Creating new table..
Populating table with attributes..
DBMI-DBF driver error:
SQL parser error in statement:
INSERT INTO mytracks VALUES (1, ' ',  ,  , ' ',  , )

Error in db_execute_immediate()

ERROR: Error while executing: "INSERT INTO mytracks VALUES (1, ' ', , , '
       ', , )
       "
Connecting attribute table to vector file..
WARNING: The table <mytracks> is now part of vector map <mytracks> and may
         be deleted or overwritten by GRASS modules
WARNING: Select privileges were granted on the table

Done.

Apparently the style file is no longer accepted in this form when 
downloading tracks/routes from GPS.
http://www.gpsbabel.org/htmldoc-1.3.2/fmt_gpx.html
http://www.gpsbabel.org/htmldoc-development/fmt_custom.html

Markus
Thu, May 10 2007 14:32:24    Mail sent by hbowman  
Downloading Tracks from GPS
'style=/home/neteler/soft/63grass_cvsexp/dist.i686-pc-linux-gnu/etc/grass_write_ascii.style'
is an unknown option to gpx.


that should have caused the EXITCODE=$? to trigger a safe exit. (line 249)

does gpsbabel not exit with a non-zero status on error? (just checked, it
seems to)


can you recreate the gpsbabel line by hand?


indeed in my version of gpsbabel (1.2.7) --help doesn't list style= as an
option to GPX.

nor is it in the help page:
  http://www.gpsbabel.org/htmldoc-1.3.3/fmt_gpx.html

?????

what does "$TMP".gpx look like? does it even exist?


I don't have a GPS handy right now to test with.


Hamish
Thu, May 10 2007 14:42:16    Mail sent by mneteler  
This worked once but the gpsbabel folks have apparently changed their
software. Here seems to be some style documentation:

http://www.gpsbabel.org/htmldoc-development/style_intro2.html

In particular,
http://www.gpsbabel.org/htmldoc-development/styles_intro.html
suggests

 gpsbabel -i gpx -f mine.gpx -o xcsv,style=mystyle.style -f mine.new

for usage. Strange.

Markus
Thu, May 10 2007 14:52:19    Mail sent by mneteler  
In the current gpsbabel CVS, there is documented:

grep gpsbabel README | grep xcsv
        gpsbabel -i xcsv,style=foo.style -c latin1 -f foo
        gpsbabel -i xcsv,style=foo.style -f foo -o xcsv,style=bar.style -F bar
gpsbabel -s -i gpx -f foo.gpx -o xcsv,style=my.style,snlen=8 -F bar

and we use in v.in.gpsbabel:

 gpsbabel -w -i $GIS_OPT_FORMAT $GPSdevice $PROGVERBOSE -o xcsv,style="$STYLE"
-F "$TMP".gpst

 gpsbabel -r -i $GIS_OPT_FORMAT $GPSdevice $PROGVERBOSE -o gpx,style="$STYLE"
-F "$TMP".gpx
 
 gpsbabel -t -i $GIS_OPT_FORMAT $GPSdevice $PROGVERBOSE -o gpx,style="$STYLE"
-F "$TMP".gpx


I observe that the second and third have gpx,style. Bug?
Should be xcsv,style? If yes, an incredible bug.

In this moment also no GPS handy,

Markus
Thu, May 10 2007 22:59:59    Comments added by mneteler  
The 2nd and third should not have the style. Fixed in CVS.

Markus
Thu, May 10 2007 23:02:21    Comments added by mneteler  
HI,

I think I got v.in.gpsbabel for tracks and routes (did that
ever work?). However, I have a final problem which requires
a bit of awk magic:

The GPX tracks file extracted from my Garmin contains a track
which isn't attributed (I dunno why but that's life). The
v.in.gpsbabel scripts successfully creates the map, then fails
on creating the attrib table. Here the problem:


# note: files contains tab delimiters
head -2 12021.0.track_atts
1
2               45.417394638    10.847196579            45.359029770   
10.166580677


# make tab delim visible (just for illustration):
head -2 12021.0.track_atts | tr -s '\t' '|'
1 | | | | | |
2 | |45.417394638 |10.847196579 | |45.359029770 |10.166580677


# this is what happens in v.in.gpsbabel (note: it does cat instead of head):
head -2 12021.0.track_atts | awk -F'\t' '{ printf("echo \"INSERT INTO $NAME
VALUES (%d, ^%s^, %s, %s, ^%s^, %s, %s)\" |
+db.execute\n", $1, $2, $3, $4, $5, $6, $7) }' | tr '^' \'
echo "INSERT INTO $NAME VALUES (1, ' ',  ,  , ' ',  , )" | db.execute
echo "INSERT INTO $NAME VALUES (2, ' ', 45.417394638 , 10.847196579 , ' ',
45.359029770 , 10.166580677)" | db.execute


We see that the first line isn't valid SQL. The first line should be:
echo "INSERT INTO $NAME VALUES (1, ' ', NULL  , NULL , ' ', NULL , NULL)" |
db.execute

Question: what to ask in the awk line to autoinsert NULL if 0 length is
found in the numeric columns 3, 4, 6, 7?

thanks
Markus

Fri, May 11 2007 05:27:08    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 11 May 2007 15:18:36 +1200
From Hamish <hamish_nospam@yahoo.com>
To Markus Neteler via RT <grass-bugs@intevation.de>
Subject Re: [bug #5478] (grass) v.in.gpsbabel broken for attributes
Message-Id <20070511151836.71bda8e9.hamish_nospam@yahoo.com>
In-Reply-To <20070510125219.E9D6B101EE4@lists.intevation.de>
References <20070510125219.E9D6B101EE4@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, score=-3.151 tagged_above=-999 required=3.5 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=1.849]
X-Spam-Score -3.151
X-Spam-Level
Markus Neteler via RT wrote:
> In the current gpsbabel CVS, there is documented:
> 
> grep gpsbabel README | grep xcsv
>         gpsbabel -i xcsv,style=foo.style -c latin1 -f foo
>         gpsbabel -i xcsv,style=foo.style -f foo -o
>         xcsv,style=bar.style -F bar gpsbabel -s -i gpx -f foo.gpx -o
>         xcsv,style=my.style,snlen=8 -F bar
> 
> and we use in v.in.gpsbabel:
> 
>  gpsbabel -w -i $GIS_OPT_FORMAT $GPSdevice $PROGVERBOSE -o
>  xcsv,style="$STYLE"
> -F "$TMP".gpst
> 
>  gpsbabel -r -i $GIS_OPT_FORMAT $GPSdevice $PROGVERBOSE -o
>  gpx,style="$STYLE"
> -F "$TMP".gpx
>  
>  gpsbabel -t -i $GIS_OPT_FORMAT $GPSdevice $PROGVERBOSE -o
>  gpx,style="$STYLE"
> -F "$TMP".gpx
> 
> 
> I observe that the second and third have gpx,style. Bug?
> Should be xcsv,style? If yes, an incredible bug.
> 
> In this moment also no GPS handy,


I see you too have figured out that ,style="$STYLE" wasn't needed for
gpx format. I was just about to commit that! ;)

I think the extra ,style= only triggerd a harmless warning, which is why
we didn't pick it up before. If gpsbabel has an exit code of 1 the
script should quit right there, but in the bug report it continues on. 


# make tab delim visible (just for illustration):
head -2 12021.0.track_atts | tr -s '\t' '|'
1 | | | | | |
2 | |45.417394638 |10.847196579 | |45.359029770 |10.166580677


this MAY may may be related to some change I May have made to work
around an off-by-one bug I was struggling with. It turns out that there
is a bug in the Garmin 45,48,12XL firmware* where if the track fills
memory and loops the timestamp record can be shifted by one spot vs.
x,y,z record. Before I figured that out I was having all sorts of
trouble getting v.in.gpsbabel and v.in.garmin to produce the same
output- always atts off by one! I had asked Davide and Claudio to fix
this bug in their script before submission, but they never could! oops.

[*] reported to Garmin, but I never heard back from them

I will request one of our field GPSs back here for more testing.


summary: compare track and timestamps vs GPX download file, I suspect
the track_atts are shifted down one line, and worrying about sed -e
"s/| |/|NULL|/" only masks the real bug.


Hamish


Sat, May 12 2007 12:34:19    Status changed to resolved by mneteler  
Sat, May 12 2007 12:34:19    Mail sent by mneteler  
I have fixed it in CVS (also 6.2-CVS, there taking out all g.message calls).
Now it works for my Etrex.

I don't observe any shift-by-one problem in the attribute table.

Markus
Comment | Reply | Take | Open

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