Google
  Web www.gpspassion.com


GpsPasSion LIVE!
www.flickr.com
This is a Flickr badge showing public photos from GpsPasSion Live !. Make your own badge here.

www.NaviBlog.com



Versions

Links/Liens




Portal/Portail
Rechercher

- -

Polls/Sondages
Sondage
Pour vous guider sur la Route :
GPS Mobile (SEM)
GPS Intégré
Smartphone
Autre
Voter  -  Résultat des votes
Votes : 2265




Club GpsPasSion
Soutenez le site!

USA: (US$)
EUROPE: (€)
Guide Paypal


GpsPasSion Forums
Home | Profile | Register/Enregist. | Active Topics | Search/Recherche | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 GPS Programming
 "Beta" GPS software
 Graphical GPX Editor - Updated 07/2012
 New Topic  Reply/Répondre
 Printer Friendly
Previous Page | Next Page
Author Previous Topic Topic Next Topic
Page: of 30

giacomo.ciani

Italy
17 Posts

Posted - 20 juin 2009 :  17:58:32  Show Profile  Reply with Quote
About the anti-scatter filter, i just thought a minute about me.
I think that angle is not an usable parameter, as while you stand still it would change on a random basis assuming all possible values. This is partially true for the speed, too. On the other hand, position is the only thing that is not going to change "that much", and, more importat, that would show a strong correlation between point taken in the same physical position, even with random error.
Given that, it seems to me that a "moving average" on the track could be a good starting point. The algorithm could do domething like this:
- moving average on a (user selctable) number of points
- detect averaged points whose distance to the previous and nex point is under a given value. Maybe this is to simple: I have to think a bit more about this

Unfortunatly I have no time (nor skills) for active development, but if you like a discussion about that I'll be glad to help!

Giacomo
Go to Top of Page

garmin76csx

62 Posts

Posted - 21 juin 2009 :  03:41:50  Show Profile  Reply with Quote
I have made 3 screendumps of tracks:
http://img504.imageshack.us/my.php?image=capture216200924509.jpg
This is a scatter made from the dashboard of a car, parked between 2 houses. The reception was reasonable, but the scatter contains ca. 138 points. The total route has 641 points in total. In the left you see the pointlist: the direction changes a lot of times. It should be reduced to 1 point.

http://img504.imageshack.us/my.php?image=capture216200924218.jpg
In this image you see us parked next to the A1 (Wetherby). Here you can see there are no additional points, so a detector should not see this as a scatter-area. Think of number of direction-changes and radius of less than 50m.

http://img504.imageshack.us/my.php?image=capture216200922618.jpg
In this image, I took the GPS with me in the house and stayed there for a couple of hours. The reception was bad of course. But the scatter contains 363 points on a track of 1976 total. This one should be reduced to 1 point.

Edited by - garmin76csx on 21 juin 2009 03:58:40
Go to Top of Page

garmin76csx

62 Posts

Posted - 21 juin 2009 :  12:01:20  Show Profile  Reply with Quote
@giacomo.ciani
I would parameter the number of directionchanges wich alter more than 90 degrees, not the angle itself.

Remind the parameters I proposed:

