champagne anarchist | armchair activist

Data

Python script to import .sps files

In a post about voting locations (in Dutch) I grumbled a bit about inconsistencies in how Statistics Netherlands (CBS) spells the names of municipalities and why don’t they include the municipality codes in their data exports. This afternoon, someone who works at CBS responded on Twitter. She had asked around and found a workaround: download the data as SPSS. Thanks!

CBS offers the option to download data as an SPSS syntax file (.sps). I wasn’t familiar with this filetype, I don’t have SPSS and I couldn’t immediately find a package to import this filetype. But it turns out that .sps files are just text files, so I wrote a little script that does the job.

Note that it’s not super fast; there may be more efficient ways to do the job. Also, I’ve only tested it on a few CBS data files. I’m not sure it’ll work correctly if all variables have labels or if the file contains not just data but also statistical analysis.

That said, you can find the script here.

How to automate extracting tables from PDFs, using Tabula

One of my colleagues needs tables extracted from a few hundred PDFs. There’s an excellent tool called Tabula that I frequently use, but you have to process each PDF manually. However, it turns out you can also automate the process. For those like me who didn’t know, here’s how it works.

Command line tool

You can download tabula-java’s jar here (I had no idea what a jar is, but apparently it’s a format to bundle Java files). You also need a recent version of Java. Note that on a Mac, Terminal may still use an old version of Java even if you have a newer version installed. The problem and how to solve it are discussed here.

For this example, create a project folder and store the jar in a subfolder script. Store the PDFs you want to process in a subfolder data/pdf and create an empty subfolder data/csv.

On a Mac, open Terminal, use cd to navigate to your project folder and run the following code (make sure the version number of the tabula jar is correct):

for i in data/pdf/*.pdf; do java -jar script/tabula-0.9.2-jar-with-dependencies.jar -n -p all -a 29.75,43.509,819.613,464.472 -o ${i//pdf/csv} $i; done

On Windows, open the command prompt, use cd to navigate to your project folder and run the following code (again, make sure the version number of the tabula jar is correct):

for %i in (data/pdf/*.pdf) do java -jar script/tabula-0.9.2-jar-with-dependencies.jar -n -p all -a 29.75,43.509,819.613,464.472 -o data/csv/%~ni.csv data/pdf/%i

The settings you can use are described here. The examples above use the following settings:

  • -n: stands for nospreadsheet; use this if the tables in the PDF don’t have gridlines.
  • -p all: look for tables in all pages of the document. Alternatively, you can specify specific pages.
  • -a (area): the portion of the page to analyse; default is the entire page. You can choose to omit this setting, which may be a good idea when the location or size of tables varies. On the other hand, I‘ve had a file where tables from one specific page were not extracted unless I set the area variable. The area is defined by coordinates that you can obtain by analysing one PDF manually with the Tabula app and exporting the result not as csv, but as script.
  • -o: the name of the file to write the csv to.

In my experience, you may need to tinker a bit with the settings to get the results right. Even so, Tabula will sometimes get the rows right but incorrectly or inconsistently identify cells within a row. You may be able to solve this using regex.

Python (and R)

There’s a Python wrapper, tabula-py that will turn PDF tables into Pandas dataframes. As with tabula-java, you need a recent version of Java. Here’s an example of how you can use tabula-py:

import tabula
import os
import pandas as pd

folder = 'data/pdf/'
paths = [folder + fn for fn in os.listdir(folder) if fn.endswith('.pdf')]
for path in paths:
    df = tabula.read_pdf(path, encoding = 'latin1', pages = 'all', area = [29.75,43.509,819.613,464.472], nospreadsheet = True)
    path = path.replace('pdf', 'csv')
    df.to_csv(path, index = False)

Using the Python wrapper, I needed to specify the encoding. I ran into a problem when I tried to extract tables with varying sizes from multi-page PDFs. I think it’s the same problem as reported here. From the response, I gather the problem may be addressed in future versions of tabula-py.

For those who use R, there’s also an R wrapper for tabula, tabulizer. I haven’t tried it myself.

Call tabula-java from Python

[Update 2 May 2017] - I realised there’s another way, which is to call tabula-java from Python. Here’s an example:

import os

pdf_folder = 'data/pdf'
csv_folder = 'data/csv'

base_command = 'java -jar tabula-0.9.2-jar-with-dependencies.jar -n -p all -f TSV -o {} {}'

for filename in os.listdir(pdf_folder):
    pdf_path = os.path.join(pdf_folder, filename)
    csv_path = os.path.join(csv_folder, filename.replace('.pdf', '.csv'))
    command = base_command.format(csv_path, pdf_path)
    os.system(command)

This solves tabula-py’s problem with multipage pdf’s containing tables with varying sizes.

Trick the trackers with a flood of meaningless data

A couple years ago, Apple obtained a patent for an intriguing idea: create a fake döppelganger that shares some characteristics with you, say birth date and hair colour, but with other interests - say basket weaving. A cloning service would visit and interact with websites in your name, messing up the profile companies like Google and Facebook are keeping of you.

I don’t think anyone has implemented it. But now I read at Mathbabe’s blog about a similar idea that actually has been implemented. It’s called Noiszy and it is

a free browser plugin that runs in the background on Jane’s computer (or yours!) and creates real-but-meaningless web data – digital «noise». It visits and navigates around websites from within the user’s browser, leaving your misleading digital footprints wherever it goes.

Cool project. However, it has been argued that the organisations that are tracking you can easily filter out the random noise created by Noiszy.

My failed attempt to build an interesting twitter bot

In 2013, I created @dataanddataviz: a twitter account that retweets tweets about data analysis, charts, maps and programming. Over time, I’ve made a few changes to improve it. And @dataanddataviz did improve, but I’m still not satisfied with it, so I decided to retire it.

There are all sorts of twitter bots. Often, their success is measured by how many followers they gain or how much interaction they provoke. My aim was different. I wanted to create an account that is so interesting that I’d want to follow it myself. Which, of course, is a very subjective criterion (not to mention ambitious).

Timing

First a practical matter: it has been suggested that you can detect twitter bots by the timing of their tweets. The chart below (inspired by this one) shows the timing of posts by @dataanddataviz.

I randomized the time at which @dataanddataviz posts. The median time between tweets is about 100 minutes (I lowered the frequency last January, as shown by the dark green dots). There is no day/night pattern. If tweets were posted manually, you’d expect a day/night pattern.

Selecting tweets

Initially, I collected tweets using search terms such as dataviz, data analysis and open data. From those tweets, I tried selecting the most interesting ones by looking how often they had been retweeted or liked. @dataanddataviz would retweet some of the more popular recent tweets.

This was not a success. For example, there are quite a few people who tweet conspiracy theories and include references to data and charts as «proof». Sometimes, their tweets get quite a few likes and retweets, and @dataanddataviz ended up retweeting some of those tweets. Awkward.

I decided to try a different approach: follow people who I trust, and use their retweets as recommendations. If someone I trust thinks a tweet is interesting enough to retweet, then it may well be interesting enough for @dataanddataviz to retweet.

The people who I follow tweet about topics like data and charts, but sometimes they tweet about other topics too. To make sure tweets are relevant, I added a condition that the text of the tweet contains at least one «mandatory» term (e.g. python, d3, or regex). I also added a condition that none of a series of «banned» terms was in the text of the tweet. I used banned terms for two purposes: filter out tweets about job openings and meetings (hiring, meetup) and filter out hypes (bigdata, data science).

This approach was a considerable improvement, but I still wasn’t happy. Sure, most of @dataanddataviz’ retweets now were relevant and retweets of embarrassing tweets became rare. But too few retweets were really good.

Predict quality?

I tried if I could predict the quality of tweets. I created an interface that would let me rate tweets that met the criteria described above: retweeted by someone I follow; containing at least one of the required terms and containing none of the banned terms.

The interface shows the text of the tweet and, if applicable, the image included in it, but not the names of the person who originally posted the tweet and the recommender who had retweeted it. This way, I forced myself to focus on the content of the tweet rather than the person who posted it. Rating consisted in deciding whether I would retweet that tweet.[1]

I rated 1095 tweets that met the basic criteria. Only 130 were good enough for me to want to retweet them. That’s not much.

I looked if there are any characteristics that can predict whether a tweet is - in my eyes - good enough to retweet. For example: text length; whether the text contains a url, mention or hashtag; and characteristics of the person who originally posted the tweet, such as account age; favourites count; followers count; friends count; friends / followers ratio; statuses count and listed count. None of these characteristics could differentiate between OK tweets and good tweets.

I also looked whether specific words are more likely to appear in good tweets - or vice versa. This was the case, but most examples are unlikely to generalise (e.g., good tweets were more likely to contain the word air or #demography).

Conclusion

I didn’t succeed in creating a retweet bot I’d want to follow myself. @dataanddataviz’ retweets are generally OK but only occasionally really good.

Also, I couldn’t predict tweet quality. Perhaps it would make a difference if I used a larger sample, or more advanced analytical techniques, but I doubt it. Subjective quality appears to be difficult to predict - which shouldn’t come as a big surprise (in fact, Twitter itself isn’t very good at predicting which tweets I’ll like, judging by their You might like suggestions).

Meanwhile, I found that since November, more of the tweets retweeted by @dataanddataviz tend to have a political content. Retweeting political statements isn’t something I want to delegate to a bot, so that’s another reason to retire @dataanddataviz.


  1. Obviously, what is being measured is a bit complicated. Whether I’d want to retweet a tweet depends not only on its quality, but also on its subject. For example, I’m now less inclined to retweet tweets about R than I was a couple years ago, because I started using Python instead of R.  ↩

Zijn er genoeg stemlocaties

Open State heeft de locaties van stembureaus verzameld en ze als open data beschikbaar gesteld. Daaruit blijkt dat er woensdag op een kleine negenduizend plekken gestemd kan worden.

Is dat genoeg? Over ongeveer die vraag is vorig jaar een rechtzaak gevoerd. De Brabantse gemeente Son en Breugel had besloten om bij het Oekraïnereferendum drie stembureaus in te richten, in plaats van de gebruikelijke tien. Forum voor Democratie is toen samen met twee inwoners naar de rechter gestapt.

Uit onderzoek zou zijn gebleken «dat er causaal verband bestaat tussen, kort gezegd, de stemfaciliteiten die aan een kiezer worden geboden (aantal, afstand, locatie) en de mate waarin die kiezer gebruik zal maken van zijn stemrecht». Helaas ontbreekt een bronvermelding.

Uit het verslag van de rechtzaak blijkt dat er niet zoveel geregeld is. In de wet staat alleen dat een gemeente tenminste één stembureau moet inrichten. In de praktijk hanteren gemeenten een informele norm van 1.200 kiesgerechtigden per stembureau. De rechter neemt die informele norm niet zonder meer over, maar kwam wel met een nieuwe regel: je mag niet zomaar het aantal stembureaus drastisch verlagen. Met als argument dat gemeenten zich ‘servicegericht’ op moeten stellen.

Zoals gezegd deden twee inwoners uit Son en Breugel mee aan de rechtzaak. Ze kampen met gezondheidsklachten en wilden daarom graag dat hun ‘vaste’ stembureau om de hoek weer open zou gaan. Daar ging de rechter niet in mee: er is «geen recht voor de individuele burger op het instellen van een stembureau op een afstand op 50 meter van zijn woning, ook niet als die burger slecht ter been is».

Stemlocaties per gemeente

Een analyse van de stemlocaties in Nederland laat zien dat het aantal stemlocaties sterk samenhangt met het aantal kiesgerechtigden in een gemeente. Gezien de informele norm die gemeenten hanteren was dat ook wel te verwachten.

In een doorsnee gemeente is er een stemlocatie per ruim 1.400 kiesgerechtigden. Dat is meer dan de informele norm van 1.200, maar dat heeft wellicht te maken met het verschil tussen stemlocaties en stembureaus (zie Methode).

Er zijn relatief weinig stemlocaties in gemeenten als Haaren, Capelle a/d IJssel (allebei ongeveer 2.800 kiesgerechtigden per locatie) en Heerenveen (3.550). In Son en Breugel kan woensdag op 9 locaties worden gestemd; dat betekent gemiddeld 1.410 kiesgerechtigden per locatie. Een doorsnee gemeente, wat dat betreft. Maar het favoriete stembureau van de twee inwoners die naar de rechter waren gestapt, zit er niet meer bij.

Stemlocaties per wijk

Uit de referendumzaak blijkt dat er wel een informele norm bestaat over het aantal stembureaus in relatie tot het aantal kiesgerechtigden, maar niet over de afstand tot een stembureau. De meeste Amsterdammers zullen geen moeite hebben om een stembureau op loopafstand te vinden, maar hoe zit dat op het platteland? Daar valt wel iets over te zeggen met een analyse op wijkniveau.

Het aantal kiesgerechtigden per wijk is denk ik niet formeel bekend, maar het aantal inwoners natuurlijk wel. Ook dat hangt duidelijk samen met het aantal stemlocaties: hoe meer inwoners in een wijk, hoe meer stemlocaties. Maar de vraag is of er relatief meer stemlocaties zijn in dunbevolkte gebieden. De grafiek hierboven laat het antwoord zien: ja, hoe lager de bevolkingsdichtheid, hoe hoger het aantal stemlocaties per 10.000 inwoners.

Hoe dat in de praktijk ongeveer werkt, is te zien op de kaart hieronder.

kaart

Dunbevolkte gebieden van ons land hebben vaak relatief veel stemlocaties. Dit geldt bijvoorbeeld voor delen van Zeeland, Limburg, Oost-Nederland en vooral Noord-Nederland. Deels geldt dat ook voor de Waddeneilanden, maar daar zijn altijd extra stemmers vanwege het toerisme. De donkergroene wijken zijn vaak (maar zeker niet altijd) wijken met hoogstens een paar honderd inwoners, die toch een stembureau hebben gekregen.

Al met al lijkt het erop dat gemeenten bij de inrichting van stembureaus niet alleen kijken naar het aantal kiesgerechtigden, maar ook naar de afstand die ze moeten afleggen. Klinkt redelijk. Als je echt wil weten hoe het zit, dan zou je eigenlijk voor alle woonadressen in Nederland moeten uitrekenen hoe ver de dichtstbijzijnde stemlocatie is. Die klus laat ik graag aan iemand anders over.

UPDATE - DUIC heeft ondertussen voor de stad Utrecht de afstand van woonadressen tot stemlocaties laten berekenen. De maximale afstand is 3,5 kilometer; de mediaan 332 meter.

Methode

De gegevens over stemlocaties zijn verzameld en beschikbaar gesteld door Open State. Soms zijn er op een locatie meerdere stembureaus, althans in Amsterdam is dat vrij gebruikelijk. Open State lijkt in principe meerdere stembureaus op dezelfde locatie als één locatie te hebben opgevat. Toch komt het een enkele keer voor dat dezelfde locatie (identieke coördinaten) meer dan één keer in het bestand zit; ik denk dat die erdoor zijn geslipt. In het Open State-bestand zitten 9018 locaties; nadat ik de duplicaten had verwijderd waren dat er 8744.

Gegevens over kiesgerechtigden per gemeente zijn te vinden bij het CBS (in dit bestand zijn gemeenten Gennep, Schijndel en Sint Oedenrode nog opgenomen als aparte gemeenten).

Bij het samenvoegen van dit soort bestanden ontstaan altijd problemen doordat gemeentenamen niet consistent worden gespeld of omdat er problemen zijn met de weergave van namen met speciale tekens, zoals S√∫dwest-Frysl√¢n. Open State heeft dit ondervangen door netjes de gemeentecode in het bestand op te nemen. In de CBS-cijfers over kiesgerechtigden is dat helaas niet het geval.

Ik dacht dit op te lossen door elders bij CBS een bestand te downloaden met de gemeentecodes. Maar toen ik de twee CBS-bestanden aan elkaar wilde koppelen bleek dat het CBS zelf geen consistente schrijfwijze hanteert. Kortom, het zou fantastisch zijn als het CBS voortaan standaard in alle datasets met regionale gegevens de bijbehorende regiocodes zou opnemen…

Voor de analyse op wijkniveau heb ik de wijk- en buurtkaart van het CBS (editite 2015) gebruikt. Deze heb ik samen met de Open State-gegevens geopend in Qgis en bepaald hoeveel stemlocaties er zijn per wijk door middel van een points in polygon-analyse.

Hier is de code voor het verwerken van de gegevens.

Update - Het blijkt wel degelijk mogelijk te zijn om gemeentecodes te krijgen bij de CBS-data, als je ze downloadt als SPSS-bestand. Zie ook hier over het inlezen van de gegevens met Python.

Pages