This Blog Is Not For Reading

 

Last year William and I started a project to add OpenStreetMap links to Thunderbird’s Lightning calendar. We didn’t finish, so that’s one project to work on this year. Also, since last year I’ve been dabbling with the Food Premise Inspection Data to add the restaurant location data to OpenStreetMap. And I hope to be taking lots of pictures and video of the event.

Come join us! Here’s the bumf:

Event: Open Data Day Hackathon
Date: Saturday, 22 February 2014 10:00am to 4:30pm

There’s an Open Data Hackathon in Guelph too, 24 hours long with a contest and prizes and everything!

Event: Open Guelph Hackathon
Start: Saturday, 22 February 2014 at 9:00am
Finish: Sunday, 23 February 2014 at 1:00pm
Location: Atrium, Science Complex, U of Guelph, 50 Stone Road East [Map2]
Website: Open Guelph Hackathon – City of Guelph
Register: Guelph Hackathon Registration, Guelph – Eventbrite
ODD2014: Open Data Day Wiki – Guelph

Be sure to register before Saturday to get in.

 

What I do know is this. Environmental data is not shared with the public. What I do know about Waterloo’s water scares me but perhaps not as much as what I don’t know.

The Region of Waterloo is gradually making its collected data available to the public in Open Data sets. This means that citizens can use and re-use the data for mapping, tracking trends, and correlating it with other data sources. The data is licensed specifically to encourage its re-use, not restrict it.

The Region of Waterloo data sets are available at http://www.regionofwaterloo.ca/en/regionalGovernment/OpenDataHome.asp

There is a citizens’ group called OpenDataWR that encourages governments to make their collected data available in standardized, re-usable formats. They meet occasionally to work on new applications utilizing Open Data resources.

OpenDataWR recently held a hackathon, where groups of people worked on new projects that makes uses of Open Data. It was mostly computer programmers at the hackathon, but we need advocates like Alan with deep knowledge of the data, science, and the meaning of the data so that the programmers can write better applications. We also need publicists to make the existence of Open Data more widely known, as well as the applications that make use of it. We need lobbyists to advocate for more Open Data from governments, and from commercial organizations such as Conestoga Rovers. For instance, the University of Waterloo has an Open Data project as well.

As far as I know, Woolwich Township doesn’t have an Open Data project, or even a policy about making its data available in open formats. For example, even something so fundamental as the Woolwich Council meeting calendar is not made available in a standard calendar format, so you can’t easily add Council meetings to your own iPad or Outlook calendar.

It would be nice to have an Open Data advocacy group in Woolwich Township. There’s certainly enough data, just no good way to get at it.

Call to arms!

If anyone is interested in setting up an Open Data Woolwich Township citizens’ group to encourage and guide the Township into opening its data, please leave a comment below or contact me at bjonkman@sobac.com.

–Bob.

 

OpenDataDay Hackathon at Kwartzlab. Clockwise: Koo (back to camera), Ralph, Michael, Mike, Brett, Jonathan. Missing: Darcy, William, Katherine, Bob.

William and I worked on the Get Map button. Although we had hoped to create some working code, we got only as far as making a mock-up of Lightning’s Edit Event screen:

Lightning “Edit Event” screen, showing the new “Get Map” button

The first hurdle we ran into is that Lightning source code is kept in a Mercurial repository. Although William was familiar with Perforce (another code revision system), I haven’t used Mercurial until now. And the repository contained all of Thunderbird, Firefox, SeaMonkey, and the Mozilla addins. We certainly didn’t want to clone the entire Mozilla code base! So William found the Lightning tarball, which I unpacked in a new folder. This let us poke around the source files to find where our new code should go.

Then we found that Lightning isn’t straight Javascript, it’s mostly XUL. XUL is close enough to XHTML, CSS and DTD files that we could figure out what needed to be done. But we had a limited amount of time, and I didn’t want to spend it waiting for source code to build. So I created a new profile in Thunderbird, installed a fresh copy of the Lightning add-in, and we hacked at the installed files directly. This gave us instant feedback on the changes we made, just by restarting Thunderbird and running Lightning. Some of the changes were in plain text files, but others needed to be made to files in JAR format. One of those was the localized language file. We weren’t sure which language file we were using, en-GB or en-US. Of course, we picked the wrong one to start with, and spend maybe two hours trying to debug a misleading error message about a missing entity definition while we were working on the wrong file.

But it all turned out OK in the end. Now we need to take the work we did on the installed files and replicate it on the source files from the Mercurial repository, properly build Lightning from source, and offer our changes to the Mozilla Calendar project. And, once we’ve got it working, we’ll make the changes available on this site too.

–Bob and William.