Is there a radius filter for trackpoints?

[Gavin Treadgold-2]

Hi all,

Let me just say congratulations on the 1.3.5 release! :)

I was wondering how easy it would be to expand the radius filter so  
that it could be applied to tracks - I note that it currently works on  
waypoints only. Basically, I'd like to be able to pass a GPX tracklog,  
and have it remove some trackpoints before uploading the resulting  
file to OpenStreetMap - by filtering out points around work, home,  
friends etc. I'd like to script GPSBabel to clean certain known  
locations from my tracklogs before upload.

So, the following hypothetical command would strip all trackpoints  
from the input file that lie within 400m of S45 E170.

gpsbabel -t -i gpx -f in.gpx -x  
radius,distance=0.4K,lat=-45.0,lon=170.0,exclude,nosort -o gpx -F  
out.gpx

Are there any obvious technical reasons that I'm missing that this  
couldn't be implemented?

Cheers Gav

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
Gpsbabel-misc@...
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

[Robert Lipe-2]

On Mon, May 5, 2008 at 11:33 PM, Gavin Treadgold <gav@...> wrote:

Hi all,

Let me just say congratulations on the 1.3.5 release! :)

Thanx.

 

I was wondering how easy it would be to expand the radius filter so
that it could be applied to tracks - I note that it currently works on

It's not practical in the general case.  See the conversation (that you participated in :-) on this
list starting on 3/21.  Radius and polygon filters have the same kinds of issues. 


 

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
Gpsbabel-misc@...
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

[Gavin Treadgold-2]

Thanks Robert,

Unless I missed some emails on the list, I didn't see any good reasons listed in that brief discussion why it couldn't be done. That is why I raised it again :) I also picked what I thought would be a relatively simple case e.g. radius, rather than arc/polygon as it should meet 90% of my needs.

The only issue that I saw raised in those emails was how to treat the tracklog - e.g. should it be kept as one, or split. For the use case I'm interested in, it is only the points that are important, not the connections between points. I would be happy in this case to have the trackpoint removed and the overall tracklog contracted. Most of my use cases would see this filtering occurring at the start or end of a track anyway, so tracklog contraction, rather than splitting, would make sense here. I understand of course that this may not generalise well. Isn't it as simple as letting the end user decide, perhaps by a switch to either contract or split whenever a trackpoint is deleted because of radius proximity?

Cheers Gav

On 2008-05-06, at 1657, Robert Lipe wrote:

On Mon, May 5, 2008 at 11:33 PM, Gavin Treadgold <gav@...> wrote:

I was wondering how easy it would be to expand the radius filter so

that it could be applied to tracks - I note that it currently works on

It's not practical in the general case.  See the conversation (that you participated in :-) on this
list starting on 3/21.  Radius and polygon filters have the same kinds of issues. 

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
Gpsbabel-misc@...
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

[Robert Lipe-2]

On Tue, May 6, 2008 at 12:26 AM, Gavin Treadgold <gav@...> wrote:

The only issue that I saw raised in those emails was how to treat the tracklog - e.g. should it be kept as one, or split. For the use case I'm interested in, it is only the points that are important, not the connections between points. I would be happy in this case to have the trackpoint removed and the overall tracklog contracted. Most of my use cases would see this

Then use GPSBabel's transform filter to convert your tracks to points and filter away.   What works for points simply doesn't work for polylines in the general case and I get that you may not be interested in solving the general case.  It's breaking that connectivity that hoses the general case of lines.

RJL


 

Cheers Gav

On 2008-05-06, at 1657, Robert Lipe wrote:

On Mon, May 5, 2008 at 11:33 PM, Gavin Treadgold <gav@...> wrote:

I was wondering how easy it would be to expand the radius filter so

that it could be applied to tracks - I note that it currently works on

It's not practical in the general case.  See the conversation (that you participated in :-) on this
list starting on 3/21.  Radius and polygon filters have the same kinds of issues. 

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
Gpsbabel-misc@...
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

[Gavin Treadgold-2]

On 2008-05-06, at 1735, Robert Lipe wrote:

On Tue, May 6, 2008 at 12:26 AM, Gavin Treadgold <gav@...> wrote:

The only issue that I saw raised in those emails was how to treat the tracklog - e.g. should it be kept as one, or split. For the use case I'm interested in, it is only the points that are important, not the connections between points. I would be happy in this case to have the trackpoint removed and the overall tracklog contracted. Most of my use cases would see this

Then use GPSBabel's transform filter to convert your tracks to points and filter away.   What works for points simply doesn't work for polylines in the general case and I get that you may not be interested in solving the general case.  It's breaking that connectivity that hoses the general case of lines.

I was looking at that before and wondering if I could do that. So for this use case, I should be able to...

1. Convert tracks to waypoints

2. Perform radius filter on waypoints

3. Convert remaining waypoints back to tracks (and possibly merge or pack to tidy them up)

I guess I have never really considered tracks as polylines - given the way they are split by poor reception, have reduced value from wander etc. I have always used them as raw points, and never made any assumptions about the connections between them. I'm not saying that either view is wrong as they are both correct for different applications, but I think that the end user should be able to decide whether they want to use tracks as points or tracks as polylines. If all I have to do is convert them to waypoints to work with them as points - then that's all I need to know and I'm happy for this use case, and will test it as soon as I have the opportunity, and report back to the list :)

Just going back to the general case for a moment (I'm always interested it trying to solve problems), and taking what I've said about about trusting points more than the implied lines between them. I'd suggest the following as trying to work towards a generalised case.

Re: your comment about breaking connectively, the fact that I want to delete points, I think suggests that I am happy with losing some aspect of connectively, and I can always merge or pack them later anyway to restore some semblance of connectivity.

Using a radius filter to cut a polyline, I assume there are two general issues.

1. Contract or split - I would suggest splitting as this maintains the fidelity of the remaining tracklogs, and does not introduce a large straight polyline segment through the cut portion that is 'meaningless'. E.g. if you have driving on road tracklogs and you enter and leave a cut section, then the resulting tracklogs will exactly mirror the actual travelled road segments and won't introduce any new polyline segments that  weren't actually travelled (e.g. a connector line from the start to the end of the removed track polyline) that doesn't follow the roads.

2. Which trackpoint to finish/start a segment with? Should we start/finish the resulting polylines at existing trackpoints, or create an additional trackpoint where the filter cut the line and interpolate its time and calculate its position? Once again, I'd go with the known information, rather than that implied by the line segment. Each polyline should start and finish with a known recorded trackpoint, and we should not  create new trackpoints at the boundary of the radius. If we were to create an trackpoint at the radius of the circle, we are only assuming that the receiver passed that point.

I base this thinking on the following - trackpoints are recorded facts (with error at times, granted), the line segments between them are only assumptions (e.g that the receiver travelled a straight line between the two points). That assumption is usually only true for short time periods between trackpoints. The longer the time period between two points, the less valid the polyline becomes. A perfect example of this is a polyline cutting the inside of a broad sweeping driving corner when trackpoints are taking only every few seconds. In this case the polyline carries less value than the points as it records a track well off the road. Record more points, and you receive a better quality polyline.

Hence, I'd argue that the trackpoints are factual and need to be kept, but that we can afford to lose line segments because they are only assumptions of connectivyt, and not factual connectivity. Yes, you will lose some assumed connectivity outside the proximity area, but no factual data. I don't see any problem with that.

Thanks again for pointing me to the waypoint direction. It sounds very promising.

Cheers Gav

PS I can feel a development support donation coming on after I've finished work :)

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
Gpsbabel-misc@...
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

[Gavin Treadgold-2]

That solution worked wonderfully for me in this case.

Cheers Gavin

On 2008-05-06, at 1735, Robert Lipe wrote:

On Tue, May 6, 2008 at 12:26 AM, Gavin Treadgold <gav@...> wrote:

The only issue that I saw raised in those emails was how to treat the tracklog - e.g. should it be kept as one, or split. For the use case I'm interested in, it is only the points that are important, not the connections between points. I would be happy in this case to have the trackpoint removed and the overall tracklog contracted. Most of my use cases would see this

Then use GPSBabel's transform filter to convert your tracks to points and filter away.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
Gpsbabel-misc@...
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc