8000 Tick labels when using hourly rangebreaks · Issue #4722 · plotly/plotly.js · GitHub
[go: up one dir, main page]
Skip to content

Tick labels when using hourly rangebreaks #4722

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.

Sign up for GitHub

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

Jump to bottom
Closed
nicolaskruchten opened this issue Apr 2, 2020 · 5 comments · Fixed by #4831
Closed

Tick labels when using hourly rangebreaks #4722

nicolaskruchten opened this issue Apr 2, 2020 · 5 comments · Fixed by #4831
Assignees
@archmoj
Labels
bug something broken
Milestone
v1.54.2

Comments

@nicolaskruchten
Copy link
Contributor
nicolaskruchten commented Apr 2, 2020 •
edited
Loading

This pen https://codepen.io/nicolaskruchten/pen/qBdwQKw?editors=0010 shows oddly-spaced tick labels both by default, and when setting dtick to 24*60*60*1000 (daily) or 60*60*1000 (hourly).
@nicolaskruchten nicolaskruchten added the bug something broken label Apr 2, 2020
@archmoj
Copy link
Contributor
archmoj commented Apr 2, 2020

With bounds: [18, 6] they are spaced well | demo.
Maybe we should try something similar to what we did for day of week i.e. using [1, 7, 14] ?

@archmoj archmoj self-assigned this Apr 2, 2020
@nicolaskruchten
Copy link
Contributor Author

Yeah, please see if you can come up with a reasonable heuristic here.

@alexcjohnson
Copy link
Collaborator

There are 2 pieces of this: first, both hour and day ticks have positioning bugs if you use dtick explicitly:

  • the day tick labels are in the wrong places even for what they say they are (if you look at the “April 7 2020” tick, it’s actually at 16:00 on that day - why? That makes no sense, tick0 on that axis is an exact day (in fullLayout) so the tick should be at midnight, ie mid-break, so it should appear at the end of the break, or 09:00. And the April 6 tick is missing entirely.
  • in hour mode two or more overlapping tick labels at the same location?

Second is the question about how to display nice evenly-spaced ticks. I don't think this will be a problem with day ticks, once the bug part is solved those will be fine. But hour ticks are an interesting case. 1-hour dtick should be fine, unless users start specifying nightly breaks in increments of fractional hours... at that level of generality there's probably nothing we can do to ensure even tick spacing, we'll just need to live with funny spacing near the break. The multi-hour dtick values we have in our auto-dtick output are 2, 3, 6, and 12 hours, and none of those will make sense in all conditions, but going straight from 1 hour to 1 day won't be a great experience (even for 8-hour workdays that's a factor of 8 jump) so we need something in the middle. A proposal:

  • use a rounded form of bounds using the floor of the first item and the ceil of the second, to get a firstHour and numHours
  • shift tick0 to firstHour on some date, when using dtick more than 1 and less than 24 hours
  • try to find a reasonable algorithm for intermediate hours based on numHours. Maybe we always include "half the range" as Math.ceil(numHours / 2) - even though that will already be nonuniform for odd numHours - and continue halving until we get to <=3? Or first try to factor numHours and use all the factors, switching to this halving thing only if numHours is prime?

@archmoj
Copy link
Contributor
archmoj commented Apr 6, 2020

Demo demostrate similar issue using dtick equal 1-day and tick0 at "1970-01-01" (i.e. at zero UTC).

@archmoj archmoj mentioned this issue Apr 6, 2020
Closed
@nicolaskruchten nicolaskruchten modified the milestones: v1.54.1, v1.54.2 Apr 30, 2020
@alexcjohnson
Copy link
Collaborator

@archmoj let's split this issue into two pieces, as I describe in my comment, so we can be very clear about the behavior we're targeting:

  • If you explicitly specify tick0 and dtick, those should be respected exactly, but if any given tick falls inside a rangebreak, its displayed position should be moved to the very end of the break and only the tick closest to the end of the break should actually be displayed if there are multiple within the break.
  • If we're picking tick0 and dtick for you, we should pick values that maximize uniformity of spacing, but after having chosen a tick0 and dtick the behavior should follow the behavior of the first point.

Image tests may not be the best way to cover this, especially the second part. Certainly one or two images but jasmine tests will let us lock down many more cases. We want many different axes showing all spans of range (leading to any autodtick from 1 to 24 hours, with a focus on the values between 1 and 24 but showing exactly where we transition from 1 or 24 to the next intermediate value) and different spans of hour rangebreaks (removing anything from ~4 hours up to ~20 hours with different starting points. The most common I guess will be removing either 8 hours (eg [0, 8] or [21, 5]), 12 hours (eg [21, 9], [20, 8]), or 16 hours (eg [16, 8] or [17, 9]), maybe 15 too (eg [17, 8] or [18, 9]) so you see 9 hours in a day, showing both ends of an 8-hour workday ie 9am and 5pm or 8am and 4pm.

@archmoj archmoj mentioned this issue May 13, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@archmoj archmoj

Labels
bug something broken
Projects
None yet
Milestone
v1.54.2
3 participants
@nicolaskruchten @alexcjohnson @archmoj
0