Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Excessive approximation of time ticks (large tracks) #170

Open
velocat opened this issue Jan 18, 2022 · 8 comments
Open

Excessive approximation of time ticks (large tracks) #170

velocat opened this issue Jan 18, 2022 · 8 comments

Comments

@velocat
Copy link
Contributor

velocat commented Jan 18, 2022

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.

label1
label2

Steps to reproduce

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

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

@Raruto
Copy link
Owner

Raruto commented Jan 18, 2022

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:

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

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

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:

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

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


Have a nice day,
Raruto

@velocat
Copy link
Contributor Author

velocat commented Jan 18, 2022

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
Copy link
Owner

Raruto commented Jan 18, 2022

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:

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
Copy link
Owner

Raruto commented Jan 18, 2022

Here you can find some usage examples:

and this could be the offending portion:

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

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

@velocat
Copy link
Contributor Author

velocat commented Jan 18, 2022

Thats my log: 😕

ticklog1

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

@velocat
Copy link
Contributor Author

velocat commented Jan 18, 2022

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

Wheel

@Raruto
Copy link
Owner

Raruto commented Jan 18, 2022

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:

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

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

@Raruto Raruto changed the title Correctness of the time scale display Excessive approximation of time ticks (large tracks) Feb 3, 2022
@hupe13
Copy link
Contributor

hupe13 commented Aug 25, 2022

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.

grafik
grafikgrafikgrafikgrafik

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants