The Data Guru in Residence

One of the most intriguing, but intractable datasets I came across at VicRoads was several year’s worth of Hawkeye data. Every two years, VicRoads contracts ARRB to travel the full length of the 22,500 kilometre VicRoads-managed network, recording fine grained detail like surface quality, line marking reflectivity, slope and so on. To assist staff in making sense of the data, photographs are taken approximately every 20: forwards, left, right, backwards, and even down.

In all, it’s several terabytes. I struggled for ages to process it: extracting individual frames from the provided AVIs, attempting to cross-reference a GPS location from the accompanying log files, and then spending far too long learning the intricacies of OpenStack’s Swift storage in order to upload it all to VicNode - a large storage facility for data useful to researchers.

And then I came across Mapillary. It’s a crowd-sourced alternative to Google Streetview, with map images available under a Creative Commons licence. StreetView data is notoriously restrictive in its licensing, while Mapillary is actively working to get their content into Wikipedia and to help improve OpenStreetMap.

Coverage in Victoria was pretty poor - a handful of low volume contributors. Would they be interested in the data?

Yes!

In two days, Yubin and Jan at Mapillary did what I couldn’t: extract the images, align it with the log files and gain access to tens of thousands of geo-located street-level images.

Getting final approval for release from VicRoads took longer. They were (understandably) nervous about possible privacy concerns, and were greatly relieved that Mapillary has face and number plate blurring built in.

The full import into Mapillary’s servers took weeks, but the end result is amazing:

And then Will McIntosh from City of Greater Geelong casually mentioned that they have the same kind of data! Whoosh, another 3.5 million images!

Just awesome to see local roads around Geelong and the Bellarine Peninsula linking perfectly with the VicRoads arterial road network...and even a few sections of Bellarine Rail Trail I contributed with a bike-mounted camera, plus some walking trails around Barwon Heads.

The end result: a beautiful example of valuable government data made accessible and more useful through the right technology partnership at the right time. If any other government bodies have similar data, Mapillary would love to make it available in the same way.

(But you’ll need a PTV API key)

1. Using the Public Transport Victoria API through the OKFNAU Swagger interface, query all ticket outlets.

2. Convert the output JSON to CSV using this tacky JSON-CSV converter

3. Download the result to a .csv file

4. Drag and drop it to nationalmap.nicta.com.au

I’ve been building http://opentrees.org, combining tree inventory data from 8 councils and the Waite Arboretum. You can read all about it here: “OpenTrees.org: How to aggregate 373,000 trees from 9 data sources.”

Here are some quick stats taken across the whole database.

Most popular genus:

Eucalyptus (47464) Callistemon (20998) Melaleuca (16426) Corymbia (14844) Ulmus (12076) Acacia (11252) Lophostemon (10616) Prunus (9688) Platanus (9093) Pyrus (7047) Quercus (6308) Fraxinus (5964) Allocasuarina (4675)

Most popular species

Lophostemon confertus (10614) Eucalyptus camaldulensis (9907) Eucalyptus leucoxylon (9422) Callistemon citrinus (7412) Platanus x acerifolia (7287) Corymbia ficifolia (6655) Prunus cerasifera (6050) Callistemon  (5593) Corymbia maculata (5387) Eucalyptus melliodora (4688) Melaleuca styphelioides (4213)

Most popular hybrids and cultivars

Platanus x acerifolia (7287) Ulmus x hollandica (745) Ulmus x holl. purpurescens (179) Prunus x blireana (131) Ulmus x hollandica vegeta (122) Populus x canadensis aurea (107) Acer x freemanii (72)

Most popular species by council

adelaide: Platanus x acerifolia ballarat: Quercus robur colac_otways: Lophostemon confertus corangamite: Ulmus procera geelong: Callistemon citrinus manningham: Prunus cerasifera melbourne: Eucalyptus camaldulensis waite arboretum: Ulmus procera

Number of distinct species by council

waite arboretum (860) manningham (537) melbourne (374) corangamite (371) geelong (277) colac_otways (138) ballarat (138) adelaide (67)

Average number of trees per species, by council

(”5″ means there are five times more trees than the number of species present, so each species is represented on average five times.)

Open data is exciting, and real-time open data is even exciting-er. But it's tricky: every step in the data gathering chain needs to be designed to support real-time publishing, or else the data goes rapidly stale. I've just finishing implementing a pilot project, publishing real-time open data for the City of Melbourne.

