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 |
|