Thread: [Gpsbabel-misc] trouble loading route from Google Maps to eTrex
Brought to you by:
robertl
From: Norman R. <nr...@ee...> - 2006-12-26 23:06:47
|
Using Debian Linux, gpsbabel version 1.3.2, I attempted to download a route from Google Maps into my Garmin eTrex unit. First note: the shell script on the fmt_google documentation is out of date. I've attached a slightly scarier shell script that appears to do the job. Second note: the .js converts into .gpx format just fine. The .gpx that is produced looks sensible except for a strange backslash in front of each route-point name. OK, I remove that. Either the original .gpx, or the .js, or my edited .gpx will all claim to pass through to the Garmin via gpsbabel -i gpx -o garmin googleroute.gpx /dev/ttyS0 and in each case the Garmin pops up it's little TRANSFER COMPLETE box. But the problem is, I don't see any new route on the Garmin. Nor a new waypoint, track, or anything. Just a whole lotta nothing. I've attached the shell script used to capture the data, The relevant .gpx file, and a log with -D 9. Any suggestions would be appreciated. (I did check the doco and the garmin format does claim to support reading and writing routes.) Norman |
From: Robert L. <rob...@us...> - 2006-12-26 23:42:15
|
Norman Ramsey wrote: > First note: the shell script on the fmt_google documentation is > out of date. I've attached a slightly scarier shell script that Thanx. I'll look at that soon. > The .gpx that is produced looks sensible except for a strange > backslash in front of each route-point name. OK, I remove that. It's actually intentional. You don't have to remove it. > Either the original .gpx, or the .js, or my edited .gpx will > all claim to pass through to the Garmin via > gpsbabel -i gpx -o garmin googleroute.gpx /dev/ttyS0 > and in each case the Garmin pops up it's little You didn't tell it to transfer routes, so it didn't. Add a '-r' to the beginning of that line and all will be well. It doesn't transfer tracks/routes by default on the protocols becuase it can be time very consuming. |
From: Christoph E. <ce...@ch...> - 2006-12-27 00:31:41
|
> > Either the original .gpx, or the .js, or my edited .gpx will > > all claim to pass through to the Garmin via > > =A0 gpsbabel -i gpx -o garmin googleroute.gpx /dev/ttyS0 > > and in each case the Garmin pops up it's little > > You didn't tell it to transfer routes, so it didn't. =A0Add a '-r' > to the beginning of that line and all will be well. > > It doesn't transfer tracks/routes by default on the protocols becuase > it can be time very consuming. As far as I have read, gpsbabel only processes waypoints per default if=20 none of the options -w, -r or -t was present. During writing Gebabbel,=20 I wondered why gpsbabel doesn't process all data (waypoints, routes,=20 tracks) per default if none of the three options -w -r -t was given.=20 IMHO this would be much more straightforward to the user (though I=20 respect that someone has made a decicion with reason). Of course gpsbabel cannot change its behaviour due to backwards=20 compatibility, but in the long term: does CPU power really matter as=20 GPS devices provide USB interfaces nowadays? Cheers, ce |
From: Jason S. <rai...@ta...> - 2006-12-27 00:35:02
|
> Of course gpsbabel cannot change its behaviour due to backwards > compatibility, but in the long term: does CPU power really matter as > GPS devices provide USB interfaces nowadays? Not all do... Reading the waypoint data off a legend (All 10000 points) over serial is painfully slow. Jason |
From: Christoph E. <ce...@ch...> - 2006-12-27 00:47:12
|
> Reading the waypoint data off a legend (All 10000 points) over serial > is painfully slow. agreed - but just for my personal interest: who the heck needs 10000 waypoints on his legend?!? ce |
From: Jason S. <rai...@ta...> - 2006-12-27 00:58:22
|
On Wed, 27 Dec 2006, Christoph Eckert wrote: >> Reading the waypoint data off a legend (All 10000 points) over serial >> is painfully slow. > > agreed - but just for my personal interest: who the heck needs 10000 > waypoints on his legend?!? I meant trackpoints :P The GPS by default stores a circular log of the last 10k trackpoints. Jason -- Jason Slagle /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . |
From: Jerry D. <jd...@co...> - 2006-12-27 02:53:02
|
On Tuesday 26 December 2006 16:06, Norman Ramsey wrote: thanks for the script, i copied it down and tweaked it for bash. it works fine from my house, but I have a question: when I paste the url in firefox, google gives me back 7 items in the driving directions. From = 510 S Extension Rd, Mesa AZ 85210. To = Florence, AZ when I do gpsbabel to convert from google to gpx, I get 97 rtept items is it supposed to do that? I haven't tried dl'ing it to the garmen yet, but I suspect there will be 97 waypoints in my route? Jerry > Using Debian Linux, gpsbabel version 1.3.2, I attempted > to download a route from Google Maps into my Garmin eTrex unit. > > First note: the shell script on the fmt_google documentation is > out of date. I've attached a slightly scarier shell script that > appears to do the job. > > Second note: the .js converts into .gpx format just fine. > The .gpx that is produced looks sensible except for a strange > backslash in front of each route-point name. OK, I remove that. > > Either the original .gpx, or the .js, or my edited .gpx will > all claim to pass through to the Garmin via > gpsbabel -i gpx -o garmin googleroute.gpx /dev/ttyS0 > and in each case the Garmin pops up it's little > TRANSFER > COMPLETE > box. But the problem is, I don't see any new route on the Garmin. > Nor a new waypoint, track, or anything. Just a whole lotta nothing. > > I've attached the shell script used to capture the data, > The relevant .gpx file, and a log with -D 9. Any suggestions > would be appreciated. > > (I did check the doco and the garmin format does claim to support > reading and writing routes.) > > > Norman -- Happy Trails! Jerry Hobbit Name: Pimpernel Loamsdown Registered Linux User: 275424 This email's random fortune: I fell asleep reading a dull book, and I dreamt that I was reading on, so I woke up from sheer boredom. |
From: Norman R. <nr...@ee...> - 2006-12-27 23:16:59
|
> when I do gpsbabel to convert from google to gpx, I get 97 rtept items > is it supposed to do that? It must; I get perhaps two waypoints per 1/10 mile. > I haven't tried dl'ing it to the garmen yet, but I suspect there will be 97 > waypoints in my route? Yes, I downloaded successfully [smacks self in head for having seen -r in the documentation somewhere and then forgotten it] and I have a ton of waypoints. It would be interesting to write a little filter to cut down on the number based on angles or something. Or maybe it's useful; I just got my GPS and have never followed a route before... Norman |
From: Robert L. <rob...@us...> - 2006-12-27 23:19:25
|
Christoph Eckert wrote: > > It doesn't transfer tracks/routes by default on the protocols becuase > > it can be time very consuming. > > I wondered why gpsbabel doesn't process all data (waypoints, routes, > tracks) per default if none of the three options -w -r -t was given. > IMHO this would be much more straightforward to the user (though I > respect that someone has made a decicion with reason). I made that decision because it can be very time consuming - if you want that data, flip that switch to get the data. Even a USB GPS can take a couple of minutes to send stored tracks - if you want to read tracks, that's just th eprice you have to pay, but if you want to read waypoints that's just wasted time. > compatibility, but in the long term: does CPU power really matter as > GPS devices provide USB interfaces nowadays? CPU power doesn't matter a lot in this regard, but passed time does. A serial GPS may take 5-8 minutes to transfer tracks and if we did that just to read a waypoint, we'd be lynched. This has lead to some inconsistency in our various options. Since our very first module was a (serial) GPS format, we had this whole modal tracks or routes or waypoints thing going on and that's leaked into a few of the formats. The various file-based ones try to read and write as much as they can of all three types without requiring -t/-r. RJL |
From: Christoph E. <ce...@ch...> - 2006-12-29 23:22:29
|
Hi Robert, > CPU power doesn't matter a lot in this regard, but passed time does. > =A0A serial GPS may take 5-8 minutes to transfer tracks and if we did > that just to read a waypoint, we'd be lynched. I guess I know what you're talking about :) . I also guess that I made=20 the same decision if I was you. Frankly, I personally do not care much=20 about it. I use the switches and I'm done, but... > This has lead to some inconsistency in our various options. =2E..I also can imagine that it may be confusing for Joe Average. Anyway, I'd vote against an informational message as suggested by =20 Norman as it fixed one inconsistency by another :) . Thanks for sharing your thoughts, ce |
From: Robert L. <rob...@us...> - 2006-12-27 23:22:50
|
Jerry Davis wrote: > when I paste the url in firefox, google gives me back 7 items in the driving > directions. From = 510 S Extension Rd, Mesa AZ 85210. To = Florence, AZ > > when I do gpsbabel to convert from google to gpx, I get 97 rtept items > is it supposed to do that? You have only five places that you actually turn, but to draw the map with reasonable resolution, you need 95 interim points. > I haven't tried dl'ing it to the garmen yet, but I suspect there will be 97 > waypoints in my route? Yes. So unless your Garmin supports 97 routepoints in a route (and I don't know of any Garmin product that does) you might find the route simplifier useful. See: http://www.gpsbabel.org/htmldoc-development/filter_simplify.html RJL |
From: JB L. <jb...@gm...> - 2006-12-28 15:39:03
|
When I've done similar route/track work, I've found the Position filter to be very useful. But that could just be from way I was using my GPS. (This is potentially off topic, so forgive me if it is) My work flow was this. I used the GPSr connected to a PC running Topo to log my travels over the course of the day. I used GPSBabel and the Position filter to get rid of the points collected (and logged) where we stopped or backed up. Then with the cleaned up path back in Topo, I broke the segment up into stages (segments), and then uploaded those segments back into the GPS as routes. I think I sanity checked my routes in EasyGPS. So there was a GPX conversion in there as well! When I needed to drive those roads again, I used the GPSr (only) to feed me general instructions for the route. That way I not only had the intersections, but most of the curves of the road as well. JB On 12/27/06, Robert Lipe <rob...@us...> wrote: > > Jerry Davis wrote: > > > when I paste the url in firefox, google gives me back 7 items in the > driving > > directions. From = 510 S Extension Rd, Mesa AZ 85210. To = Florence, AZ > > > > when I do gpsbabel to convert from google to gpx, I get 97 rtept items > > is it supposed to do that? > > You have only five places that you actually turn, but to draw the map > with reasonable resolution, you need 95 interim points. > > > I haven't tried dl'ing it to the garmen yet, but I suspect there will be > 97 > > waypoints in my route? > > Yes. So unless your Garmin supports 97 routepoints in a route (and I > don't > know of any Garmin product that does) you might find the route simplifier > useful. See: > > http://www.gpsbabel.org/htmldoc-development/filter_simplify.html > > > RJL > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Gpsbabel-misc mailing list http://www.gpsbabel.org > Gps...@li... > To unsubscribe, change list options, or see archives, visit: > https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc > -- http://randombodger.blogspot.com |
From: Norman R. <nr...@ee...> - 2006-12-28 15:24:28
|
> > I wondered why gpsbabel doesn't process all data (waypoints, routes, > > tracks) per default if none of the three options -w -r -t was given. > > IMHO this would be much more straightforward to the user (though I > > respect that someone has made a decicion with reason). > > I made that decision because it can be very time consuming - if you want > that data, flip that switch to get the data... > CPU power doesn't matter a lot in this regard, but passed time does. A > serial GPS may take 5-8 minutes to transfer tracks and if we did that > just to read a waypoint, we'd be lynched. I couldn't agree more. And with the GPS battery running down the whole time! (Hello eTrex owners.) > This has lead to some inconsistency in our various options. Since our > very first module was a (serial) GPS format, we had this whole modal > tracks or routes or waypoints thing going on and that's leaked into a few > of the formats. The various file-based ones try to read and write as much > as they can of all three types without requiring -t/-r. It's just this inconsistency (and the very large size of the manual) that makes it difficult for at least one user to retain the correct method of use. (Though the software's author is extremely helpful on the mailing list.) An idea to consider might be that if a user should attempt to transfer a file that contains route data or track data but no waypoints, gpsbabel might issue a warning message saying You tried to transfer a file containing only tracks/routes but no waypoints, but as a result of the default settings, nothing was transferrred. Try again with -r or -t. Of course then you'll get more blowback from users: if gpsbabel knows the right thing to do, why doesn't it just do it? A truly manly decision for fmt_garmin would be that if a file contains but a single route or track, do the transfer regardless of options. Norman |
From: Robert L. <rob...@us...> - 2006-12-28 17:26:00
|
> It's just this inconsistency (and the very large size of the manual) When we had little doc, people complained about that, too. :-) > You tried to transfer a file containing only tracks/routes but no > waypoints, but as a result of the default settings, nothing was > transferrred. Try again with -r or -t. I'd considered that before, but that would work only in the sending direction. Adding this "guess" about what the user really wanted would actually add a different kind of inconsistency as it makes it asymmetric. > decision for fmt_garmin would be that if a file contains but a single > route or track, do the transfer regardless of options. If I were to do anything here, I think I'd just make the transmitting direction of the garmin module send everything, asymmetry be damned. That'd be more consistent with more of the formats in ignoring {-r, -w, -t } on write. RJL |
From: Norman R. <nr...@ee...> - 2006-12-30 03:04:43
|
> > It's just this inconsistency (and the very large size of the manual) > > When we had little doc, people complained about that, too. :-) Oh, sure. I've only ever agreed with one thing Bjarne Stroustrup has ever said, and this is it: There's software that people complain about, and then there's software that people don't use. > > You tried to transfer a file containing only tracks/routes but no > > waypoints, but as a result of the default settings, nothing was > > transferrred. Try again with -r or -t. > > I'd considered that before, but that would work only in the sending > direction. Adding this "guess" about what the user really wanted > would actually add a different kind of inconsistency as it makes it > asymmetric. OK, so let's see if we can find a way to make it symmetric. My argument, which is a usability argument, is this: a user rarely types a command with the intention of making nothing happen. So something that would work in both directions would be this: mumble.gpx contained no waypoints, so no data was transferred to /dev/ttyS0 /dev/ttyS0 contained no waypoints, so no data was transferred to mumble.gpx. The point being that if a user issues a command that causes nothing to happen, it would be a kind act for the program to say so. > If I were to do anything here, I think I'd just make the transmitting > direction of the garmin module send everything, asymmetry be damned. > That'd be more consistent with more of the formats in ignoring {-r, -w, > -t } on write. I'd be happy with that. Norman |