cumulativeElevationGain and cumulativeElevationLoss not correct when missing parts of track with gps problem? about phpgpx

[nono303]

Hi @Sibyx,
Quick answer: Yes, the middleware layer would a practical answer to execute all kind of process that you can imagine on gpx (and I’ve got a lot of them in old fashioned php style ;)
I'll update phpgistoolbox README to precise public methods on Elevation on next rainy day.

[Sibyx]

Hello @bloodangel78,
I have noticed some issues connected with this feature. I have already started rewriting calculation of the distance, realDistance, gains, loss in the feature/real-distance. I will try to check it out, thanks for the test data.

[bloodangel78]

Hello, no problem.

I have checked with a good gpx file with no cut or gps problem in it, and ill is perfect.

Well done for the speed, it is nice info to have too ;)

[syl20b]

Hello @Sibyx and thank you for your work :)

Do you plan to publish the fix in the next release ?

[Sibyx]

Hello @syl20b, I am sorry to disappoint you I was kind of struggling last time trying to resolve this issue (the numbers I get in the feature branch feature/real-distance didn't make any sense). I will gladly make a release if you offered a PR. I will try to resolve the issue after June (I am finishing my master thesis so I have different priorities right now).

[nono303]

Hi @here,
I'm also looking at this point and after reading few articles dealing with it, it seems complicated to have a good “all-situation” solution without DTM rewriting or a good smoothing algorithm

• https://www.gpsvisualizer.com/tutorials/elevation_gain.html
• https://tracedetrail.fr/en/accueil/help/calcul

Having some test with a gpx track and here are my results for cumulativeElevationGain:

• APPLY_ELEVATION_SMOOTHING = false 3310m (same as http://utrack.crempa.net)
• APPLY_ELEVATION_SMOOTHING = true & ELEVATION_SMOOTHING_THRESHOLD = 2 2823m
• APPLY_ELEVATION_SMOOTHING = true & ELEVATION_SMOOTHING_THRESHOLD = 5 2463m
• APPLY_ELEVATION_SMOOTHING = true & ELEVATION_SMOOTHING_THRESHOLD = 10 2250m

With DEM (DTM1) elevation rewrited gpx

• APPLY_ELEVATION_SMOOTHING = false 2483m (vs. 3310m for original file !)
  ...
• APPLY_ELEVATION_SMOOTHING = true & ELEVATION_SMOOTHING_THRESHOLD = 10 2170m

Some web references

• GoogleEarth 2281m
• tracedetrail 2190m
• trackreport 2523m
• wikiloc 2150m

In my point of view ELEVATION_SMOOTHING_SPIKES_THRESHOLD is not relevant, especially for an hiking recorded track and must be keep at null (or I didn't understand the code in ElevationGainLossCalculator.php l.54 abs($elevationDelta) < phpGPX::$ELEVATION_SMOOTHING_SPIKES_THRESHOLD))

---

I will test some median smoothing algorithm to qualify quality of results
@Sibyx

1. are you interested for an implementation of DEM rewriting ? I have all the code to do it but it might be not relevant for this package…
2. If median smoothing algorithm test was relevant, could you give me your preferred configuration setting implementation?
   My idea (breaking change)
   • change APPLY_ELEVATION_SMOOTHING from bool to int with const SMOOTHING_THRESOLD or 'SMOOTHING_MEDIAN
   • change ELEVATION_SMOOTHING_THRESHOLD to ELEVATION_SMOOTHING_VALUE still int, either for meter(s) threshold or windows size median

[Sibyx]

First of all, @syl20b, part of the issue discussed about real distance has been resolved in 1.2.0.

@nono303, please feel free to implement this. We already have some analytics implemented, so I don't think it's out of scope. I have a different solution that won't introduce breaking changes. However, I'm not sure how it will behave on PHP 8.1+, so please correct me if I'm wrong.

My proposal is to keep APPLY_ELEVATION_SMOOTHING and implement it as a union type bool|int (or string) with the default set to SMOOTHING_THRESHOLD. Additionally, we can keep ELEVATION_SMOOTHING_THRESHOLD as it is and introduce ELEVATION_SMOOTHING_MEDIAN, which will only be used with SMOOTHING_MEDIAN.

I know this may not be the ideal solution, but I want to avoid introducing breaking changes. We can address it in the next major release. I'll try to implement it soon. Feel free to assist @nono303 if you have time.

[Sibyx]

@nono303 It will be nice to take a look on ELEVATION_SMOOTHING. I think we can implement this as a Strategy design pattern and introduce some basic strategies as part of a code base.

[nono303]

Hi @Sibyx,
Always on my mind - background task as I'm mostly on rock and ice than behind my keyboard during summer vacation 🗻

1. For gpx smoothing: I use https://github.com/Alezy80/gpx_reduce with -d 2 -m 5 which produce excellent results (at least with Garmin fit gpx containing bunch of disturbing points (one every 5seconds, moving or not ☹)
   It would be interesting to extract algorithm into a php lib. @Sibyx I let you have a look on it Otherwise I’ll be able to do the job but not before mid-October

2. For altitude correction & filling. I’ve take the time today to transform my old-school procedural script into a draft composer library > https://github.com/nono303/phpgistoolbox.git
   @Sibyx, please have a look on it and give me advises concerning composer organization, global class structure, code style etc.
   Also, if you could PR or help me on how to transform /tests/ElevationTest.php in a real PHPUnit with GitHub Actions (never done all of this…)
   Normally you have all to test it (maybe except for GeoTIFF / vrt as I use homemade file from French IGN Open DATA)
   It might miss some function like getElevation([[lat,lon]+]) but if needed, I’ll do it quickly.

Waiting for your feedback!

[Sibyx]

Hello @nono303, thank you for your response. I've further organized my thoughts below, sorted by category. Your feedback is very much appreciated.

GPX smoothing

The gpx_reduce function seems quite effective. I believe it should not pose much difficulty to incorporate this behavior into a library. Indeed, I consider it a beneficial feature that should be revisited in 2.x. Kindly review my proposed implementation approach.

The additional computational processes for statistical analysis can be managed through middleware that implement the library interface. These middleware will execute in a specified sequence, post GPX parsing, following the basic statistical computations (or the library may include some middleware for elementary stats by default). To better understand my concept, consider the code below. It is merely a rough draft, hence open to modifications.

$phpgpx = new \phpGPX();

$phpgpx->middlewares->add(new \phpGPX\Middlewares\GpxReductionSmoothingMiddleware(2, 5));
$phpgpx->middlewares->add(new \phpGPX\Middlewares\TrackPointExtensionStatsMiddleware());
$phpgpx->middlewares->add(new CustomMiddleware());

$file = $phpgpx->load('example.gpx');

Implementing such a layer should substantially simplify the extension or modification of the library's behavior. I aim to develop a preliminary model for this layer. This should enhance the library's configurability (I'm not particularly fond of the current use of constants for this purpose). I would love to hear your thoughts on this proposal.

There is already an opened discussion about the elevation smoothing. Check it out for some other thougts #55.

phpgistoolbox

I would be more than willing to examine and contribute some pull requests. I can even establish a CI/CD pipeline and set up tests as requested. Initially, I would like to ask you to update your README with a detailed description of the public API, as well as examples of its usage. Subsequently, I'd be delighted to assist you with the implementation and code organization.

If you want to check my other thoughts on the 2.x release, please join discussion #67.