Lines as Long as You Like

Today, inspired by a recent donation*, I finally got around to speeding up the display of long route lines (i.e., the line marking a route on the trip planner map). Previously, long route lines would take a long time to show up, and when a line was too long, it just wouldn’t show up at all, possibly crashing the user’s browser. Obviously not good.berryjam.ru

What happened was, I got notification of a donation and saw that the person making the donation lives in Beaverton. I tried getting a route from Beaverton to downtown Portland, but the route never came up because the line was too long. I felt bad that someone had made a donation but might not even be able to get directions over a relatively short distance, so I got to work on fixing the problem.rtisnab.ru

So, skipping over the technical aspects, I’ll just say that now it should be possible to get a route of just about any length. It still takes a while to generate a really long route, but once the route info gets back to the user’s browser, the line drawing is almost instantaneous. Even for short routes there’s a noticeable speedup.

This has been bugging me for a long time, so I’m glad it’s finally fixed. As usual, if you notice any problems, please let us know.

* Big thanks to Rebecca in Beaverton.

Scroll Wheel Zooming Added

A few days ago Google added scroll wheel zooming to their public maps API. Today, I enabled that feature in the trip planner. It was really simple, only requiring the addition of one line of JavaScript code.

This feature has been available on the official Google Maps site for a while, but it wasn’t available to third party developers until three days ago [1].

Another feature Google released recently is the ability to encode long lines for more efficient rendering. For long routes, this means the annoying “this script is taking a long time, do you want to continue popup” shouldn’t come up again.

We haven’t incorporated this into the trip planner yet but will some time in the next week or so (it’s a bit more complicated than adding scroll wheel zooming). I wrote some code that does the line encoding; now I just need to set up the back end to encode lines before sending them to the Web.

[1] Google Maps blog post about scroll wheel zooming

Trip Planner Updates 1/25

We hadn’t touched the online version of the trip planner in months, since we’ve been working on a new (imporoved!) version. In the last week or so, though, I got sick of looking at the old design and decided to make a few changes.

This wasn’t a complete overhaul, as we are focusing our efforts on the upcoming version, but I think it’s quite a bit nicer than before. Overall, it just feels less clunky.

Under the hood, nothing has changed. For example, for the Portland region, we’re still using data from 2004 (with some updates), but that should be changing fairly soon–hopefully within the next month or so.

Please check it out and let us know what you think.

Foray Into Pylons (Python Web Framework)

For a while now I’ve been planning to start using one of the many available Python Web frameworks in the development of the trip planner. Over the course of the project we have built an ad hoc, application-specific, CGI framework (of sorts). Using a “real” framework will allow us to stop refining those wheels we reinvented and instead focus more on the specifics of our application.??? ??????? ??????? ?????? ??????.

Deciding which framework to use has been tough. In the past year or so it seems Web frameworks have become all the rage, with several interesting Python projects and all the Ruby on Rails hype. I had initially narrowed it down to two choices, having researched just about all the competitors: TurboGears and Django. I don’t remember Pylons in that first round of research, but maybe I just missed it. Once I noticed it, it was added to the list too.

So, the idea had been floating around for a while and I had created several test applications with various frameworks but still hadn’t gotten around to making a definite decision and switching over. Recently, I listened to a podcast interview of Guido van Rossum[1]. In it he mentioned that Django is his favorite Web framework. He didn’t say much about why except that he likes the way the project is being run. (“They really get open source.”)

Having heard that and having also narrowed the field to just Pylons versus Django, I decided, “OK, well I’m going to go ahead with Django then.” I ordered up a new Ubuntu VPS[2] to host the new version of the trip planner on and got to work. It was exciting to finally make a decision and move forward.

Getting started was easy and I really liked the admin interface, but about five minutes into it, I realized Django wasn’t going to work for me. There was only one reason: the tightly coupled ORM. Sure, I could just not use that part and use a different ORM, but somehow that seems “impure.” Maybe that seems silly, but remember that I had only decided to use Django on, essentially, a whim.

The reason I don’t want to use the built-in ORM is, I want the Web interface to be orthogonal to the core functionality. I want them completely separate, as they are now in the CGI version. I want to keep database access in the back end and be able to create other interfaces as necessary. Now, I suppose I could just use the Django ORM in the back end (?), but there’s another ORM you may have heard of, SQLAlchemy, that I was/am interested in trying out.

This led me back to Pylons and thinking about some of its good points: it’s WSGI from the start, Routes seems like a really cool way to map URLs, and the (Myghty) templates use Python.

Thinking about it, Pylons seems more like the “natural” choice for this project and its architecture. On the other hand, I think Django would be great for projects that don’t need such separation between the front and back ends (or where there is no back end as such).

I’ve just gotten started with the CGI=>Pylons conversion and so far it’s been a pleasure. I’ll report in more detail once I’ve gotten further into it. One “gotcha” that came up, that I don’t think this is specific to Pylons, was creating a controller with the same name as the top-level package. Don’t do something like this:

paster create –template=pylons tripplanner
paster controller tripplanner

Python will be unable to import the controller.

[1] The creator of Python (which I mention for non-technical readers)
[2] vpslink.com (seems good so far)