Closed davidmiller closed 11 years ago
@davidmiller the problem is that your data is "bad": you've got year values which are like "2001/02". The graph system does not recognize these as dates correctly ...
You need to fix this and I've forked and done it for you :-)
http://explorer.okfnlabs.org/#rgrp/58685f35a48492453dee/view/graph
I've also switched to columns for graph (i know bar vs columns is weird - not my choice!) :-)
Shure, I could have done that :)
That's not really the bug I was reporting though.
Unfortunately, the thing I'm trying to graph is "bad". Some of the records are "12 months previous to interview periodically broken up by financial years" & thus traverse calendar years. Others are not. ( c.f. notes to Figure 1. [1] Crime in England and Wales, Year Ending December 2012 )
The historical decision to change the reference peroiods of the survey is not something I have the power to fix ;) (I can't remember who I lent the keys to the time machine to)
For 2001 - 2009 your forked version is thus misleadingly labelled :S
My guess is that somewhere some of the "Year" values get coerced to numeric types without checking to see if the whole set can be sanely coerced to numbers, and also Ignoring the datapackage declaration that says that the Year field, despite being called Year, despite the fact that some values can be sanely coerced to numbers, is, in fact a string :)
The Right Thing To Do (TM) IMHO is the same as e.g. [2] - evenly spaced stringy 'ticks'
[1] ) prior to 2001/02, CSEW estimates relate to crimes experienced in that calendar year. From 2001/02 onwards the estimates relate to crimes experienced in the12 months before interview, based on interviews carried out in that financial year; and c) the last two data points for both CSEW and police recorded crime refer to data collected in the rolling 12 month time period for the latest available two years (January to December).
[2] http://explorer.okfnlabs.org/#davidmiller/32f208f941f8bf64f961/view/graph
@davidmiller ah sorry, misunderstood. Hmmm that's a tough one. The current Recline flot graph auto converts to numbers if it can (if it didn't we'd really have issues with most graphs ...):
https://github.com/okfn/recline/blob/master/src/view.flot.js#L325
The way to fix it though isn't that hard - just make all the years proper strings. I've done this now, see:
http://explorer.okfnlabs.org/#rgrp/58685f35a48492453dee/view/graph
Right.
Thanks for the graph - that's exactly the high-level outcome I was after :)
ISTM that you would want to make sure that all elements of a series could be cast before applying the transformation.
e.g. something along the lines of https://github.com/davidmiller/recline/commit/c34d8c681cdc6a10d6a2cb8b6559b86f679aeaf4
That works for my case, but can't speak for others. Tests for that view don't inspire me with confidence to "refactor with impunity"...
Alternatively, your method works now && definitely doesn't break anyone else's graph :)
That looks pretty good. I have a real sense that there is some good refactoring that could happen in that view that would make testing on this sort of stuff easier.
c.f. Crime Survey For England & Wales exploration [1]
Bar ticks are textual descriptions of time periods (Source data unavoidably real-world-messy)
Would be great to have bars equally spaced && readable.
ALTERNATIVELY:
Please let me know what I'm doing stupidly in this example ;)
[1] http://explorer.okfnlabs.org/#davidmiller/d7831f56d0209d751680/view/graph