Excessive approximation of time ticks (large tracks)

[velocat]

Subject of the issue

After it became possible to see the duration in the tooltip, I noticed that on large tracks the upper scale is displayed incorrectly. It displays a completely different time than in the hint. This is not observed on short tracks.

Is it difficult to understand what is wrong? For understanding, I give a link to a branch with this example and screenshots.

Steps to reproduce

https://github.com/velocat/leaflet-elevation/tree/TestTrack

https://jsfiddle.net/velocat/pwyLxb9u/1/

[Raruto]

Hi velocat,

these should be the lines you should check (it could be related to the formatTime function, for your tests you can also override it using the xTimeFormat option):

---

Axis:

https://github.com/Raruto/leaflet-elevation/blob/ac803fd023718e097a71f5121501a6a5043946d2/src/time.js#L34

https://github.com/Raruto/leaflet-elevation/blob/ac803fd023718e097a71f5121501a6a5043946d2/src/time.js#L49

https://github.com/Raruto/leaflet-elevation/blob/ac803fd023718e097a71f5121501a6a5043946d2/src/utils.js#L48-L65

Mouse Tooltip:

https://github.com/Raruto/leaflet-elevation/blob/ac803fd023718e097a71f5121501a6a5043946d2/src/time.js#L107

https://github.com/Raruto/leaflet-elevation/blob/ac803fd023718e097a71f5121501a6a5043946d2/src/chart.js#L812

---

Have a nice day, Raruto

[velocat]

I think this is due to a principled approach.

This scale shows the time calculated according to the time specified in the track. However, there is a time increment delta in the hint. That's what makes the difference.

It would probably be more logical to use an increment in the scale as well.

Note: Track recording can be stopped, for example, overnight, and then continued the next day, the next day. As it seems to me, this is what causes the difference, though... need to test more precisely with different tracks.

[Raruto]

if I'm not mistaken this is a problem related to how d3js handles the creation of the ticks on the time axis scale, you can check it as follows:

https://github.com/Raruto/leaflet-elevation/blob/ac803fd023718e097a71f5121501a6a5043946d2/src/time.js#L49

// CHANGE that line inside time.js

tickFormat : (d)  => {
  console.log("Duration: " + _.formatTime(d || 0) + ' {' + d + '}');
  return (d == 0 ? '' : opts.xTimeFormat(d))
},

// ADD this line inside time.js

this._registerFocusLabel({
  name: 'time',
  chart: (item) => "Duration: " + _.formatTime(item.duration || 0) + ' {' + item.duration + '}'
});

For some reason it only considers values that are multiples of 10 (eg. 50000000, 100000000, 150000000, 200000000, 250000000)

[Raruto]

Here you can find some usage examples:

• https://observablehq.com/@d3/axis-ticks
• https://observablehq.com/@d3/scale-ticks

and this could be the offending portion:

https://github.com/Raruto/leaflet-elevation/blob/ac803fd023718e097a71f5121501a6a5043946d2/src/components.js#L77-L82

https://github.com/Raruto/leaflet-elevation/blob/ac803fd023718e097a71f5121501a6a5043946d2/src/components.js#L392-L394

[velocat]

Thats my log: :confused:

And .... There is already an increment at the zero point (starting point):

[velocat]

And more... If you zoom with the mouse, then this scale disappears altogether until you return to the initial zoom level:

[Raruto]

And more... If you zoom with the mouse, then this scale disappears altogether until you return to the initial zoom level

This is the reason:

https://github.com/Raruto/leaflet-elevation/blob/ac803fd023718e097a71f5121501a6a5043946d2/src/index.css#L39-L42

if you want to investigate further you can start from here:

https://github.com/Raruto/leaflet-elevation/blob/ac803fd023718e097a71f5121501a6a5043946d2/src/chart.js#L238

---

There is already an increment at the zero point (starting point):

There is also an initial speed of 0.01 km/h (and a slope of -600% ...), maybe they are related issues.

---

As usual anyone interested in solving this is welcome (honestly for my current use of this library these advanced stats are quite overkill...)

Have a nice day, Raruto

[hupe13]

Okay, I deleted my comment because I thought it wasn't right. But now I tested it on an extreme track: The first quarter and the last quarter of the track went very fast, the 2nd super slow, the third a little slower than the first and last quarter. Unfortunately, in the 2nd quarter my gps device quit. But it seems to be right what I suspected. The time in the diagram is considered evenly distributed, but it is not.