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

rangebreaks, weekly tick labels and period label mode #5062

Closed
nicolaskruchten opened this issue Aug 11, 2020 · 11 comments · Fixed by #5089
Closed

rangebreaks, weekly tick labels and period label mode #5062

nicolaskruchten opened this issue Aug 11, 2020 · 11 comments · Fixed by #5089
Assignees
Labels
bug something broken

Comments

@nicolaskruchten
Copy link
Contributor

I wanted to test the interaction of weekly tick labels, rangebreaks and period label mode (to see if the period mode would take into account the rangebreaks, or if the week number would be too far to the right!) but the ticks actually don't show up at all in this configuration: https://codepen.io/nicolaskruchten/pen/NWNGpQO

@nicolaskruchten nicolaskruchten added the bug something broken label Aug 11, 2020
@nicolaskruchten
Copy link
Contributor Author

@alexcjohnson can you think of a reasonable way to handle rangebreaks and period mode together? The weekly case for iso-formatted weekly labels is the one that will look ugly: the middle of a Monday week is Thursday noon, whereas the the middle of a Monday week less weekends is Wednesday noon, meaning the label will be 20% farther to the right than it should be in such a case.

@alexcjohnson
Copy link
Collaborator

Nice catch @nicolaskruchten - seems to me this is a tightly-scoped case:

  • dtick of an integer number of weeks
  • and weekly rangebreaks
  • and week number as the period-defining component of tickformat

Then for the label position, rather than half a period away from the preceding tick, we use the midpoint between two rangebreak edges containing successive weekends - accounting for additional nightly or holiday breaks.

So if you have weekly (removing weekends) and nightly breaks (for example 9am to 9pm), you'll ignore the weeknight breaks and go halfway between Monday 9am and Friday 9pm, which is Wednesday 3pm. And if Monday is a holiday, you'll go halfway between Tuesday 9am and Friday 9pm, which is Thursday 3am - we'll have to ensure this still gets drawn despite being in a nightly break, but that's OK, there's no tick there.

Things get weird if there's a Tuesday or Thursday holiday and the Monday or Friday is not a holiday - that might put one label in a weird place with this scheme. Could presumably fix that by calculating the label position in screen space rather than data space but that may be more complicated than it's worth. I'm not even going to talk about what would happen if you put weekend breaks on Tuesday and Wednesday...

@nicolaskruchten
Copy link
Contributor Author

We could do a super-scoped thing or we could do something a bit more principled and say "the position of the ticklabel is drawn physically halfway between the outermost range within the interval it represents" so for the case of a Monday-week with Wednesday and Sunday hidden, those positions are basically Monday 00:00 and Saturday 23:59:59, spanning 5 days (due to the missing Wednesday) so we start at Monday 00:00 and we add 2.5 days, which taking into account the missing Wednesday drops us on Thursday at noon. That'd be the most flexible/scalable thing, but I imagine that this computation is totally out of order compared to what we do right now so maybe a narrowly-targeted thing for weeks makes sense.

Either way let's see what my Pen looks like once #5065 is merged :)

@nicolaskruchten
Copy link
Contributor Author

Hmm actually even with a bundle from #5065 things don't look awesome... https://codepen.io/nicolaskruchten/pen/dyMYEBm?editors=0010

@alexcjohnson
Copy link
Collaborator

My reasoning for suggesting the tight scope is that when the range breaks aren't phase locked with periods, keeping the label at the central data value of the period is likely to be more accurate - and I suspect it'll make more sense to the user if there's one smaller (or larger) gap between labels where there's a rangebreak, rather than three altered gaps - one at the rangebreak and one on either side. At that point it may be impossible to see what the "real" spacing is anymore.

Whereas when the range breaks and periods ARE phase locked, you've effectively used the range breaks to modify the meaning of the period, and every label is going to move the same amount (except when further modified by holidays) so things will still look consistent.

@nicolaskruchten
Copy link
Contributor Author

I'll buy that. Dropping weekends when you have monthly tick labels can cause some alignment issues if the last or first two days of the month are in the rangebreak, but that'll cause a positioning error on the order of 4% which might be acceptable... will have to check.

@nicolaskruchten
Copy link
Contributor Author

Well... monthly does seems slightly odd to my eye: https://codepen.io/nicolaskruchten/pen/MWyaNRx?editors=0010

@nicolaskruchten
Copy link
Contributor Author

The Jan label on the left...

image

@archmoj
Copy link
Contributor

archmoj commented Aug 13, 2020

Updated codepen using the build from #5065 displays the labels.

@nicolaskruchten
Copy link
Contributor Author

OK nice, and this pen does demonstrate the problem in the weekly case.

I worry that a monthly-period bar graph will look really bad with weekend range-breaks also (much more marginal case)

@archmoj
Copy link
Contributor

archmoj commented Aug 13, 2020

OK. Let's keep this issue open until we test those cases.

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 a pull request may close this issue.

3 participants