Skip to content

Relocate first tick when falls inside a rangebreak #4734

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

Closed
wants to merge 4 commits into from

Conversation

archmoj
Copy link
Contributor

@archmoj archmoj commented Apr 6, 2020

Fixes #4722,
this PR improves tick positioning by moving the first tick when it falls inside a rangebreak.

Demos: before vs after.

@plotly/plotly_js

@archmoj archmoj added bug something broken status: reviewable labels Apr 6, 2020
@archmoj archmoj requested a review from alexcjohnson April 6, 2020 18:47
@nicolaskruchten
Copy link
Contributor

So here the ticks are all at 16:00 which is weird

@archmoj archmoj requested review from alexcjohnson and removed request for alexcjohnson April 26, 2020 21:13
@archmoj archmoj added this to the v1.54.1 milestone Apr 30, 2020
@nicolaskruchten nicolaskruchten modified the milestones: v1.54.1, v1.54.2 May 4, 2020
@alexcjohnson
Copy link
Collaborator

What's going on in test/image/baselines/axes_breaks-gridlines.png ? The ticks seem to have moved to the last day of the month, which means "Mar 2015" is actually at March 31, ie essentially where an April 1 tick should have been, so it looks like we're labeling April as March.

This seems consistent on the autorange view, but if you zoom in a bit to 1-month ticks things get worse: some ticks seem to be on the last day of the month, others on the first, so sometimes you get two identical ticks:
Screen Shot 2020-05-06 at 4 19 40 PM

I guess I'm nervous about doing this at the level of tick0 in general - particularly if you have some funny non-periodic breaks, shifting tick0 could result in other ticks that don't need to move at all getting moved. Seems to me the solution needs to be about moving each individual tick out of a break if it falls within one.

This PR also still has the odd spacing issue for automatically-determined tick0 and dtick values. See test/image/baselines/axes_breaks-weekends-weeknights.png - to solve that we'll likely need to adjust this algorithm when there are hourly ticks > 1 h along with hour rangebreaks.
Screen Shot 2020-05-06 at 4 38 45 PM

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

Successfully merging this pull request may close these issues.

Tick labels when using hourly rangebreaks
3 participants