D3 learning Part 3 – linking to live data

Previously I’ve managed to display a simple d3.js visualisation on the site through a couple of different methods. Next step is to go from proving a general concept to actually displaying some data that might be interesting.

So, what steps did I go through:

1. Find some lovely data

I wanted something interesting to play with that was home related; Mendip Council’s open data offerings are less than impressive, so national agencies it is; I recalled there was and there’s a rainfall monitoring station only a mile or so from home. So why not try to build a graph that shows recent rainfall (say, the last 100 recording incidences) for where I live (notwithstanding the obvious empirical alternatives to understanding like looking out of the window)

The data is already well defined and it was easy to determine the Frome station (531108) thanks to the  EA API demonstrator.

A bit of digging with that demonstrator showed it is possible  to call  a .csv file with the data that I want to visualise in a fairly basic three column format.

2. Find a viz

I have found a simple chart I like the look of (well, actually it’s ugly as hell, but I’ve got a load of time data and a value – a basic line chart is a good starting point.)

First thing I did was upload the csv and the html files to my site to check that there wasn’t something odd that WordPress might do with them.

There wasn’t

3. Make that viz look at the data

Now I need to stick my data to the viz. The data being produced by the  .csv associated with that example vis obviously doesn’t look like my EA data. I got the index.html into a text editor and started to look at the variables I think define the data.

4. The Detective work 1) Date formatting

The Environment Agency data isn’t in the same format as that in the example. So finding the right bit of code which determines that was the first job. It’s

var parseDate = d3.time.format("%d-%b-%y").parse

(which was easy to determine thanks to excellent notation in the d3 code)

D3 has its own formatting guidelines (the documentation was comprehensive and made a broad level of sense. We are relatively fortunate in that our EA data comes in a standard ISO data format for date/time (ISO 8601). A bit of googling gave a d3 format with which to replace the bits in the “”, specifically

"%Y-%m-%dT%H:%M:%SZ"

(source)

5) More detective work 2) Calling the csv file.

Rather than calling from a static csv file already on my site, I want to link to that live csv (that’s the exciting bit)

