[bug] Receiving SRTM heights breaks the heart rate recording.

[snooppr]

I have a watch that writes metrics: GPS and heart rate (but not altitude).

Reproducing the problem when GPSPrune removes (apparently unintentionally) the pulse from the gpx track.

1. Open the gpx track in gpsprune (approximate markup)

<trkpt lat="x" lon="y">
    <time>2024-01-16T08:49:09.000Z</time>
    <extensions>
        <gpxtpx:TrackPointExtension>
            <gpxtpx:hr>98</gpxtpx:hr>
        </gpxtpx:TrackPointExtension>
    </extensions>
</trkpt>

2. Online --> get height from SRTM --> save track in gpx.
3. Open the saved gpx track and you will find that the heart rate has disappeared from it

<trkpt lat="x" lon="y">
	<ele>130.52680000000055</ele>
	<time>2024-01-16T08:49:09.000Z</time>
</trkpt>

If you do not use the function in gpsprune (obtaining heights from SRTM), then after editing the track, for example, gluing, etc. and after saving the track, the new track saves your heart rate.
So I conclude that it is the 'get height from SRTM' function that removes the heart rate from the track, it shouldn't be that way. Please correct.

[snooppr]

Just in case, I will add information, a workaround for the problem until it is fixed in gpsprune, for those users who are faced with the same problem (for example, all users of the TomTom line of watches, who can now receive their tracks from the watch only using a PC) .

You can add height to a track and save the heart rate in various software (osmand; qgis, etc.), but this is not so convenient/long.

The easiest option but privacy may suffer, although the source code is open and there is a nice privacy policy, everything seems to be acceptable

The files created, visualized or edited on the website are only read once and never stored on a server. We only access the data contained in the files and handle all computations from your local browser (it is a pure client-side application) is to use the service

https://gpx.studio/
It does this very quickly and intuitively without any technical skills, I checked it on my track.

[activityworkshop]

Thanks for the bug report, and yes I agree it can be a bit confusing.

The problem here is not specifically the SRTM lookup, it's the fact that this function adds the altitude field to a point which didn't have an altitude before. It behaves the same if you manually add an altitude to this point too.
In your "non-SRTM" case where you're changing the order of points or combining points from different files, the points themselves aren't changed. And because you've selected "Copy source xml", (even though the points are now in a different order), GpsPrune is able to just copy the whole xml for that point from its source file, including the gpxtpx:hr tags which GpsPrune otherwise has no knowledge about.
When you add a new field to this point, either by adding a waypoint name or by adding an altitude, GpsPrune realises that it can no longer copy the source for this point, so it has to regenerate the gpx contents based on what it knows about. And that includes position, altitude, name, timestamp etc but not these extensions which it doesn't recognise.

Until GpsPrune has a more complete understanding of all the possible gpx extensions which could be in use, it doesn't have a way to work out where to insert the missing <ele> tag. So the workaround which I would personally use (yes, I know it's awkward, that's why I'm calling it a workaround and not a solution) would be to add altitudes to all the points before loading into GpsPrune. For example, I could replace <time> for all the points with <ele>0</ele><time> so that they all have zero altitude. Then after GpsPrune has replaced those altitudes with values out of SRTM (or changed by hand) then it can export as a GPX file using the source file, and your extensions including your heart rate data will be retained.