Just a quick note to say that I just opensourced the software behind hbus.ca, nicknamed “Routez” under the Affero GPL. You can get the code on github.
For those new to the project, hbus.ca is a generic trip planning / transit information site for Halifax, Nova Scotia written using the Django web framework. It currently has two main features:
- A trip planning front-end much like Google Transit (built from the ground up using the libroutez library).
- A “nearby” routes feature which gives you all the bus departures near a particular location.
On the backend, both of these features are accessible via JSON APIs, for use in transit apps, etc. Transit to Go uses these to great effect.
There is nothing particularly Halifax-specific to the underlying Routez software, aside from various references in the web front end to Halifax and hbus.ca. In fact, we use Routez to provide information for Transit to Go Edmonton right now, with no modification.
Originally my plan was to release something that was completely generic out of the box so that anyone could trivially make up a version of this site for their favourite city. I’ve made some headway towards that goal over the last week or so, but there’s still some ways to go. There’s basically two major issues:
- The geocoder depends on information gleaned from the geobase road network dataset. The intent behind this is noble (provide an end-to-end solution that doesn’t depend on third parties) but in practice this limits the software’s usefulness. It would be better to optionally allow a Routez-based site to use Google’s geocoder on the front-end. Unfortunately, to comply with Google’s terms of service, we’d also need to use their Maps API for the base map as well. Perhaps the best option here would be to use something like Mapstraction to allow users to select their preferred mapping provider.
- The trip planning software used in the backend, libroutez, is getting a bit long in the tooth and is quite finicky about what kind of data it will accept. I think the long-term solution to this is to switch to Graphserver (which is more mature and better supported), but some features would have to be added to it to support the kind of things that Routez needs (like a list of upcoming departures at a particular transit stop).
Even with these problems, I figured it would be better to open up what I have for people to check out and play with. Have a look and let me know what you think!
A few weekends ago, there was a Montréal Ouvert hackfest at the Notman House. I decided to take a bit of a break from my usual transit hacking and built up a mobile friendly interface to the wonderful Déchets Montréal, which lets residents easily get information on their garbage collection schedule.
The interface is intentionally quite simplistic, the idea being that if you’re accessing the site using a mobile device you’re probably only interested in the collection schedule for the current week and nothing else. If you want something more complicated you probably should just be using the full site.
Anyway, another fun opportunity to play with mobile web technology (a bit of break from my current consulting gig, which is mostly native iPhone apps). A few things that I learned this time around:
- It’s easy to give your application a nice icon when added to the iPhone home screen by using a webpage icon.
- Related to the above, you can give the user a nice hint to add your webpage to their homescreen by using Google’s mobile bookmark bubble library.
- The iPhone’s form interface will persist after pressing “Search” unless you change the focus using an anchor element.
- jQuery is the best thing since sliced bread for dynamic web applications (ok, I actually knew this already but I just can’t get over how great it is).
Thanks muchly to Kent Mewhort, the brains behind Déchets Montréal, for helping me incorporate my work into his Drupal-based site.
This weekend my girlfriend’s band (Rice & Barley) did a show at Casa del Popolo. It was great, you should have been there. I made some videos using my trusty new iPhone:
Rae Spoon, the headline act, was awesome. I recorded one of his songs, which he kindly gave permission to post:
Vidya (the other opening band) was good too, though I didn’t get a chance to record them. Next time!
Ok, I’ll be the first to admit that the content on this blog has been rather nerd-heavy, somewhat breaking the promise I made when I first started it to have “approximately the same mix of personal, political and technical content” as my old livejournal. I’ve been meaning to correct that for a while, but as often happens, other things have taken priority.
Well, it’s time to make a stab at it.
I’ve noticed that a good numbers of searches on this blog have been for ginger tea and/or channa masala (chickpea curry). Must have something to do with this blog’s name. Unsurprisingly, these hits tend to have a high bounce rate (people coming to the site and immediately leaving, probably dissatisfied). Well, it’s about time these people get satisfaction with these wonderful, easy to follow recipes:
Channa Masala (recipe courtesy of Mark Côté)
1 medium-sized onion
1 clove garlic
1 2-cm cube ginger
2–3 fresh or dried chilis
1 tsp salt
1/2 tsp turmeric
1 small tomato
2–3 curry leaves
1 540 mL can chick peas
1 tsp garam masala
Saute onion, garlic, and chilis as usual, adding ginger at the same time as the garlic. Place the tomato in boiling water until you are easily able to remove the skin. Add salt, turmeric, tomato, and curry leaves, and cook for another minute. Add chick peas and cover with water. Cook for 15–20 minutes, until water is absorbed and chick peas are tender. Add garam masala, stir, and serve.
Ginger Tea (very informal recipe)
1 hunk of ginger, coarsely chopped (perhaps 4 tablespoons worth)
4 tablespoons honey
3–4 cups water
Put above ingredients into pot, at maximum heat. Bring to boil. Turn heat to low, let cook for 30 minutes or so. Consume. It’s the best medicine for a cold that i know.
Those who’ve known me for a while have probably heard about my first major open source project, libwpd. In a nutshell, it’s a parser for WordPerfect documents with the primary aim of converting them into something usable by the major opensource office programs out there. It’s used by LibreOffice, OpenOffice.org, AbiWord, and KOffice. WordPerfect isn’t the most popular word processor out there, but there’s still quite a number of legacy documents in that format, especially in the legal community (which was almost exclusively using WordPerfect until very recently).
This project goes way back: I started work on it with Marc Maurer way back in 2002 (just after I graduated from University). I put a rather ridiculous amount of unpaid work into it for a few years. WordPerfect’s streaming document format is a bit esoteric to say the least, and figuring out how to map into the document model used by more modern software was a pretty interesting problem. I still remember spending sleepless nights trying to reliably convert WordPerfect’s outlining into structured lists (I mostly succeeded).
Since then, I’ve mostly moved on to other things, leaving the project in the capable hands of Fridrich Strba, who’s been steadily working on adding a number of important features to the library that massively improve import fidelity. I did have time this summer to add page numbering support (thanks to Yam Software for sponsoring that work) and move the project over to git from cvs, but for the most part it’s been his show since late 2004.
Even if I’m not as actively involved as I once was, when there’s major developments, I still get excited (perhaps in the way that a parent might about a child who’s left the household). And yesterday brought something pretty big: libwpd 0.9.0. With this release, we finally supports graphics (thanks to the work of Fridrich and Ariya Hidayat on libwpg), notes, the page numbering that I mentioned above, and support for encrypted documents. It’s a big deal. Here’s some before and after screenshots:
All this goodness should be available transparently whenever you import a WordPerfect file in an upcoming release of LibreOffice. AbiWord and KOffice filters should come soon enough as well (the updates needed to support libwpd 0.9 are fairly minimal).
Integration with OpenOffice.org is another story. Without going into great amount of detail on the situation (see this article on Ars Technica for the gory details if you’re really interested), it’s quite unlikely that OpenOffice.org WordPerfect support will advance unless (1) someone volunteers to do it and (2) Oracle drops their copyright assignment policy. The chances of these things happening seem rather low to me. My personal recommendation would be to switch to LibreOffice as soon as the first production version is released. I expect it to rapidly overtake OpenOffice.org in functionality due to its more open participation model.
Due to some schedule adjustments, it appears as if Metro Transit’s Google Transit is temporarily out of service while they wait for Google to process their new transit feed.
However, fear not! Unlike Google, obsessive compulsive computer programmer William Lachance works on weekends for free (or the low, low price of $1.99 in the case of iPhone applications) so your thirst for updated transit information can be satisfied. I link to these things often enough on this blog, but here they are again, for the benefit of first time viewers:
- Transit to Go In other news, it appears as if Metro Transit has finally seen the light and made their transit information available to anyone who wants it. I would like to think that I might have had something to do with this, but I honestly have no idea. Anyway, if you want to check it out, it’s available here.
After a month long hiatus, I finally had a chance to get hbus.ca back into a working state. The big difference is that we’re now using the official HRM transit data. Lots more remains to be done to make this site competitive for 2010 (most of the recent work has been back-end infrastructure stuff), but at least it’s usable again.
With yesterday’s work out of the way, there weren’t too many extra steps required before I got a basic version of Transit to Go running for Edmonton. There are definitely bugs and rough edges (the bus names could definitely be better described/formatted, and there’s some serious geocoder issues), but I think the heavy lifting is out of the way. I guess now would be a good time to open up an invitations to anyone in Edmonton with an iPhone to become part of our free private beta. We’d love to hear what you think! Just send an email to firstname.lastname@example.org.
A productive day on the transit development front. Finished up a few big features related to hbus.ca and Transit to Go:
- Sped up the graph and database generation by an order of magnitude. Not too exciting from a user perspective, but I should now be able to iterate the codebase much faster.
- Better transit stop / street graph linking: No more does libroutez simply try to find the closest street level vertice to link to when merging transit stops with street information– we now actually create _new_ street level vertices as needed and link to those. Upshot? Slightly better directions and prettier polylines. When I first thought up the algorithm a month ago, I thought I was totally brilliant, only to later find out that Andrew Byrd had done something almost identical a few months earlier for graphserver. Ah well, at least it’s implemented.
- I coded up a script to automatically generate synthetic headsigns for GTFS feeds which don’t have them. This was needed to provide a sensible view for the Edmonton version of Transit to Go. All the props in the world for opening up your data guys, but can’t you do better than saying that all your buses go in the “1” direction? There’s a reason why it’s a required field you know. Not only would it help me, but Google Transit would give better results for your city as well.
Because I don’t have enough spare time projects (this is a joke), I decided to take on the task of adding a must-requested special iPhone/iPod-touch friendly view for the WifiDog authentication server (used by the infamous Île Sans Fil) after being inspired by the WifiDog camp held a few weeks ago at Station C. I finally finally finished up a prototype today. It’s a bit of a hack, but a relatively clean one– hopefully some version of it can be integrated into trunk, and users with mobile devices will have a better experience when they’re on the go in Montréal (or any other area with a community-oriented wifidog deployment: I hear there’s lots).
For those interested in grubby details, you can track the progress of this work on the WifiDog ticket tracker.