Route from Track Revisited

[PjotrC]

I've been experimenting with some heuristics to reduce the number of points generated by the Route-From-Track function in the Route Manager.

A very simple approach seems to work fine:

- to include the waypoint, if its XTE between the Accepted Previous Point, and Potential Next Point exceeds "TrackPoint Distance Interval" / 2.
- to include the waypoint every (x * "Plan_Speed" Nautical Miles, x=2.0 seems OK, equivalent to 2 hrs underway = half a watch)

Both parameters are settable in respective Dialogs (TrackPoint Distance Interval: Tools/Etc, Plan_Speed: RouteProperties).

Some example results:

1. A track of 3028 trackpoints recorded every 60 seconds is reduced to a 40 waypoint route by choosing PlanSpeed=3.0, TrackDist=0.05 (minimum possible)

2. A track of 6682 trackpoints generated from LOGBOOK timestamps every 30 minutes is reduced to a 540 waypoint route by choosing PlanSpeed=10.0, TrackDist=0.5

3. A tricky track of 272 trackpoints recorded every 60 seconds is reduced to a very reasonable route of 25 waypoints by using default values of 6 kn and 0.1 nm.

This algorithm tends to smooth out gentle curves rather than look for positively straight lines. There are many other approaches possible, and none is objectively perfect ...

For programming simplicity I am omitting the very last stretch of route, but manual checking and and touchup is always necessary on such routes anyway.

Enjoy,

Piotr

PS. Note the Zero increase in user interface here ...

[Ptizef]

Hi Piotr

Very good idea ! many thanks

patch apply and built without any problem

first tests with an existing track
parameters : speed 5 kts
track points each 60 s

shot 1
distance parameter = 0.2 NM
route not created on all the distance and crosses land

shot 2
distance parameter = 0.1 NM
route crosses land

shot 3
distance parameter = 0.01 NM
very good : only 70 points instead of 600

I would suggest to "offset" the result : with a distance parameter of 0.01 , the route should be almost the same as track and the good result above should have been obtained with a greater value , most often use in this parameter
Another alternative would be to use a specific parameter to ovoid having to change the track parameter



another remark : Personally ,I would prefer using the Diamond icon instead of the blue X one


Regards
Jean Pierre

[PjotrC]

You are right on all points...

In principle I was against automatic building of routes at all, but once it is there, we might do something about it...

I would not even attempt building a route that can be blindly used, and I hope nobody will try that, although much better approximation is possible

It is a tool used as a first step in regular route construction.

Therefore no checks for crossing the land, and leaving the last stretch unfinished. I make it obvious, that the route has to be edited by hand.

I did not want to include any new parameters. I left the icon as the original author did choose.

The simple algorithm does "lazy turning", that is why there are usually two waypoints close to each other on sharp turns - could be better with a two-pass scanning, but again - I do not aim at automatic planning.

Cheers,

Piotr

[Jon Hacking]

Piotr, this looks very interesting. Is it implemented anywhere? Can I try it out? If so, how? (I don't have build tools out here...)

[PjotrC]

Originally Posted by Jon Hacking

I am very interested - Anything I can do to help it along?

You can help by testing the Route Planning with GRIB...

I will include the TrackToRoute in the next build, so you can play with this as well.

P.

[sinbad7]

Piotr..

Why re-invent the wheel? There already exists a smart,Open Source route converting interface by the name 'RouteConvert'.

It already has many of the features we need but need a little 'marinising' for use in our marine environments. It already has the capability to delete/add points in the track from three different criteria.

It also has a very nifty editable library of tracks etc. where you can also add your own.

Would it not be possible for those of you with programing experience to make the necessary addittions/changes?

Tore

[Jon Hacking]

Originally Posted by PjotrC

You can help by testing the Route Planning with GRIB...

I will include the TrackToRoute in the next build, so you can play with this as well. P.

Piotr, I'm a SW Tester (& embedded dev) by profession, so I'd love to help any way I can. Is the Route Planning with Grib already in the build? I don't remember seeing it (but I usually use AirMail for my GRIBs). I'll look forward to the TrackToRoute code!

[PjotrC]

The link to Windows build 2.5.1101 is given inForums - Post 808701">-IRJDSUNE9932123321222xxeww-this-IRJDSUNE9932123321222xxeww-post.

The source patch is attached.

I tweaked a little the algorithm, so route is now end-to-end and looks better.

The quality of conversion is controlled by two parameters:

- Plan_Speed (Route Properties Dialog) - equals 1/4 of maximum leg length
- Trackpoints Distance Interval (Tools->Etc) - sets max allowed XTE between existing track and constructed route (regardless of whether track was done with time-based or distance-based recording)

Good luck,

Piotr