Collect the data A team of researchers led by Dr Jayavardhana Lakshminarasimha from the University of Melbourne School of Electrical and Electronic Engineering have installed around 10 Meshlium automated environment sensors, in Fitzroy Gardens and at the Docklands Library. These produce data every 30 seconds.

Locations of the environmental sensors, at the Docklands Library and in Fitzroy Gardens.

Store the data The team created a MySQL database on the NeCTAR Research Cloud, and wrote scripts to constantly write data into it. The next bit was up to me.

Aggregate the data Publishing data at such frequent intervals could hit Socrata's usage limits, and isn't useful for the average end user. So we aggregate first:

SELECT date_sub(timestamp,interval (minute(timestamp) %% %d ) * 60 + second(timestamp) second) AS timestamp_agg, convert(avg(convert(temperature, decimal(5,1))),decimal(5,1)) AS temp_avg, ..... FROM sensorReadings sr INNER JOIN sensor_info si on si.boardid = sr.boardid WHERE temperature <> '' GROUP BY sr.boardid, date_sub(timestamp,interval (minute(timestamp) %% %d) * 60 + second(timestamp) second) HAVING timestamp_agg > '%s' ORDER BY timestamp LIMIT %d''' % (interval_mins, interval_mins, latest_published, rowlimit)

Publish the data Publishing to Socrata is pretty easy using the SODA API. My script (available on Github) is in Python. There's no special Python API, but then you don't really need one, as it's a pretty conventional REST interface.

headers = { 'X-App-Token': config.app_token, 'Content-Type': 'application/json' } auth = ('[REDACTED USERNAME]', '[REDACTED PASSWORD]') r = requests.post(config.dataset, data=simplejson.dumps(rows), headers = headers, auth=auth) j = r.json() if r.status_code != 200: raise RuntimeError ( "%d Socrata error: %s" % (r.status_code, j['message']))

Repeat automatically

To make this happen automatically, we simply add the Python script to Cron, Linux's background task scheduler.

*/10 * * * * cd /home/ubuntu/sodasensor && ./publish.py --rows 100 >> publish.log

The final result The dataset in data.melbourne.gov.au has these fields: timestamp: the time of the start of the aggregated period

mac: MAC address of the sensor

boardtype: always 1 for environmental sensors, I think

boardid: ID of the sensor itself

temp_max/min/avg: temperature

light_max/min/avg: ambient light level

humidity_max/min/avg: humidity

model: ENV for environmental sensors

latitude/longitude: location, hard coded

elevation: height above ground, hard coded I believe

location: text description of where the sensor is

rowid: unique identifier, comprised of time and board ID.

See the data now: "Trial environmental sensor readings".

Ever seen VicTraffic? It's an interactive map showing roadworks, public events, traffic alerts, natural disasters and other events causing disruption on roads across the state. In addition to this site, VicRoads provides the data to a number of data consumers on a commercial basis, with individual agreements and SLA's. For some consumers, like ESTA (who manage 000 calls), correct, up-to-date information is critical for safe routing of ambulances and other emergency services. For others, like Australia Post, it's a matter of efficient service delivery.

It's easy to see why this data would be useful to an even wider range of consumers: that is, why it should be open data. But let's look at the complexities.

This data comes from several sources, combined:

Planned roadworks

Planned events (such as marathons)

Traffic alerts (some of which are triggered by smart freeway sensors)

Unplanned road closures (eg, due to an accident, landslide or a bushfire)

Unplanned road closures provided by local councils. (For reasons I don't quite understand, councils have to notify VicRoads of unplanned road closures, but not planned ones.)

VicRoads doesn't develop or host many software applications, and VicTraffic is no exception: it's developed and hosted by WaveDigital. The VicTraffic application requests data, in the form of an XML SOAP feed, every couple of minutes, from VicRoads servers, over a secure, IP-controlled link.

So, how can VicRoads release their data in realtime to the world?

Option 1: Remove the IP whitelisting, and publish the URL of their data feed

This is the simplest option, but completely reckless. Their servers are not built to be accessible to the public, and could easily be crippled during an emergency. Lives could easily be at stake.

Option 2: WaveDigital should provide a machine-readable feed of the data

Two problems: first, obviously this would cost money for the change, which could be significant. Secondly, this now makes WaveDigital's servers the single point of failure, and the gateway to a potentially much larger ecosystem than they reckoned on. If the servers became swamped by non-critical needs during an emergency, then critical needs could also be compromised. Clever architecting would perhaps be required.

Option 3: Publish a parallel feed to another location

Perhaps a better solution is to also provide an IP-controlled feed to another server designed to provide just this static content to large numbers of clients. The biggest risk in this solution is that applications could come to depend on this new endpoint, when there is in fact no SLA between VicRoads and the application or its consumers.

Over the last few months, I've had meetings with a few state government bodies that are just starting their open data journeys: EPA, VicHealth, Sustainability Victoria, Transport Safety Victoria. These first steps seem to recur:

1. Make a list of datasets available in the organisation.

Often this already exists, called an Information Asset Register, or Data Inventory. The usual driver for these is security: making sure that important information is both protected from loss, and from inappropriate sharing.

2. Add new fields

Ask these questions:

a) Published: Has this information been published before? If data has already been included in a report, then it's easier to publish as data.

b) Confidential: Is there anything confidential in this data? Individuals' names, addresses, etc. Political sensitivities get recorded here, too. There's no need to go near any confidential or sensitive datasets to begin with.

c) Processing required: What would need to happen to turn this dataset into something that could be uploaded to DataVic? Maybe it already exists as a spreadsheet, maybe it needs to be exported from a database, maybe some complex aggregation and de-identification would be required.

d) Sign-off: Who would need to sign off on this dataset being released?

e) Useful for: What reasons would this data be valuable for? App development? Research? It's hard to predict every use, but a quick brainstorm helps discussion.

Other, organisation-specific fields get added. For EPA, we added fields like how often a dataset is collected, how many data attributes, and so on.

3. Prioritise

Once the spreadsheet is more or less complete, you can start assigning priorities. You balance:

Value: "Useful for" column and previous demand.

Ease of publishing: "Processing required"

Sensitivity: "Confidential" and "sign-off" columns.

The first couple of datasets should be low-sensitivity, easy to publish, and preferably at least moderately usfeul.

4. Publish, gather feedback and repeat!

I've created a draft set of standards for some common council datasets: trees and garbage collection zones so far, with more to come. Update: Building accessibility ratings added!

The primary goal: to allow datasets from different councils to be easily joined up into something bigger, to support research, app development, knowledge exchange between councils, and use by the public.

Your feedback is needed!

At the Municipal Association of Victoria's technical forum in Healesville on the 5th of December, we proposed 4 datasets for councils to focus on publishing. Already, Ballarat has released their garbage collection data at data.gov.au:

And here's what the current state of trees datasets looks like:

Open Data Hackfests and Health (for Department of Health, March 21, 2014)

Rethinking the Smart CIty with better open data (for Melbourne Knowledge Week, 30 October, 2014)

The Open Road (for ~20 staff at VicRoads, 25 November 2014)

Open Data for Corangamite (for directors and CEO of Corangamite Shire Council, 2 December 2014)

Open data together (for ~30 council IT staff at MAV technical forum, 5 December 2014)

Government bodies are big fans of the pretty spreadsheet:

It's no good for any kind of data work like that, however. Here's what you do.

1. Strip the formatting, remove header fluff and blank columns.

2. Create cell formulas to construct one row from all the cells around it.

3. Add an IF expression so that cells only get populated once per block of text. Here I check whether the "Tel:" cell contains exactly that text. If it doesn't, remain blank.

4. Fill down.

5. Copy all the new cells, and paste-special so that they contain values, not formulas.

6. Remove the old columns.

7. Remove all the interleaved blank rows with the magic touch: sort!

Voilà. Now we have something we can work with.

The states' government data portals contain all kinds of data goodies that are pretty useful, if you know it's there and how to get it. Here's one: the Department of Enivornment Primary Industries' "Vicmap Vegetation 1:25,000" dataset.

What is it? A detailed geospatial data file showing areas that have trees, across the whole state.

Why is it useful for me? I run http://cycletour.org, a map-based planning tool for cycle tours. It's nice to know which areas are forested, as they're often nicer than farmland, and better for stealth camping.

Searching for "trees" on http://data.vic.gov.au turns up lots of stuff, like this:

There's a lot of technical knowledge assumed here. See the text in blue?

WMS: This actually isn't a data file you can download. It actually means the first two "datasets" are just locations of a Web Map Service - an older way of serving map tiles over the web. So it's a URL that you could give to a GIS program to change your basemap, but you're stuck with however DEPI chose to render this vegetation layer. And you can't do any actual analysis with the data - it's just a set of images.

SHP: This is a downloadable Shapefile, a very widely supported proprietary geospatial format.

And the 1:25,000? Government departments still seem to be dominated by the idea of printing maps, where scales are expressed as ratios. A dataset described as 1:25,000 means that the data is precise enough to be printed on a map at that scale. In this case, that's good enough for a pretty detailed hiking map, for instance. (The datasets also include more detailed statements like "For topographic base derived data this represents an error of 8.3m on the ground for 1:25,000 data")

Ok, let's download it.

Not so fast.

Data.vic.gov.au doesn't actually contain downloadable geospatial files from DEPI. Instead, after entering your email address, you get redirected to the Spatial Datamart, a somewhat clunky geospatial data portal. Here's what you have to do to get all the data for Victoria:

1.Choose area type "Whole of State"

2.Click "VIC", then ">". (So now it knows which whole of state...)

3. Click Apply and Submit.

You could choose a different projection, but since it doesn't offer anything useful, like, oh, the world's most popular web mapping projection, Spherical Mercator (EPSG 3857), there's not much point.

 4. Sit back and wait. You'll get an email in an hour or so, letting you download the file. This one's about 1.5GB.

Then, you can do what you want with it. In my case, styling the data with TileMill, and adding a new vegetation layer to cycletour.org:

How do you get researchers and government talking to each other? Maybe you stick them in a workshop together. Last week, I ran Visualise the City, a one day workshop to learn Tableau, a pretty awesome visualisation and data analysis tool. I opened the event to researchers at the University of Melbourne, staff at the City of Melbourne, and a small number of "public" - mostly GIS people interested in open data.

The first few hours were almost a standard Tableau workshop, run by Tableau sales consultant Cynthia Halim. Almost - instead of the dry and off-topic sales data normally used for corporate audiences, we substituted in the City of Melbourne's excellent Urban Forest dataset. This rich dataset of 70,000 trees with species, diameters, year of planting and estimated life expectancy quickly piqued participants' interest.

Lunch at nearby Thai restaurant Middlefish was excellent and got everyone talking. Vigorous debates over statewide infrastructure policy at one end of the table were balanced by technical questions on Tableau's capabilities at the other.

Then, the group challenge in teams of three: a researcher, a City of Melbourne staff member, and an "other". In one hour, each team had to:

find an open dataset, on data.melbourne.gov.au or elsewhere;

ask a question of the data; and

answer the question with a Tableau dashboard

They did great. We had questions like "when will we get relief from the London Plane?", a novel use of the Urban Forest dataset from an allergy-sufferer. Or how about "is manufacturing shrinking in Melbourne", looking at the change in floor space usage reported in the Census of Land Use and Employment.

What does a well organised open data movement look like at city council level? Perhaps like this: http://us-city.census.okfn.org/

&amp;amp;amp;amp;lt;p&amp;amp;amp;amp;gt;aoeu&amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;gt;

This impressive chart is the combined work of Code for America (citizens working on technology problems with government), the Open Knowledge Foundation (promoting openness), and the Sunlight Foundation (promoting transparency). They identified 18 kinds of data that every US city is likely to collect.

They then assess whether each city publishes this data as open data, using 9 separate criteria: data exists; is digital; is publicly available; is free of charge; is online; is machine readable; is available in bulk; is openly licensed; and is up to date.

So an annual budget published once every year as a PDF would probably score 7 or 8 points, lacking machine readability and perhaps open licensing.

Global Census

Similarly, there is a Global Census, measuring open data availability for different countries. The Global Open Data Index Survey, ranks us 10th, somewhat improbably ahead of Germany:

(The choice of categories here is a bit odd. "Public transport timetables" don't always make a lot of sense at national level, being predominantly state or municipal in many cases. The requirement for a 1:250,000 scale "national map" is just plain weird in the era of OpenStreetMap)

Open Data City Census for Australia

As local governments around Australia begin their open data journey, the time has probably come for an “Australian city open data census”. It would both chart and guide their progress. The US list is a good starting point but some categories don’t apply well here:

Crime stats are probably collected at state level, not city.

City elections are less important here, so are campaign donations so important?

Public transport may be managed at a state rather than city level.

I had already started working on something similar with MAV, the Municipal Association of Victoria: a list of “High Priority Local Government Datasets" that most councils in Victoria could provide. The ultimate goal of that list is somewhat different however: joining up data from the geographically small councils into bigger, more useful datasets. And it focuses on “usefulness” rather than transparency.

Now, local versions of the Open Data Census have already been created for more than 25 different countries: the UK  France  even Burkina Faso and Bangladesh.

But there's still no Australian City Census. So, let's get on it.

One of the two main data feeds we had to fake in our Living, Breathing Melbourne project for Govhack is actually available! Melbourne Bike Share provides an API, meaning you can get a sort-of live feed of the number of bikes in each station around the city.

http://www.melbournebikeshare.com.au/stationmap/data

It returns a big piece of JSON like this:

[ { "id": "2", "name": "Docklands Drive - Docklands", "terminalName": "60000", "lastCommWithServer": "1410748124274", "lat": "-37.814022", "long": "144.939521", "installed": "true", "locked": "false", "installDate": "1313724600000", "removalDate": { }, "temporary": "false", "public": "true", "nbBikes": "6", "nbEmptyDocks": "17", "latestUpdateTime": "1410746433507" },...

Amongst much fairly uninteresting metadata, the useful data is:

lat,long: location

nbBikes, nbEmptyDocks: number of bikes and empty spaces (and combined, total capacity)

name: a human-readable location

Somewhat disappointingly, the feed itself only seems to update about every 10 minutes (it varies). However, the aggregating server seems to communicate with individual stations more frequently than that - based on my reading of the latestUpdateTime field.

So, what to do with it? How about this zen-like visualisation, which shows both the current number of bikes available in each station, and the occasional drop-off and pick-up.

View the visualization

You'll have to watch it for a while because of the 10 minute update frequency. However, I try to fill in the gaps, by spacing out all changes over the next minute or two. To get a sense of what it would look like with many times more activity:

View the visualization with fake data

The visualisation uses:

A basemap made in TileMill, based on the OSM Bright style, incorporating the City of Melbourne's Urban Forest.

Javascript calls to the BikeShare JSON feed. In the end, I didn't use the excellent PyBikes library.

As a data guru in residence, I'm helping government bodies prioritise which datasets to release as open data. Sometimes people say "No one would ever find this data interesting, so why bother releasing it?" I think there are several distinct reasons why a given dataset might be worth releasing. Some datasets are valuable for several reasons simultaneously. Some aren't valuable at all.

When a public servant comments that a potential dataset isn't interesting or useful, ask: "are there other reasons to release it"?

But if a dataset fails to meet any of these criteria? You have my permission not to release it. :)

#1 Build an app around it

Census Explorer, by Yuri Feldman, allows easy exploration of part of the 2011 Australian Census.

Datasets like public transport timetables, public bike share station status, or parking space availability are obvious candidates for third party developers to use to build an app. Unfortunately, these examples also require near-realtime feeds in order to be useful.

#2 Support other apps

Even if a dataset isn't interesting or useful enough to warrant an app in its own right, it could add value to another website or app if it's easy to use. I've come across many of these:

Average traffic volume on roads maintained by VicRoads, used to help cyclists decide which roads to avoid, on cycletour.org.

The slope of footpaths around Melbourne can help wheelchair users navigate the city.

The location and species of every tree in Melbourne can add colour and interest to a map of the city.

Locations of drinking fountains could be useful for cycling, jogging, or dog walking apps or websites.

Which way would you cycle to Port Albert?

#3 Interesting for research

If a dataset is big, rich, detailed and high quality, then there's a pretty good chance it's worth of some kind of analysis. If it's unique enough, then it might even interest a researcher in starting a research project just to look at this dataset.

Examples: building permits database, public transport timetables (for urban planning).

#4 Supporting other research

Much more common than such a rich dataset is small datasets that researchers find useful to solve particular problems, add context, or strengthen an analysis. Local Government Area boundaries aren't inherently interesting, but they're one of the geospatial datasets that researchers request the most often. The ATO's Standard Business Rules taxonomy sounds incredibly dry to me, but is of potential use to lots of people trying to glue different kinds of data and applications together.

#5 Policy and analysis

Lots of organisations need government data to develop internal strategies or policies to be shared with the public - or even to influence government. Typically they get the data either by transcribing tables from official reports, or by developing direct relationships with the government body in question. Publishing data directly to an open data portal allows a wider range of groups to make use of it, without the overhead of having to ask whether the data is available. Data that is collected regularly, in the same format is a particularly likely to be useful.

#6 Transparency

If the data relates to how government decisions are made, it may be worth releasing to demonstrate transparency - regardless of how much the dataset is even used. For example, releasing annual budget data as an easy to use spreadsheet makes a big political statement about willingness to be scrutinised. Even if no citizen takes up the opportunity to crunch the numbers, they may still appreciate having that option.

Examples: annual budgets, revenue sources (parking meters, speeding fines), parliamentary voting records.

#7 Insights for government

On Tuesday, I met with Paul Corkill and Ricky Dong from Transport Safety Victoria, which provided the Waterway Zones dataset for Govhack. At that event, I used it to whip up this quick website, CanIBoatHere.com:

Meetings about opening government data don't often get written up publicly, so I thought I'd recap.

The department's plans in releasing the dataset are to provide more effective access to the current regulations around where boats can be used. They're currently defined in legislation and the "Guide to Vessel Operating and Zoning Rules", known as VOZR. TSV would love to see web and mobile apps using this data, but is prevented under current expenditure rules from directly commissioning a mobile app.

The actual data currently provided doesn't quite do all this though. It's derived from audits carried out over the last few years, which sought to verify that signage still existed where expected, locations of buoys etc.

In addition, the dataset doesn't currently cover "unscheduled waterways" - department-speak for rivers and lakes that don't have any specific rules, and are covered by the general regulations, such as a 5-knot speed limit within 50m of shore.

Even harder, the regulations include rules like "when Lake Glenmaggie is below 44% but above 25% capacity, then certain rules apply". Without good shoreline and waterlevel data, it's hard to accurately answer the question "can I boat here?"

The upshot:

They're working on a better quality dataset to release. (Governments hate publicly mentioning timeframes, so let's leave it at that)

They're taking into account comments about the format of the previous release (MapInfo with lots of subdirectories, no documentation, dozens of attributes)

They also have potentially other interesting data to release:

Hundreds of boating incidents such as capsizings, collisions, man overboard, etc, going back years.

Licensing data - there are something like 300,000 licensed boat operators in Victoria. (It goes without saying that confidential data would never be released.)

Boat registration data - lots of detailed information about all the individual boats that are registered for use. (Not sure how confidential this is.)

City of Melbourne's data portal has this nice dataset of building footprints: a rough 2D outline of the shape of the building at ground level. But what's cool is the height in metres of (almost) every building in is included.

Let's grab the shapefile.

wget https://data.melbourne.vic.gov.au/api/geospatial/qe9w-cym8?method=export&format=Shapefile

A quick preview in TileMill shows a small problem:

See the overlapping parts of Etihad Stadium? We need to draw the buildings from north to south. I load the shapefile into PostGIS:

ogr2ogr -t_srs EPSG:3857 -overwrite -f "PostgreSQL" PG:"dbname=gis user=ubuntu password=..." -nlt MULTIPOLYGON BuildingFootprints.shp

For good measure, here's an alternative way:

shp2pgsql BuildingFootprints.shp | sudo -u mapbox tee footprints.sql psql -d gis < footprints.sql

Now, a bit of fancy styling, and some more data from OpenStreetMap, and voila.

The full CartoCSS code for TileMill is here:

One of the datasets promoted for #infrahack is VicRoads' "Speed Zones Data", available at data.vic.gov.au. It's awesome. Completely comprehensive (every public road in the state, as far as I can see), simple to work with, and in a popular data format (ESRI shapefile).

There are 9 fields, some of which are self-explanatory. 

VicRoads, it would be nice if you could include descriptions of these fields in your dataset description. What do they mean exactly? My guesses:

SIGN_SPEED: limit in kph, obvious.

DIRECTION: presumably, whether the limit applies in only one direction?

Def_Zone: ?

Variable: whether the limit changes at different times of day, like school zones?

Var_Code: ?

Seasonal: Whether the limit changes in winter? Or whether the road is closed altogether, like the Dargo High Plains Rd?

Seasonal_F: ?

Seasonal_T: ?

Currency: A non-standard date format representing how recently the data was updated.

I've done a simple visualisation in TileMill of the speed zones in this dataset.