Re: [Gpsbabel-code] De-noise filter?
Brought to you by:
robertl
From: Nicolas B. <nbo...@de...> - 2015-08-25 11:54:37
|
Hi, On Sun, Aug 23, 2015 at 07:30:58PM -0500, Robert Lipe wrote: > > That's OK. Your English is better than my non-existent French (?). I'll > just be more careful about uncommon terms. Thanks for your effort. And you guessed correctly, I am french. > You're right. That page does need clarification and what I thought it did, > what the doc says it does, and what the code actually does don't really > match. I finally read the source code again, and now I understand why it does not behave as I thought it would. For what it’s worth, I hacked the position filter to make it behave as I thought it would. My quick & dirty patch (for gpsbabel 1.4.3) is attached. Please tell me if you would be interested by a cleaner patch (probably with an option, not to change the default behavior) for git head. > A "zinger" in GPS parlance is when a point is recorded that's pretty > clearly errant. For example, if I'm recording a walking track and have one > track point here and the next track point is in Switzerland and the > following track point is 2m from where I started, that middle point is a > zinger. GPSes that record such points but that don't filter points or > provide reliability data are not good...but very common in the logger > space. Yours doesn't do large zingers; it looks like it's doing some kind > of weighted averaging and drifting. Thanks for explaining the word “zinger”. Just curious, do such extreme “zingers” really happen? I am not sure, but I would have thought that my GPS unit (and most of them) would use some Kalman-like filtering to merge the data from many satellites, and that the offset drifts whenever a new satellite is considered. BTW, I thing it would be nice if it was possible to log the raw low-level per-satellite data, because I think it would make it possible to do a great post-processing job. (GPS modules may be doing a great job already, but they are somewhat restricted by their need to do real-time processing; using also future data might help a lot.) But I don’t know any GPS module that provides such low-level data (not to say any GPS datalogger that logs it)… :-( > A brisk (quick) jog might also be called a slow run. I was trying to > express something faster than even a fast walk in that terrain. Ok, thanks for the explanation. > > Anyway, I was hiking with kids (2 of them being 4 years old), so I > > certainly never walked anything near 3 meters/sec. > > > > It looked like a challenging hike on its own. Doing it with kids that age > is heroic. :-) Do you mean the “real” hike or the hypothetic one with 3 meters/sec speed? The real hike was not that challenging, even for 4-year-old kids. > That's a very common thing to do. I was using speed as a metric because > it's in your source file and is easier to machine process than doing the > great circle math to compute actual distances. For example, if you > $ grep speed ~/Downloads/initial.gpx | sort | uniq -c > you'll see there are a fair number of outlying points that are not typical > walking speeds. Yes, I saw that as well (altough with different commands). > You'll also find that the unit isn't reporting fractional seconds or doing > a very good job of keeping to the "every two seconds" goal. > > <time>2015-08-07T16:01:53Z</time> > <time>2015-08-07T16:01:54Z</time> > <time>2015-08-07T16:01:57Z</time> > <time>2015-08-07T16:01:59Z</time> > <time>2015-08-07T16:02:00Z</time> Yes, the logged timestamps are clearly rounded to a 1-second resolution. That datalogger may be used as a real-time GPS unit and event then it provides NMEA sentences where timestamps have a 1-second resolution… :-( However, the high speed do not seem to be related with 1-second intervals. > Certainly. This is why lots of GPSes have options to drop points every N > units of distance instead of every T units of time. The DG-200 has this option, but as I understand it, it is not different from what I get with my patched position filter. > I looked in our DG-[12]00 reader and if DOP is logged by the devices at > all, we don't know how to read it. It does not show up in the specification I got from GlobalSat. Cheers, -- Nicolas Boullis |