OmniGraphSketcher and dates
March 31, 2009 at 11:50 AM by Dr. Drang
I really don’t mean to be dumping on OmniGraphSketcher. It’s a program that’s intended to make sketching graphs easy. And it does that. But as you move away from sketching and into plotting real data—which OmniGraphSketcher can do and which Omni sells it as being able to do—you have to be careful. I’ve already discussed its problems with connectivity and how you can work around them. This post will tackle how OmniGraphSketcher handles dates.
In a nutshell, OmniGraphSketcher doesn’t handle dates. As far as I can tell, it has no date parser and no internal routines for calendar math. But you might be fooled into thinking it does.
Say you have this set of data in a spreadsheet:
You select and copy the two columns and paste into OmniGraphSketcher. This is what you get:
It’s putting the dates along the x-axis, so it looks like it knows what it’s doing, but it doesn’t. The labels along the x-axis are goofy: the distance between Jan 1 and Jan 10 is the same as the distance between Jan 10 and Jan 27. A quick look at the Data Inspection pane reveals the problem:
The dates are not being parsed and converted into values that reflect their relative spacing, they’re simply being converted into a uniform series of integers. The date strings are being used purely as labels for these integers.
[I should mention that the date problem is pretty obvious in this case. Because the dates have very different spacing and the values are uniformly spaced, anyone could immediately see that the graph was wrong. If the date spacing were more nearly uniform and the values more jumbled, the problems with the graph may have been hidden by its complexity. (Of course, if the date spacing is perfectly uniform, the graph will be correct.)]
If you’re wondering why OmniGraphSketcher works this way, it’s because it wants to be able to graph data like this:
If you were going to make a column chart of this data, you’d like the x-axis to display the names of the fruit. So for our original data, OmniGraphSketcher is treating the dates like fruit—it doesn’t know the difference.
OmniGraphSketcher’s inability to understand dates is a pretty significant deficiency, given how common it is to plot time histories of data. Luckily, many of these plots—e.g., monthly financials, yearly subscriptions, seasonal rainfall—can be plotted with uniform date spacing. But if the date spacing isn’t uniform, you need to transform the data before pasting it into OGS.
For the data in our example, converting the dates into day-of-year values is probably best.
The new column slipped in between the Date and Value columns has the formula:
=DATEDIF("12/31/2008",B2,"D")
which calculates the number of day between the given date and the last day of 2008. (This is using Numbers; I’m sure there’s a similar function in Excel. If you’re working with data in a text file instead of a spreadsheet, you can transform the data using one of the date libraries in Perl, Python, or Ruby.) Now we can copy the Day of year and Value columns and paste them into OmniGraphSketcher to get this:
This gives a correct view of how the value changes with time. If you prefer to have dates as the tick labels along the x-axis, you can edit them directly in OmniGraphSketcher. Just click to select the label, then double click to select its text and start typing the replacement text.
Here I’ve changed the tick spacing to 7 days and added a background grid.
This is pretty clearly not the best way to handle dates. I don’t mind the conversion of dates into numbers, but the relabeling bothers me because it can’t be automated and is subject to typos. Gnuplot is still my choice for automated date handling. But if you’re doing your graphs in OmniGraphSketcher and need to handle unevenly spaced dates, this is the way to do it.
Update 3/31/09
Beta 2 of OmniGraphSketcher was released several hours after I wrote this post, and with along the new beta there’s a new screencast in which time series are pasted in and plotted. The time series in the screencast are uniformly spaced (yearly), so the problems I described in this post don’t arise.
