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:

leaflet-elevation/src/time.js

Line 34 in ac803fd

opts.xTimeFormat = opts.xTimeFormat || ((t) => _.formatTime(t).split("'")[0]);

leaflet-elevation/src/time.js

Line 49 in ac803fd

tickFormat : (d) => (d == 0 ? '' : opts.xTimeFormat(d)),

leaflet-elevation/src/utils.js

Lines 48 to 65 in ac803fd

	const SEC = 1000;
	const MIN = SEC * 60;
	const HOUR = MIN * 60;
	const DAY = HOUR * 24;
	/**
	* Convert a duration time (millis) to a human readable string (%Dd %H:%M'%S")
	*/
	export function formatTime(t) {
	let d = Math.floor(t / DAY);
	let h = Math.floor( (t - d * DAY) / HOUR);
	let m = Math.floor( (t - d * DAY - h * HOUR) / MIN);
	let s = Math.round( (t - d * DAY - h * HOUR - m * MIN) / SEC);
	if ( s === 60 ) { m++; s = 0; }
	if ( m === 60 ) { h++; m = 0; }
	if ( h === 24 ) { d++; h = 0; }
	return (d ? d + "d " : '') + h.toString().padStart(2, 0) + ':' + m.toString().padStart(2, 0) + "'" + s.toString().padStart(2, 0) + '"';
	}

Mouse Tooltip:

leaflet-elevation/src/time.js

Line 107 in ac803fd

chart: (item) => this.options.timeFormat(item.time)

leaflet-elevation/src/chart.js

Line 812 in ac803fd

label.text(typeof labels[i].value !== "function" ? labels[i].value : labels[i].value(item) );

---

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:

leaflet-elevation/src/time.js

Line 49 in ac803fd

tickFormat : (d) => (d == 0 ? '' : opts.xTimeFormat(d)),

// 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:

leaflet-elevation/src/components.js

Lines 77 to 82 in ac803fd

	let axisScale = d3["axis" + position.replace(/\b\w/g, l => l.toUpperCase())]()
	.scale(scale)
	.ticks(ticks)
	.tickPadding(tickPadding)
	.tickSize(tickSize)
	.tickFormat(tickFormat);

leaflet-elevation/src/components.js

Lines 392 to 394 in ac803fd

	return d3.scaleLinear()
	.range(range)
	.domain(Domain({min, max, attr, forceBounds})(data));

[velocat]

Thats my log: 😕

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:

leaflet-elevation/src/index.css

Lines 39 to 42 in ac803fd

	.elevation-control.elevation .background.zoomed .point,
	.elevation-control.elevation .background.zoomed .axis.time {
	display: none;
	}

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

leaflet-elevation/src/chart.js

Line 238 in ac803fd

this._updateScale(); // hacky way for restoring x scale when zooming out

---

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.