I want to add a suggestion to solve the problem of too long time needed for
SSTB compression. You remember ?
5/ Regarding display of a track when starting trackback : the conversion of a long track (10000 points) take about 15mn.. This is long, but as to be added to the documentation.. (If no way to enhance)..(@Alain: Did you really mean 15 minutes ?? - If yes, this is really not acceptable !).
Okay - now we know why this time is needed ! It's because of this:
1. Improve accuracy of SS Track Back:
Due to the complaination of SS track back, the current compression scenario is to:
- To set the max compression points is 200
- Set filter for Dist as 50m, Turn angel as 15 degree
- Compress trace regarding filter
- If total points are over 200, increase Dist 1m,
- Repeat compression until to under 200 points
Have a nice weekend, Geoffrey
When I read this, I had immideately these ideas:
1. Couldn't there be a smarter algorithm, instead of try and error ?
Repeat several times until result is okay ? Actually I have no idea,
but I will think about it !
2. If we keep this algorithm as it is now, it can easily be optimized:
a) Use a larger distance filter increasing step ! Instead of 1m use 5m or 10m.
This will fasten the calculation by a factor of 5 or 10.
b) Use a dynamic distance filter increasing step. Instead of using a fixed
value like 1m or 5m, make it depend on the number of resulting points.
So, when a first calculation compresses an original amount of points
of e.g. 10.000 points to 3.000, it doesn't make much sense to increase
the distance filter from 50m to 51m. The resulting points will never reach
the goal of 200. Because the difference from 3.000 to the final 200 is
still so big, it would make more sense to try next time with e.g. 100m.
I'm not able to tell more, because I still cannot imagine exactly how the compression
algorithm is working in detail. And furthermore which are the limits (any why)
the algorithm is created for. Maybe if I knew more, I could make more suggstions...