Data loss with position filter
The article warns that "All current gpsbabel versions seem to suffer from a data loss bug in position filter", with a link to an archived email list discussion. In that thread, which appears to be read-only, there is clearly a disagreement over whether this "position" filter is working properly or not. The initiator of the thread believed that points were wrongly being deleted, and the author of GPSBabel didn't appear willing to explain why he thought it was behaving as intended, or even to try out the provided data set.
I think it can be explained. The attached track loops around and covers the same path/road twice. The OP used GPSBabel to remove points which are close together, using the command
gpsbabel -i gpx -f infile.gpx -x position,distance=2m -o gpx -F outfile.gpx
The position filter is described in the docs as "This filter removes points based on their proximity to each other. A point is removed if it is within the specified distance of a point that has come before." So the user expected GPSBabel to remove points from the first pass which are within 2m of each other, and then do the same for the second pass. But GPSBabel actually looks at all the earlier points and deletes a point if it is found to be within 2m of any of the preceding points of the track. In this case, on the second pass several points are within 2m of points from the first pass, and so are deleted, which surprised the user. Instead of a smooth curve with points spaced 2m apart, it generates a very uneven trace with the corners cut off.
Perhaps this is the behaviour desired by the author, but it's not clear from the description that this is what it does. And it's not what the user expected. One way to avoid the problem is to add a "time" parameter, to only compare points within the same minute. Then the points in the second pass are not compared with those from the first pass as they are more than a minute older (of course this only works if the track has timestamps). Using the following:
gpsbabel -i gpx -f infile.gpx -x position,distance=2m,time=60 -o gpx -F outfile2.gpx
the shape of the second pass is preserved. Unfortunately, some consecutive points elsewhere at almost identical locations are then also retained, because they are one minute apart but in the same place.
If that's what's happening, and the fact that adding the time parameter stops the deletion indicates that that's true, then I'd say it's more of a bug in the documentation than a bug in GPSBabel. And maybe the red warning on this page is a little unnecessary? Eric2 10:38, 9 November 2012 (UTC)