a. minimum number of sudden angle-changes (5-30?)(directionchange>90 degree)
b. maximum circle of scattering around center of gravity (20-75 meters?
c. minimum time-period (2-10 minutes?)

In pseudocode I think of the next algorithm:

for all the trackpoints do:
- Imagine a circle around this point with a radius of [param.b] meters. (moving circle)
- within this circle:if the number of directionchanges(more than 90 degree) is more than [param.a] it could be a scatter
- if elapsed time of all points within circle is more than [param.c]
-> we found a scatter!!
reduce scatter: delete all points between entry- and exitpoint of the circle


Go to Top of Page

garmin76csx

62 Posts

Posted - 21 juin 2009 :  15:36:38  Show Profile  Reply with Quote
@Pixel K
During translation (now at 52%), I found a few typo's:

andministrator
german (no capital)
spanish (no capital)
a few bbytes less,

In the last version (and previous) 1.1.76.865 (original exe),when I have selected a tracklog and are in preview the next happens:

- If I move the cursor in the stat-window, the crosshair does not follow the mouse, but has different intervals. The cross in the main preview-window follows this behavour of course.
- After moving around in the stat-window, when I go to the main preview-window and click and release (without scrolling or panning), the yellow tracking cross remains in the view and does not get erased, even when going back to stat-window. There will be a new yellow tracking cross created and so on.

About Garmin tracklogs: If I import a GPX file saved by Mapsource, they use a nonstandard gpxx for the color. Your program gives a little short warning triangle, but ignores the error and continues. GREAT!
But when I save the file with GPX editor, I get a GPX with a nonstandard result:

<extensions>
Red
</extensions>

I maybe wrong, but I think: if you don't accept Garmins 'dialect', why does GPX Editor creates its own?
Go to Top of Page

Pixel_K

France
835 Posts

Posted - 21 juin 2009 :  17:30:24  Show Profile  Visit Pixel_K's Homepage  Reply with Quote
Thank you for the feedback.

The typos and grammar error will be corrected in next version.

- This is not a bug, it's a feature : the red crosshair jumps to the nearest existing point.
- This is a bug, the track is not redrawn until you move / resize it. I would classify that one as minor.

The yellow warning triangle isn't about an error, it just appears when no GPX data is loaded (which happens before the GPX is fully loaded).
GPX Editor tries to interpret the extension data but fails as it is not standard. You can write what you want within the extensions tag, but can't hope everybody will understand it.
The "right thing" to do would be to just copy/paste what it encounters in the extensions tag to the saved file, but at the time I wrote this code, I didn't know how to disable the automatic interpretation within those tags.
Go to Top of Page

garmin76csx

62 Posts

Posted - 22 juin 2009 :  11:29:17  Show Profile  Reply with Quote
I would like to change the behavour of the crosshair, so it wil follow the mousex, disregarding the y, resulting in the nearest X.

So, I thougt: I'll comment all statements out in GPXstat, function TStatPoint.Distance() and replace it with 'Result := Self.X-X'

Strangely, the crosshair does not move anymore.
I do not see why.
Can you tell me where I go wrong?
Go to Top of Page

Pixel_K

France
835 Posts

Posted - 22 juin 2009 :  11:46:34  Show Profile  Visit Pixel_K's Homepage  Reply with Quote
I don't really see the point in not jumping only to existing points, but if you just want the crosshair to follow the mouse, you can change the corsshair drawing routine in main.pas / TMainForm.GPXStatImageMouseMove / Line 4555 :

  Canvas.MoveTo(X,0);
  Canvas.LineTo(X,(GPXStatPanel.Height - GPXStatPanel.oy));
  Canvas.MoveTo(GPXStatPanel.ox,CloSP.Y);
  Canvas.LineTo(GPXStatPanel.Width,CloSP.Y);


Edited by - Pixel_K on 22 juin 2009 12:10:27
Go to Top of Page

garmin76csx

62 Posts

Posted - 22 juin 2009 :  12:06:32  Show Profile  Reply with Quote
Don't get me wrong: It should follow existing points, but only in the x-axes, disregarding the y-difference.
Go to Top of Page

Pixel_K

France
835 Posts

Posted - 22 juin 2009 :  12:10:45  Show Profile  Visit Pixel_K's Homepage  Reply with Quote
After playing a bit with the graph, I think I understand what you want (just guessing). To do it You can modify the TStatPointList.FindClosestIndex in GPXStat.pas. I created a FindClosestXIndex which reads like that :
http://pastebin.com/m4944edcc
then call it in GPXStatImageMouseMove instead of the original function :
closest := GPXStatPanel.StatPointList.FindClosestXIndex(x);
If it's what you want, I can add a switch in the settings to choose a version or the other of FindClosestIndex.

Edited by - Pixel_K on 22 juin 2009 12:12:54
Go to Top of Page

garmin76csx

62 Posts

Posted - 22 juin 2009 :  12:31:32  Show Profile  Reply with Quote
Yessss! That's it.

With your last change, I saw my fault in my trial: I forgot the ABS-function, that's why the crosshair stayed in the corner.

Whatever solution to my problem: the way it now works, seems the realy best of all. I think, the nearestX gives a better feeling and feedback than the nearestXY. I don't need a switch, make it permanent. If using the nearestx, I would recommend to not draw the horizontal crossline, only a vertical one. The horizontal one does cover too much of the profile-line.

I am still wondering about the next: if I have a tracklog elapsing 7 hours, would it be usefull to zoom in (timewise) to better can pinpoint a trackpoint?

About Garmin Mapsource again: I use this application to download tracklogs from my GPSMAP76CSx using the USB-connection. After that, I am saving it in GPX-format, but as you know, it has some dialect.

Do you think (on long term) it would be possible to import tracklogs directly from GPS to GPX Editor?

Edited by - garmin76csx on 22 juin 2009 12:46:25
Go to Top of Page

Pixel_K

France
835 Posts

Posted - 22 juin 2009 :  12:55:58  Show Profile  Visit Pixel_K's Homepage  Reply with Quote
I prefer to give the choice to all the user, but I probably make nearestX the default. As your wrote, it feels more natural.

I prefer to cut my long tracks into smaller ones, easier to manage, and faster to show on Google map. The zoom feature on the elevation graph is a feature I wanted to add a few month ago but I never really had the time to work on it.

I don't know how the GPSMAP76CSx works, but, as I already worked on another datalogger (GlobalSat DG-100), those things are not really funny to deal with on a programming level. Each one has its own dialect and you have to re-learn everything for each model. I don't even know how to speak with Garmin devices (as I don't own one) and doing a reliable import is unrealistic without owning the hardware to test it. The DG-100 had a good documentation, I don't know anything about the state of the informations I can get about any Garmin device. An input plugin for GPX Editor would be nice, but infeasible without owning the device and knowing the underground layer of the exchanges with the device.
The shipped Software with the DG-100 was really an horror, but the procedures to talk with it on hardware-level were simple enough for me to have to do only simple reverse-engineering. Doing it without owning one to tinker with is unrealistic.
I know there are other (open) softwares than the official garmin ones to dump the content of those devices, but I know nothing about them.

*** EDIT ***

GPSBabel supports your device.

Edited by - Pixel_K on 22 juin 2009 13:04:28
Go to Top of Page

garmin76csx

62 Posts

Posted - 22 juin 2009 :  13:56:48  Show Profile  Reply with Quote
Thank you for your feedback.

About translating:
There are words with '&', being keyboard shortcuts. When I translate, will the shortcut be replaced with the new one? In that case, I have to be extra carefull to maintain different shortcuts and still looking for a Dutch word.
Go to Top of Page

garmin76csx

62 Posts

Posted - 22 juin 2009 :  16:58:33  Show Profile  Reply with Quote
@Pixel K:

Is it possible to make a selector wich data to show in the statpoints-pane?

- a. Altitude (as is)
- b. Speed
- c. Direction-change (angle)

NOTES:

in b: normally one point has no speed. The time- and positiondifference between two points gives a speed. But wich point gets this property? You could make an average of the results before and after a point and store that as property of that point. The first point has no predecessor, so take next vector. The last has no successor, so take the last vector.

in c: Almost the same notes as in b: the first and last point store '0' as directionchange. The intermediate points could be calculated with the already available routine 'AngleFrom3Points'.

The last option c. is very handy for future development of anti-scatter, but this is at this point also a mighty help for recognizing and editing by hand. You could opt to display all three options at the same time (in different colors), with or without a checkmark for each option. I am very curious about this last option how it will look like.

Please Santa, please

Edited by - garmin76csx on 22 juin 2009 17:02:16
Go to Top of Page

Pixel_K

France
835 Posts

Posted - 22 juin 2009 :  21:21:53  Show Profile  Visit Pixel_K's Homepage  Reply with Quote
I would add (d) distance from start. Even if it's just an increasing-only curve, it may prove usefull (combined with the cut here / plant waypoint right-click)

Speed was a long-standing awaited addition, you just gave me the motivation to work on it. I'm not yet decided on the details, so it will take some time to implement.
Go to Top of Page

Pixel_K

France
835 Posts

Posted - 22 juin 2009 :  21:40:52  Show Profile  Visit Pixel_K's Homepage  Reply with Quote
Version 1.1.77 available.

Corrects the typos, let the user choose the method for determining nearest statpoint
Go to Top of Page
Page: of 30 Previous Topic Topic Next Topic  
Previous Page | Next Page
 New Topic  Reply/Répondre
 Printer Friendly
Jump To:
GpsPasSion Forums © 2002-2014_GpsPasSion/Manzanite Go To Top Of Page
This page was generated in 1,45 seconds. Powered By: Snitz Forums 2000 Version 3.4.05