d3.csv("http://intelligentplaces.org.uk/wp-content/uploads/2017/02/lineclean.csv", function(error, data) {
 data.forEach(function(d) {
 d.date = parseDate(d.date);
 d.close = +d.close;
 });

I want to get it from the csv I discussed earlier. Which means fiddling with this a bit…

I *think* the d.{variable} bit is where we’re telling d3 how to handle the individual column in the csv.

Assuming that is the case, then I tried

d3.csv("http://environment.data.gov.uk/flood-monitoring/id/stations/531108/readings.csv?_limit=100&_sorted¶meter=rainfall", function(error, data) {
 data.forEach(function(d) {
 d.DateTime = parseDate(d.date);
 d.value = +d.close;

And…

Nothing.

A whole page of blankness.

6) Error checking – following through the fields (and double checking blank values).

Now the fact that there is simply nothing to be seen leads me to believe that either the data is simply not there (and because the data is defined relative to itself, there’s nothing to show from nothing) or that I’ve bodged up one of the above. I’ve no idea whether there’s error handling built into this – I’m assuming not.

First I did a formatting/sense check on the code; I amended all the other references to the previous fields with my newly defined ones and I got a really boring graph

Now it’s not rained much recently (it’s snowed a bit, but I’m guessing a “tipping bucket” needs a bit more than some wimpy flurries to register).

So I swapped weather station URL for somewhere near the Pennines (559100R) where there’d been a bit more rain recently and…

Whooop!, data, visualized using code and linked to a live source.

I have now reset the live data back to Frome.

7) Note next steps.

This worked to prove the concept; but there’s a lot more to do before

  •  Find a way of displaying something when there’s no data because of a nil return, as opposed to a processing error, can’t immediately tell at the moment.
  • Find a visualisation that isn’t boring as hell. is more visually appealing
  • Find out more about the underlying data, could there be some some appropriate presets for the axes?.
  • Work out how to have a bit more control over the x axis, those dates aren’t pretty and labelling is essential.
  • Marvel at the decades you’ve been working with data and only just discovered that axes is the plural of axis.

We need to talk about (the small-area) Brexit (voting data)

The BBC recently published a piece on small area referendum voting data. The information was gathered, through Freedom of Information requests, from less than half the local authorities (acting as ‘designated counting areas’) who administered the referendum. It’s a rather problematic piece of work.

This analysis is riddled with errors; there could be evidence of illegal practice; there are clear opportunities to improve practice around election data and the implications of this release have relevance to other realms of government data.

It is incorrect

The analysis and the underlying data are flawed for a number of reasons which immediately spring to mind;

Postal votes weren’t counted spatially. The article repeatedly notes that postal votes aren’t allocated to the areas of their electors beyond the principle area of the election (this is technically untrue, they’re *probably* not allocated to areas) but makes no significant attempts to account for this error.

Mass FOI mail-outs are not and cannot be a systematic data collection method. 44% of counting areas (rather, their corresponding local authorities) responded. No consideration of statistical confidence is made in the analysis, neither is any proportional demographic assessment conducted between responder and non-responders.

At its most basic level, comparing voters with population involves several layers of extrapolation. Even in an area with unprecedented high turnout it can feel spurious. Turnout is a subset of electorate, itself a subset of the eligible voters which in its turn is a subset of the population. The practice of sticking whole populations’ demographics from some nationally standardised data (usually the Census –  Hello 2011, don’t you feel like a lifetime ago!) on a scatterplot against the electorate data is, to be polite, rather crude.

I’d add that none of the above should necessarily invalidate the analysis; the disciplines of social research/political science are riddled with bias and I’ve seen far less rigorous analysis published to far greater acclaim. I do think they suggest that they mean the data warrants far more thought and debate than has so far accompanied it.

Some of it is possibly illegal.

A quick tangent into electoral practice: When you vote, you’re given an elector number. This is your sequence on the electoral register within an individual polling district. These are geographical areas allocated to individual ballot boxes in polling stations. These share boundaries with the relevant electoral geography for the election in question. Local government elections being the smallest geographical election they are also (usually) in line with parishes and wards.

And so, to the article:

A few councils released their data at remarkably localised levels, down even to individual polling districts (ie ballot boxes)…or clusters of two/three/four districts… Most places mixed boxes of postal and non-postal votes for counting, so generally it’s not possible to draw comparative conclusions. However there were a few exceptions which recorded them separately, or included a very small number of non-postal votes with the postals.

As identified by @richgreenhill on Twitter, it seems that the data released gives evidence that rule 46(2) of the referendum act which require that votes from individual ballot boxes are mixed with another and that postal votes are counted alongside individual ballots was broken. It is worth caveating here that there may be reasonable responses to all these (multi-polling district ballot boxes being one immediately mentioned).

There is also no legal requirement to produce electorate statistics at an area lower than the principle counting area. The Electoral Commission’s guidance (p3) notes only the requirement for a Counting Officer (responsible officer for each Counting Area) to declare for their voting area. This means that the process of allocation votes to a smaller geography is based on local administrative practice. Elections may be heavily regulated and systematic exercises, but there is a wealth of different on-the-ground practice around management and counting of papers and onward dissemination of data not explicitly prescribed in statutory notices. In addition to creating what I would suggest is at least a legal grey area this creates a further challenge to the validity of the data.

There is a case for change.

Whether a local authority made the internal, administrative decision to collate small-area results, the data was simply not collected for this purpose. Every authority who responded would have been justified in saying ‘no’; but many released. That such a large volume of data could be gathered with relative ease suggests that the standard practice, guidance and legislation is deficient.

Does this make it any different from any other Open Data on its slow route to the public domain or anything different from the next speculative FOI-based bit of journalism? Perhaps not, perhaps this is simply all part of the process, part of the ebb and flow of an increasingly data literate society. Whatever the context of the situation, I would argue that the above challenges mean continuing to release data in this way is not desirable.

The Electoral Commission are well placed to take a view on this, perhaps with support from organisations such as the Open Data Institute and I think it would be in their interests to do so sooner rather than later. I would imagine that we’ll be seeing more Freedom of Information requests of this nature over time and data collection practices will inevitability become more varied. In a time when public perception of political institutions is challenging and intense political divisions are presented as material fact, it seems the time is right to put some thought into this practice.

There are wider implications for data release.

If there does turn out to be evidence of electoral malpractice in this data, then whose responsibility is it to identify that? Is it individual local authorities, or does the author/requester have an accountability to understand the legal context in which they operate or is it sufficient to leave it to a wider, interested community? My initial take is that administrative data is now so prevalent in the public realm that no one stakeholder can practically take sole accountability for it, regardless of legal reality.

Finally, looking towards the end of the article, we can see elements which are relevant to any non-standardised release of data.

…releasing the information was up to the discretion of councils. While some were very willing, in other cases it required a lot of persistence and persuasion…A few places such as Birmingham released their… data …on their own initiative, but in most cases the information had to be obtained by us requesting it directly, and sometimes repeatedly, from the authority.

Whatever the outcome of this (and ongoing confusion is by far the most likely) debate, there are lessons about how creators and users behave with re-purposed data. It’s never been more critical to think about what we should legitimately, pragmatically and ethically do with it.