These are chat archives for sandialabs/toyplot

19th
Oct 2016
Johann du Toit
@johanndt
Oct 19 2016 00:07
Hi it's me again - always asking questions! :-) We've been generally using the Explicit locator to set our x ticks, but it's not exactly the best for time series... so I'm trying locator.Timestamp but it doesn't seem to want to play nice with bar plots.
blob
notice how the ticks are not center of the bars
whereas explicit was nicely in the center:
blob
Johann du Toit
@johanndt
Oct 19 2016 00:15
the reason for wanting to move away from explicit is if you imagine squeezing in more bars the labels start to overlap.
Johann du Toit
@johanndt
Oct 19 2016 01:05
looking through the code I think I might have to write my own locator - kind of a cross between explicit and uniform - but I'll wait for an answer here first. :-)
Timothy M. Shead
@tshead
Oct 19 2016 04:58
OK, where to start … the reason tick marks line-up with bar centers by default is that by default bars are centered on integers 0, 1, 2, … N-1, and the default Extended tick locator favors putting ticks in “good” (in this case integer) locations. Of course, you’re free to put the edges of your bars anywhere you want (for example: if you’re displaying a histogram where the bin widths vary), in which case the default ticks won’t line-up nicely anymore.
In your case, you’re using the Timestamp locator, which expects the input domain to be Unix Epoch UTC timestamps. So step one will be to explicitly specify the left and right edges of the bars, using timestamps for the periods in question. Looks like you’re already doing this.
Timothy M. Shead
@tshead
Oct 19 2016 05:07
Next thing is that Timestamp will choose a “good” granularity and range of ticks to cover the domain, in your case, weekly ticks over a period of a month. It assumes that the tick for a week will be located on the first day of the week, and the tick for a day will be located at midnight. That, plus possible timezone errors if you didn’t convert your bar edges to UTC, would explain the consistent offset between the ticks and your bars. I also don’t recall off the top of my head which day is considered the “first” day of the week, Sunday or Monday. See arrow for details.
Timothy M. Shead
@tshead
Oct 19 2016 05:12
We could parameterize Timestamp in all sorts of fancy ways, to allow you to specify what part of the week to display, when displaying weeks, which day is the first day, etc. But I think that that would be confusing.
There’s also the problem that different human-oriented periods of time may vary in duration (think February), which could lead to on-the-one-hand-nonintuitive-but-on-the-other-hand-annoying differences in the width of a bar. So in general I don’t think you want to display bars in the timestamp domain in general.
Johann du Toit
@johanndt
Oct 19 2016 05:15
Hi @tshead - thinking about it, I think it might just be timezone offset issues - or rather "time of day".
Timothy M. Shead
@tshead
Oct 19 2016 05:16
What I would suggest is writing a factory function for Explicit that makes it easier for you to label the time periods you want - daily, weekly, etc.
Johann du Toit
@johanndt
Oct 19 2016 05:16
yeah - I agree. I think what I'll do is write a locator like explicit which has nice integer locations along with the label formatting I want.. and then allowing it to nicely space labels if they are too close to each other.
Timothy M. Shead
@tshead
Oct 19 2016 05:17
Sounds like a winner!
Johann du Toit
@johanndt
Oct 19 2016 05:17
one other thing I noticed with Explicit is that it won't run the formatting function on labels if you only specify labels during creation.
I kind of worked around this, but it was not what I expected when I passed something to the format parameter in the constructor
but I get now that it's for generating labels from locations. so makes sense.
anyways - no question there... I'll let you know how I go. Thanks for the quick response as always!
Timothy M. Shead
@tshead2
Oct 19 2016 21:42
@johanndt - one thing to keep in mind is that at the moment, locators don’t have enough information to determine whether labels are "too close" or not - while they know the content of the labels they’re preparing, they don’t know the range (available space) or the label font size(s). This is a longstanding limitation of the current design. So you might want to focus in the short-term on allowing users to explicitly specify which labels to omit when things get crowded, or some other top-down, user driven paramaterization.
Johann du Toit
@johanndt
Oct 19 2016 23:41
That's fine Timothy. I wrote the locator - was actually pretty simple in the end. At the point where I initialize the locator I know the canvas width, so I've just got a simple little ratio of "count per width" which I pass into the locator's count parameter. It seems to work fine since I have a rough idea of how the dates are formatted. However this reminds me of the "horizontal legends" request from a while back - in the end I used a function in PIL (Pillow) which can give a pretty close estimate of the dimensions of text rendered in a specific font. That also seems to work really well for us. It does use PIL though - but that is an (optional) dependency of reportlab already.
Happy to share the code if you want.