Wrong accumulated elevation when added point does not contain elevation data

Issue #124 closed
Michel Durand created an issue

With Basecamp it is possible to insert points to existing tracks.
These added point only contain latitude/longitude, no date and no elevation.

When importing these files to QMapShack, everything is fine but accumulated elevation :

wrongAccumulatedElevation.png

QMapShack v1.6 post
W10 64bits

Comments (17)

  1. Michel Durand reporter

    Means we keep this 2^31 m accumulated elevation ?

    I do not know GPX specification and am not able to tell if Basecamp is wrong here.

    What I see is 2 bilions meters accumulated climb and this is wrong.

    Having "??" instead would make more sense.

    On the same topic speed on tracks without timestamps is "inf".
    "??" could be used here instead too.

    And assembling 2 tracks with QMapShack, 1st one with timestamps, 2nd one without timestamps gives funny results on duration.

    On the other hand having funny durations, infinite speeds or billions meters climbs shows clearly that calculation is not possible with given data, even if having "??" would be better.

  2. Michel Durand reporter

    I attached 2 tracks created with QMapShack v1.6 only (invalidDuration.gpx and invalidSpeedAndDescent.gpx).
    With/without timestamps and/or with/without elevation, using tracks merging function.

    OK I did them on purpose knowing what result I wanted.
    By the way if someone wants to replace invalid calculation results by "??" or "--" or "invalid", the 2 attached files are good testing material.

  3. kiozen

    These tracks contain obviously bullshit and bullshit is displayed. I really see no point in wasting time on them.

    If you want to have some statics on spoofed data, use the filters to replace senseless data. If you just have a few corrupted points in your track, remove them.

  4. Michel Durand reporter

    The problem was not bullshit tracks, but bullshit in calculation results.

    Anyway, you are the boss, you decide. If I am not happy I can just keep my Basecamp. But QMS has wonderful features like multi-maps displays and so on ... then I keep QMS.

  5. Michel Durand reporter

    Well seen !

    Good to know that I am still not a useless troll to you. Even if I try hard :)

    Well OK I forget these calculations stuff and I live with them... but :

    The trace where elevation is <ele>-2147483648</ele> has been drawn by myself with QMS on an area without DEM data. (see trackDrawnOnAreaWithoutDEMdata.gpx ; creator is "edge 305" because I modified QMS code, then Strava takes into account elevation data).

    Do you confirm that getting <ele>-2147483648</ele> in this case is OK ?
    I would expect no <ele> in this case. (once more I can live with this too ...)

  6. Christian Eichler

    I think I want to add a few points:

    1. If there is no DEM at all, we should not add any elevation data to saved .gpx files at all. This does not apply if the DEM source contains invalid values (that's sth we can't prevent)
    2. If your input files contain technically correct values (for instance <ele>-2147483648</ele>), the derivation will be based on those values - that is totally correct the way it currently is.
    3. If the input does not contain data for a specific value on a few trackpoints, then we should avoid using default values for derivation and consequently displaying bullshit.
      This is (imho) the reason why bike magazine wrote "Herkunft aus der Linux-(Computer-Nerd)-Ecke"* - we (the nerds) see, that the value displayed could originate from an unset value, the average user does not and will most likely never find out.
    4. In general I don't think "others behave equally bad" is a justification for not fixing bad behavior - in this particular case point (1) applies (valid input files containing weird values)

    *freely translated / in the sense of: "a tool written by nerds"

  7. Michel Durand reporter

    Then is it a valid (minor) bug report if I create one telling that "GPX file created from an area without DEM data contains <ele>-2147483648</ele> instead of no elevation data" ?

  8. kiozen

    Yes, that is a real bug. I will fix that.

    For the other stuff: You can spend a lot of time on that and you will loose either way. If users are convinced that their track should always provide perfect data, even if they have corrupted the data by themselves, they will file a bug report either way.

    Take the starting example. A valid track corrupted by introducing artificial points via Basecamp.

    1. We could ignore the points and derive the statistics from the valid ones. For one or two points ok. If the user introduced quite some points the calculated values won't match the expected range -> bug report: Values derived by QMS are too low.

    2. We can display extreme values as by now -> bug report: like this one

    3. We can refuse to display statistics -> bug report: QMS does not show any values.

    I really use QMapShack a lot and I do have a huge database of tracks. Recordings from my GPS are usually valid tracks that do not cause any problem. The other group are tracks from the internet or those that come with a tour guide book. Usually those are hilariously bad. They contain every cruelty you can do in a track. I usually replace the elevation data by DEM and apply an average speed to those tracks before I register them in the database. I think that is the only sensible way to handle spoofed, malformed or corrupted tracks. There is no sense in trying to rescue the best from that kind of data.

  9. Christian Eichler

    I think neither of those three ways of implementing that is a good idea.

    To get rid of those bug reports you describe, the most simple way is displaying something like "Ascend: ??" along with a message describing the reason why that value cannot be calculated properly.

    Additionally: I don't think the current behavior ist a bug - but I think the report is a valid suggestion for an enhancement. If someone is willing to fix that - fine, if not, well...
    Maybe I'll take a look at that if I have some spare time.

  10. Michel Durand reporter

    Concerning correction :
    OK : now tracks drawn on area without DEM data get no elevation data. Good.
    But it seems that side effects appeared :
    When drawing tracks in area with DEM data, it seems that elevations of first point and last point are taken in account, but not the ones in-between :

    descend0.png

    flatProfileButLastPoint.png

  11. Log in to comment