Strange behaviour of filters "Change Speed" and "Hide Invalid Points" in extreme situations

Issue #131 resolved
wthaemelt created an issue

While trying to understand what an invalid trackpoint in the latest QMS version is I tried some extreme values.

Filter "Change speed":

Setting the speed in the "Change speed" filter to possible (but extreme) value 0 km/h leads to a "Invalid timestamps" warning and a "backward oriented/reversed" track (i.e. timestamp of successor trackpoint is earlier than timestamp of predecessor).

Possible improvements:

Either set minimum feasible value for selection to 0.00001 km/h or some other reasonable nonzero value or issue a warning message of the form "0 km/h is not a feasible value" and cancel the action or remove all timestamps (as is done with reversed tracks).

Filter "Hide Invalid Points":

I edited the latitude value of a trackpoint in a GPX file to lat="151.27021055" in order to get an invalid trackpoint position. After loading the track into QMS I get the "correct" "N151 ..." position. Applying the "Hide Invalid Points" filter nothing happens with this trackpoint.
In the map window the trackpoint is shown with coordinates (0, 0).

As far as I understand invalid trackpoints are those with missing timestamp, missing elevation or wrong coordinates.

Possible improvements:

Implement stronger rules to validate coordinates and show invalid trackpoint coordinates in red in the track points window - maybe together with a warning message of the form "Points with invalid coordinates shown in red. Track on map therefore invalid.".

Of course, both issues are closely related to the question what the objective of QMS is. I personally like the current situation which I would describe for tracks as follows:

QMS can handle 2 types of tracks:

  • "Complete (recorded) tracks" coming mainly from a GPS device with "good" and "complete" data (timestamps, positions, elevations, ...) but also from other reliable sources.

  • "Tracks under construction (incomplete tracks/planned tracks)" build within QMS with various methods (this includes also the possibility to load tracks from GPX files possibly with wrong data). These tracks should have at least "good" position data.

QMS filters can be used to convert incomplete tracks into complete ones or to identify missing or even wrong data (e.g. wrong coordinates) in tracks (invalid trackpoints).

Various track actions with complete tracks can result in incomplete tracks (e.g. merging of tracks, reversing of tracks).

Having this in mind I simply consider invalid or bad (Wiki formulation) trackpoints as incomplete trackpoints and like the support of QMS to make trackpoints and therefore tracks complete.


Comments (2)

  1. kiozen

    Regarding speed and position: I will improve that. The initial idea for position was to remove bad positions with a coordinate of 0,0 introduced by a GPS receiver. But testing for sane coordinate limits is a good idea, too.

    Regarding "completing tracks": Imho this is up to the user. Creating a new track from fragments of other tracks including new data is surely the typical way to plan a new tour. The decision to fix that is up to the user. Usually I apply elevation data from the DEM layer and apply the speed of my average walking speed. So this is quite individual.

  2. Log in to comment