Clamp ContinuousTimeScale ticks to round(er) values

[hsuominen]

I'm implementing a zoomable time axis (from seconds up to months, ) and ContinuousTimeScale works almost perfectly out of the box but for certain zoom levels the resulting ticks could be improved.

As the ideal result seems quite case specific I was wondering if it would make sense to add the ability to pass custom tickIntervals through to the Scale? Essentially what I would want is to modify this https://github.com/gampleman/elm-visualization/blob/master/src/Visualization/Scale/Time.elm#L51 but due to most of the machinery being private modifying it without forking the whole library seems a no go.

[gampleman]

Interesting question. I feel like I would like to hear a bit more details about what you are doing and what the specific issues you are running into are. Passing in a custom tickIntervals isn't entirely straightforward without further complicating scales which are already fairly complex.

On another note, Axis that ship with elm-visualization provide an option for you to pass in custom ticks, so you can implement your own functionality if need be, while still using the provided scales for other purposes.

[hsuominen]

To demonstrate the problem below are some screen shots at different zoom levels (effectively expanding the time range)

This looks good, but there is a date switch at 12:00 which we miss

Zooming out we get the hours together with the date changeover, this is great

Going further out we miss the date change again

Which gets especially confusing further out

Going out further things are great

Thinking about this more, messing with tickIntervals would not solve the issue, as it stems from the axis limits and whether the autocomputed ticks happen to fall on the "magic" values (eg. date/month change).

As I'm working with a fully dynamic canvas (the user can zoom in and out, and pan around) I don't want to set the axis limits to "round" numbers unnecessarily. I could of course compute tick positions and pass them directly to Axis but this seems overkill seeming that the scales are doing effectively the same job behind the scenes.

Now I'm thinking what might make most sense is to add further rounding to the start/end values inside ticks (https://github.com/gampleman/elm-visualization/blob/master/src/Visualization/Scale/Time.elm#L48). Date.Extra.range implements rounding at the level of the intended time interval, but I think to solve this issue we would need to perform rounding at a longer time interval.