rufuspollock-okfn / dataexplorer

View, visualize, clean and process data in the browser.
http://explorer.okfnlabs.org
148 stars 47 forks source link

Bar chart formatting #146

Closed davidmiller closed 11 years ago

davidmiller commented 11 years ago

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

rufuspollock commented 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!) :-)

davidmiller commented 11 years ago

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

rufuspollock commented 11 years ago

@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

davidmiller commented 11 years ago

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 :)

rufuspollock commented 11 years ago

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.