Thread: Re: [Gpsbabel-misc] time with waypoints?
Brought to you by:
robertl
From: Paul F. <pg...@fo...> - 2006-01-24 19:17:28
|
> > Just started using gpsbabel to extract data from my garmin > > gps. I noticed that the waypoints do not have a <time> > > attribute associated with them when written to a gpx file. ... > It would be nice, wouldn't it? (Especially if you were, say, > using waypoints to track the location of digital photos.) It > would also be nice if your saved tracks stored the time... or > if the "Active Log" recorded HDOP and other other useful info. > But alas, Garmin, in their far-less-than-infinite wisdom, have > decided that they only need to store the barest minimum of > information for you. i may be way off base, and i haven't used gpsbabel much with my garmin III, but i have an old waypoint file downloaded from that unit with a program called gd2 that contains what look like reasonable "created" times. are you saying you don't have creation times? paul =--------------------- paul fox, pg...@fo... (arlington, ma, where it's 33.8 degrees) |
From: Robert L. <rob...@us...> - 2006-01-24 20:21:39
|
If the original question really was about trackpoints and not waypoints, the answers you have are spot-on. If it really is about waypoints and not trackpoints, we'll need to know a lot more about the receiver in question. GPSBabel tries to support them, but given the variety of waypoint xfer protocols and the relatively low number of them that support waypoint timestamps, I wouldn't die of shock if there was some combination that wasn't handled. For example, the D109's have space for a timestamp but I can't think of a single receiver I've seen with D109's that ever displays a timestamp on waypoints (beyond that in the comment field when you press 'mark' on some units) or that returns that field with anything other than 'unused' on a read So I have an impression there's a light switch there but there may not be any wires connected to it in most units. adam> I understand they're trying to save memory space, That made some amount of sense in the days when flash memory was scarce. Now that these things routinely have a substantial fraction of a gig of flash, a lot of these things (like waypoint comment length) really should be revisited by all the GPS guys. It seems that the vendors keep cranking out units with one foot in the past. As perspective, a Streetpilot with 2G of memory does exactly what's described above, too - and it stores even fewer trackpoints! I've carried a half gig in a Magellan for a long time and while it stores 500 waypoints at a time, only 200 of them have 50 character comments. Is there really not another 15KB of storage in these things? And why are these tables and fields fixed in size anyway? RJL |
From: Jon S. <sai...@ya...> - 2006-01-24 21:52:58
|
Thanks everyone... all great replies. My original question really was this: is it possible to get a <time> attribute with each waypoint when I extract them from my garmin extrex Legend using gpsbabel to a gpx file? I want to make sure I am not missing a commandline argument or something. I am not even sure my device keeps a timestamp with each waypoint. Anyone know? The active track has times... the saved ones do not... not fun. Thanks Jon --- Robert Lipe <rob...@us...> wrote: > If the original question really was about > trackpoints and not waypoints, > the answers you have are spot-on. > > If it really is about waypoints and not trackpoints, > we'll need to > know a lot more about the receiver in question. > GPSBabel tries to > support them, but given the variety of waypoint xfer > protocols and > the relatively low number of them that support > waypoint timestamps, I > wouldn't die of shock if there was some combination > that wasn't handled. > > For example, the D109's have space for a timestamp > but I can't think of > a single receiver I've seen with D109's that ever > displays a timestamp > on waypoints (beyond that in the comment field when > you press 'mark' on > some units) or that returns that field with anything > other than 'unused' > on a read > > So I have an impression there's a light switch there > but there may not > be any wires connected to it in most units. > > adam> I understand they're trying to save memory > space, > > That made some amount of sense in the days when > flash memory was scarce. > Now that these things routinely have a substantial > fraction of a gig > of flash, a lot of these things (like waypoint > comment length) really > should be revisited by all the GPS guys. It seems > that the vendors keep > cranking out units with one foot in the past. > > As perspective, a Streetpilot with 2G of memory does > exactly what's > described above, too - and it stores even fewer > trackpoints! I've > carried a half gig in a Magellan for a long time and > while it stores 500 > waypoints at a time, only 200 of them have 50 > character comments. Is > there really not another 15KB of storage in these > things? And why are > these tables and fields fixed in size anyway? > > RJL > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do > you grep through log files > for problems? Stop! Download the new AJAX search > engine that makes > searching your log files as easy as surfing the > web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Gpsbabel-misc mailing list > Gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc > |
From: Adam S. <ada...@un...> - 2006-01-24 21:59:44
|
On 01/24/06, Jon Saints wrote: > >My original question really was this: is it possible >to get a <time> attribute with each waypoint when I >extract them from my garmin extrex Legend using >gpsbabel to a gpx file? I want to make sure I am not >missing a commandline argument or something. No, there is no way to do it, with GPSBabel or any other program, because your eTrex does not store any information with waypoints other than name, symbol, latitude, longitude, and elevation. As Beverly Howard pointed out, the only possibility would be to go through manually and find the nearest time-stamped trackpoint. I suppose it's conceivable that someone has written a program to do this sort of thing, but I don't know of one. Adam |
From: Robert L. <rob...@us...> - 2006-01-24 22:08:57
|
Jon Saints wrote: > My original question really was this: is it possible > to get a <time> attribute with each waypoint when I > extract them from my garmin extrex Legend using If you really are asking about waypoints and not trackpoints, I'm reasonably sure that etrex Legend does not retain that data ever. > The active track has times... the saved ones do not... > not fun. But that's trackpoints and not waypoints... RJL |
From: Greg <Greg@KeepTheRubberSideDown.com> - 2006-01-26 02:07:07
|
Hi I'm no expert, but a waypoint is marking a place and has nothing to do with time. That doesn't mean many of wouldn't want to know when we were there--but I think that is the logic. Again Garmin has decided if you want to save a compressed version you don't need time; it's only marking the route; hence a saved track doesn't have a time stamp. Did anyone come up with a way to figure out the time when you were closest to the waypoint? Someone must have done it, it's a common desire. I've often wished I could insert the waypoints I've marked into my Active Log. If it's for photographs; there are programs to match the capture time with the Active Log. I'm writing privately because I'm blocked (or my ISP is, although no other site blocks me) from posting. All this GPS logic is frustrating. As someone pointed out, memory probably was the original reason. But I've realized that GPSs are used in so many different ways, it's hard to suit us all. The company that does it will probably make money. Good luck. Greg --------------------------------------------------------------------- _--=0 Hermosa Beach, California USA __ /---\\ http://KeepTheRubberSideDown.com ___ () () email: http://public.xdi.org/=mtnbiker Skype: KnobbyGeek On Jan 24, 2006, at 1:52 PM, Jon Saints wrote: > Thanks everyone... all great replies. > > My original question really was this: is it possible > to get a <time> attribute with each waypoint when I > extract them from my garmin extrex Legend using > gpsbabel to a gpx file? I want to make sure I am not > missing a commandline argument or something. > > I am not even sure my device keeps a timestamp with > each waypoint. Anyone know? > > The active track has times... the saved ones do not... > not fun. > > Thanks > Jon > > > > --- Robert Lipe <rob...@us...> wrote: > >> If the original question really was about >> trackpoints and not waypoints, >> the answers you have are spot-on. >> >> If it really is about waypoints and not trackpoints, >> we'll need to >> know a lot more about the receiver in question. >> GPSBabel tries to >> support them, but given the variety of waypoint xfer >> protocols and >> the relatively low number of them that support >> waypoint timestamps, I >> wouldn't die of shock if there was some combination >> that wasn't handled. >> >> For example, the D109's have space for a timestamp >> but I can't think of >> a single receiver I've seen with D109's that ever >> displays a timestamp >> on waypoints (beyond that in the comment field when >> you press 'mark' on >> some units) or that returns that field with anything >> other than 'unused' >> on a read >> >> So I have an impression there's a light switch there >> but there may not >> be any wires connected to it in most units. >> >> adam> I understand they're trying to save memory >> space, >> >> That made some amount of sense in the days when >> flash memory was scarce. >> Now that these things routinely have a substantial >> fraction of a gig >> of flash, a lot of these things (like waypoint >> comment length) really >> should be revisited by all the GPS guys. It seems >> that the vendors keep >> cranking out units with one foot in the past. >> >> As perspective, a Streetpilot with 2G of memory does >> exactly what's >> described above, too - and it stores even fewer >> trackpoints! I've >> carried a half gig in a Magellan for a long time and >> while it stores 500 >> waypoints at a time, only 200 of them have 50 >> character comments. Is >> there really not another 15KB of storage in these >> things? And why are >> these tables and fields fixed in size anyway? >> >> RJL >> >> >> >> > ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do >> you grep through log files >> for problems? Stop! Download the new AJAX search >> engine that makes >> searching your log files as easy as surfing the >> web. DOWNLOAD SPLUNK! >> > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=103432&bid=230486&dat=121642 >> _______________________________________________ >> Gpsbabel-misc mailing list >> Gps...@li... >> > https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Gpsbabel-misc mailing list > Gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc |
From: Stan G. <sta...@pa...> - 2006-01-26 02:34:17
|
Okay, I may get hit on this one, but in reality, Greg, using a GPS has EVERYTHING TO DO WITH TIME!!! (doesn't it??) That's EXACTLY how a GPS unit works. It uses the time differentials between the signals it receives from multiple satellites to "compute" the location it is at by knowing the signatures and locations of each of the satellites. Of course, it's all semantics. We don't really consider all of that when we mark a waypoint -- as users, it has nothing to do with time; hey, it's "where we're at!" But I agree with you on everything else ;-) Stan Greg wrote: > Hi > > I'm no expert, but a waypoint is marking a place and has nothing to do > with time. That doesn't mean many of wouldn't want to know when we > were there--but I think that is the logic. > > Again Garmin has decided if you want to save a compressed version you > don't need time; it's only marking the route; hence a saved track > doesn't have a time stamp. > > Did anyone come up with a way to figure out the time when you were > closest to the waypoint? Someone must have done it, it's a common > desire. I've often wished I could insert the waypoints I've marked > into my Active Log. > > If it's for photographs; there are programs to match the capture time > with the Active Log. > > I'm writing privately because I'm blocked (or my ISP is, although no > other site blocks me) from posting. > > All this GPS logic is frustrating. As someone pointed out, memory > probably was the original reason. But I've realized that GPSs are used > in so many different ways, it's hard to suit us all. The company that > does it will probably make money. > > Good luck. > > > Greg > > --------------------------------------------------------------------- > > _--=0 Hermosa Beach, California USA > > __ /---\\ http://KeepTheRubberSideDown.com > > ___ () () email: http://public.xdi.org/=mtnbiker > > Skype: KnobbyGeek > > |
From: Lee D. R. <lee...@gm...> - 2006-01-26 03:42:45
|
On 1/25/06, Greg <Gr...@ke...> wrote: > I'm no expert, but a waypoint is marking a place and has nothing to do wi= th > time. That doesn't mean many of wouldn't want to know when we were > there--but I think that is the logic. Lowrance uses the exact opposite logic. Waypoints have time stamps, trackpoints don't. I find this EXTREMELY frustrating. As a bicyclist, I'd really like to determine speeds at specific points on a ride. Can't do that easily if trackpoints aren't time-stamped. > Did anyone come up with a way to figure out the time when you were closes= t > to the waypoint? Someone must have done it, it's a common desire. On the Lowrance iFinder, I've cheanged the track log settings to set a point every 15 seconds (instead of the usual optimizing logic). I also set a waypoint (which on my GPS does get a timestamp) at the beginning of the ride. That way I can calculate the time of each track point. A bother, but it works. Could you apply any form of that trickery to your Garmin problem? -L. |
From: Robert L. <rob...@us...> - 2006-01-26 19:12:04
|
Greg wrote: > Did anyone come up with a way to figure out the time when you were > closest to the waypoint? Someone must have done it, it's a common > desire. I've often wished I could insert the waypoints I've marked > into my Active Log. We have most the logic for this. I needed something like this for a geocaching trip where I screwed up my record keeping. What I did (kids, don't try this at home) was to take my list of waypoints and my tracklog and feed them to a modified version of the arc filter to find all waypoints within N feet of my track. The modification was in arcdist.c and was pretty simple to do poorly, but in my case, "poorly" was "good enough". Basicly I just made the code in arcdist_process that decided that this point was close enough to the trackpoint[1] just modify the source waypoint's creation time. I didn't think it was worth generalizing, do I tossed the code once was I done. But you're right - geotagging would be a lovely use for that. This would be a good little project for some coder. > If it's for photographs; there are programs to match the capture > time with the Active Log. My Treo has AGPS and a camera; why do I have to geotag at all? Oh, yeah, it's becuase they won't release the programming information to actually get to the AGPS data... There are another bazillion things that the Palm code could do if it knew your location... RJL [1] Which meant that the saved timestamp probably wasn't the point where we were actually closest, but it represented a time where I was "close enough" to get me a sorted list that I could use for logging. |
From: Ron P. <ro...@pa...> - 2006-01-26 19:25:54
|
Robert Lipe wrote: > We have most the logic for this. > > I needed something like this for a geocaching trip where I screwed up my > record keeping. What I did (kids, don't try this at home) was to take my > list of waypoints and my tracklog and feed them to a modified version > of the arc filter to find all waypoints within N feet of my track. The > modification was in arcdist.c and was pretty simple to do poorly, but > in my case, "poorly" was "good enough". Basicly I just made the code in > arcdist_process that decided that this point was close enough to the > trackpoint[1] just modify the source waypoint's creation time. > > [1] Which meant that the saved timestamp probably wasn't the point where > we were actually closest, but it represented a time where I was > "close enough" to get me a sorted list that I could use for logging. > If you did it inside the "if ( ed->distance > dist )" condition, it was the closest line segment. One or the other of that line segment's endpoints was thus the closest endpoint. Linear interpolation between the endpoint times would probably be overkill. :) Now I want to try it at home... > I didn't think it was worth generalizing, do I tossed the code once was > I done. But you're right - geotagging would be a lovely use for that. > This would be a good little project for some coder. > While that coder is at it, since they'd have to modify the arc format to contain timestamps, perhaps they could generalize things a bit so we don't actually need the arc format anymore. Say, an option that says "use the track/route named 'foo'" or even "use the first track or route in the track/route list." We'd probably also want a way to then remove the route from the list so it wouldn't get written into our output GPX file. |
From: Ron P. <ro...@pa...> - 2006-01-26 19:38:30
|
Ron Parker wrote: > Robert Lipe wrote: >> >> [1] Which meant that the saved timestamp probably wasn't the point >> where >> we were actually closest, but it represented a time where I was >> "close enough" to get me a sorted list that I could use for logging. >> > If you did it inside the "if ( ed->distance > dist )" condition, it > was the closest line segment. One or the other of that line segment's > endpoints was thus the closest endpoint. Linear interpolation between > the endpoint times would probably be overkill. :) And the point I intended to make in that message, but forgot to: that being the case, there's an opportunity for optimization there. Once something is close enough, we really should stop computing the distance to future line segments. |
From: Beverly H. <Bev@BevHoward.com> - 2006-01-26 21:05:36
|
>> This would be a good little project for some coder. << While I am relatively new to any geo-coding, since the problem is two dimensional, I can't wrap my head around determining the closest point other than to compute the distance between one point and all other points then choosing the lowest value. Any elucidation on alternatives would be appreciated. Beverly Howard |
From: Greg <Greg@KeepTheRubberSideDown.com> - 2006-01-26 21:34:43
|
I think it's really three dimensional, but unless someone is climbing something steep two dimensional would be OK. But a rock climber would be going very slowly up a cliff and the lat and long would stay the same and the elevation would change with time, so for this and other vertical (climbing a pole or tower), the problem should probably be done as three dimensional. Get your head around that ;) Greg --------------------------------------------------------------------- _--=0 Hermosa Beach, California USA __ /---\\ http://KeepTheRubberSideDown.com ___ () () email: http://public.xdi.org/=mtnbiker Skype: KnobbyGeek On Jan 26, 2006, at 1:05 PM, Beverly Howard wrote: > >> This would be a good little project for some coder. << > > While I am relatively new to any geo-coding, since the problem is > two dimensional, I can't wrap my head around determining the > closest point other than to compute the distance between one point > and all other points then choosing the lowest value. > > Any elucidation on alternatives would be appreciated. > > Beverly Howard |
From: Dave P. <da...@dp...> - 2006-01-27 18:52:36
|
On Thu, 2006-01-26 at 13:34 -0800, Greg wrote: > I think it's really three dimensional, but unless someone is climbing > something steep two dimensional would be OK. But a rock climber would > be going very slowly up a cliff and the lat and long would stay the > same and the elevation would change with time, so for this and other > vertical (climbing a pole or tower), the problem should probably be > done as three dimensional. > > > Get your head around that ;) I'm with Beverley. If the clever people could give us an algorithm, I'd certainly have a go at it. Java, for calling from an xslt transform, using gpx input format. -- Regards, Dave Pawson XSLT + Docbook FAQ http://www.dpawson.co.uk |
From: Beverly H. <Bev@BevHoward.com> - 2006-01-27 20:54:18
|
>> If the clever people could give us an algorithm, I'd certainly have a go at it. << Well, two disclaimers here, first, I'm not that clever, and second, I am a database programmer in FoxPro which has a number of helpful tools to make doing the following fairly easy. With that in mind and remembering that the following is just "thinking out loud; For the sake of simplicity, I would discard altitude, make all values positive, then find the nearest trackpoints using "fuzzy logic" to determine; a tp (a) where ((wp_lat - tp_lat) + (wp_long - tp_long)) is the lowest a tp (b) where ((tp_lat - wp_lat) + (tp_long - wp_long)) is the lowest I naively assume that (for at least a fairly straight track) that the waypoint would be between the two trackpoints and that it's "time" would be the proportional difference between the two trakpoint's times. I am sure that everyone and their brother is going to jump in and point out that lat/long distance values are inconsistant. While the above would not be accurate as a distance value, it should work as a "relative" value. There could be a trackpoint 2,500 feet above or such a convoluted track that it would scramble the above. Simply determining if the two resultant trackpoints are sequential could be a starting point at narrowing that down. <end of "mind barf"> (... this is gonna be interesting... and educational ;-) Beverly Howard |
From: Ron P. <ro...@pa...> - 2006-01-27 21:15:52
|
Beverly Howard wrote: > a tp (a) where ((wp_lat - tp_lat) + (wp_long - tp_long)) is the lowest > > a tp (b) where ((tp_lat - wp_lat) + (tp_long - wp_long)) is the lowest That's what's called "taxicab" or "L1" distance. If you're going to do it that way, you should instead use the Pythagorean or L2 distance (square root of the sum of the squares.) However, if you're writing code for GPSBabel, you don't need to do that. There's already a gcdist (great circle distance) function defined in grtcirc.c. It's about as accurate as you can get while still pretending that the Earth is a sphere. There's also a linedist function that will determine the distance to the closest point on a line segment, which is actually far more useful for this task. > I naively assume that (for at least a fairly straight track) that the > waypoint would be between the two trackpoints and that it's "time" > would be the proportional difference between the two trakpoint's times. You can do a little better than that, actually; it's not too hard to compute the actual closest point on the line. You should even be able to adapt some of the code from the linedist function to compute that point for you, if you can make sense of the math. (Perhaps surprisingly, I can compute the distance from the line segment without ever completely calculating the location of the closest point.) One problem might be that the closest approach to the waypoint actually is a single trackpoint. That'd happen if the track has been simplified. If you're adapting the linedist code, you can easily catch that case too; linedist already has to. |