| Versions |
  |
|
| Author |
 Topic  |
|
Pixel_K
France
814 Posts |
 Posted - 17 mai 2009 : 23:11:27
|
Version 1.1.70
Tries to restore position in treeview, even after an object is deleted |
 |
|
|
giacomo.ciani
Italy
15 Posts |
Posted - 19 mai 2009 : 08:13:50
|
I just had a quick try: it only restores the status of the tree branch you are working on (i.e. if if have track and waypoints opened, and you delete a waypoint, you end up with waypoint opened and tracks closed), but that's already much better than before. Good job! :-)
Thanks
Giacomo |
|
|
|
michael1303
2 Posts |
Posted - 02 juin 2009 : 12:11:56
|
Hallo,
I have used the GPX editor to create a new waypoint by clicking in the map and then clicking on the Waypoint-Button. The Waypoint was created, but if i try to move the waypoint to another position, there comes an error-message in france : "(GMap 52.550419 N' n'est une valeur en virgule flottante correcte." Is it possible to move the waypoints ?
Greetings
Michael |
|
|
|
Pixel_K
France
814 Posts |
Posted - 02 juin 2009 : 21:04:08
|
Hi,
could you please telle me if this test version solves the bug you found ? |
|
|
|
garmin76csx
62 Posts |
Posted - 11 juin 2009 : 23:54:01
|
Hi Pixel_K,
Thank you for sharing this program with us. I was most interested in the filtering of tracklogs using the Douglas-Peucker algorithm.
Because I would like to refine the algorithm depending on velocity and change of angle, I downloaded the source and some other external units. But at a point I can't go further: it needs XpBase and XpDom.
Where can I find these?
By the way: when filtering with Douglas-Peucker, in what units 0..10.0000 is this? |
|
|
|
Pixel_K
France
814 Posts |
Posted - 12 juin 2009 : 09:54:18
|
XML Parter can be found here
Most of the Douglas-Peucker algorithm comes from here, the other sources I used is here (in Perl).
The constant you're writing about is the maximum distance allowed between the real and the simplified path. I would guess (because I can't remember) it's in meter.
As DP is only about distance and not time, I hardly see how you would make speed in the equation, other by giving more weight to some points. About the angle, it's kind of already in there, as a high significant angle will most of the time be in the simplified path. |
|
|
|
garmin76csx
62 Posts |
Posted - 13 juin 2009 : 11:17:45
|
Thank you for your addition.
I would like the following refinement to test for my own tracklogs: the tolerance (or distance)gets an initial value of the user. Depending on speed and angle it gets a multiplication factor.
The DP-algorithm used here just looks at the graphic line, while a tracklog has also another dimension: speed. Maybe I will use the 3d-algorithm where the speed is the third dimension, not linear but as a logarithm.
My goal is to reduce points in a tracklog with car and walks together. As speed is high, you can adjust to a higher tolerance. At that speeds you are following a road wich is simple to 'reconstruct' after reduction. If speed is low however (walking), the tolerance should be lower to retain more points. I would like to keep the places where are footbridges or geocaches.
A workaround would be: cut the tracklog in pieces and use per piece a different tolerance. But at lower speeds, one can make sharper angles (there can be a reason for that), wich would be filtered out on tolerance, but should be kept.
BTW: with the last version program (still unmodified), experimenting with the tolerance, I suddenly had a memory issue in the program. Used a tracklog of 1500 points. |
|
|
|
Pixel_K
France
814 Posts |
Posted - 13 juin 2009 : 14:49:35
|
What kind of "memory issue" ? I often edit and simplify tracks with more than 10000 points without encountering any problem.
And just to be clear, speed isn't a dimension, time is. Your idea is interesting, please share with us your progress on those algorithms. |
|
|
|
garmin76csx
62 Posts |
Posted - 13 juin 2009 : 18:19:10
|
After playing again with the DP-adjustment on a single tracklog of 2787 points to 706 points at the 'tolerance' set at 741 with the up/down-arrow (started from 100), I got the next message: 'Mémoire insuffisante'. I had zoomed in at a portion (ca 10x) in the middle of a track to see at what level the corners of the track are back in the resulting line.
Looking in the task-explorer, it used 2.013.200kB, or 2Gb!
Starting all over again: after loading it uses 6500kB. With the task-explorer in a second window: every change in DP-parameter results in more memory-usage.
The same is happening with other filter-methods. It looks to me, that the program does not release all previous result-lines in memory. If I start with a filter resulting drastic results, the increase of memory is less, than starting with less filtering. |
Edited by - garmin76csx on 13 juin 2009 18:31:42 |
|
|
|
Pixel_K
France
814 Posts |
Posted - 13 juin 2009 : 19:38:59
|
| I'll look at this memory leak, thank you for your feedback on it. |
|
|
|
garmin76csx
62 Posts |
Posted - 16 juin 2009 : 00:24:26
|
Goodmorning Pixel K,
I found two problems tonight:
a. When i try to read a .gpx-file wich was reduced with DP, I got an error in Garmin Mapsource stating 'file xxx.gpx can not be imported.
The problem lies in the extension with color. If I delete the complete extension, it will import again.
These are the differences:
Garmin Mapsource output:
<trk>
<name>ACTIVE LOG 002</name>
<extensions>
<gpxx:TrackExtension xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3">
<gpxx:DisplayColor>Blue</gpxx:DisplayColor>
</gpxx:TrackExtension>
</extensions>
---------------------------------------------------------------------
GPX editor output:
<trk>
<name>ACTIVE LOG 002</name>
<extensions>
Blue </extensions>
<trkseg>
b. When using DP the way implemented, the corners start beiing a shortcut first, while a lot of points on a straight line stay....
My experience with Delphi are not that high, so I have a lot to study and read your sources. |
|
|
|
Pixel_K
France
814 Posts |
Posted - 16 juin 2009 : 01:43:16
|
The garmin extension are not standard, so no project on supporting them. There is already supported and documented GPX style extension. Garmin choose to ignore them and use their proprietary one.
So the problem lies within garmin software, I can't do anything about that. |
|
|
|
garmin76csx
62 Posts |
Posted - 16 juin 2009 : 01:50:09
|
Found the errors in the DP-alogrithm:
In function VecMinPoint4D2, DotProdPoint4D2, NormSquaredPoint4D2 and SimplifyTrackDP in file PointListEdit.pas, there is altitude used.
If I remove/alter those statements, you get a clean 2D-calculation, having less points on a straight line, leaving corners more intact and still a better reduction in points.
Original file: 269 points, after reducing (5000) results 194 points.
After modifying the source, I get after reducing(5000) 58 points.
Even with reducing(10000) I get 85 as highes result!
Now I have to figure out how points are stored, to get a meaningfull unit (meters I would like) for the tolerance. |
|
|
|
Pixel_K
France
814 Posts |
Posted - 16 juin 2009 : 03:12:24
|
Oh yes you're right, I was just adding degrees to meters in my calculation, witch is just wrong. I should find another way to use the altitude (or at least give the choice to the user to use it or not).
Thank you for spotting that one. |
|
|
|
garmin76csx
62 Posts |
Posted - 16 juin 2009 : 09:37:08
|
If you would like the user to choose from 2D or 3D, you could add a "Douglas-Peucker 3D-difference" in the pulldown-menu and implement the complete 3D calculation next to the 2D.
And rename the current to "Douglas-Peucker 2D-difference".
BTW: how can I help to translate text to Dutch?
I can't see a language-select under options. Or only during compiletime?
|
|
|
|
Topic |
|
|
|
| This page was generated in 3,12 seconds. |
 |
|
- 
- 
Graphical GPX Editor - Updated 07/2012
