Pittsburgh Removed From Trip Planner

After months of deliberation, we finally decided to go ahead and remove the Pittsburgh region from the trip planner (and, poof, it’s gone). The immediate trigger for the removal was a forwarded email that contained, amongst other things, the following: “Being from Pittsburgh, I chose Pittsburgh. I couldn’t get anything to work.” Ouch.

Here’s the (heavily condensed) story behind the Pittsburgh trip planner. At the end of 2005 we were contacted by someone in Pittsburgh who was interested in integrating the area into the trip planner. She had a plan to get a grant from a local organization to support her work. She eventually got the grant and worked for several months to get the region online.

Unfortunately, for various technical and other reasons, the Pittsburgh version was never quite “up to snuff” (as they say). It was never supported by any Pittsburgh-local organizations, and after the initial integration, the person who did the integration moved to another city and hasn’t worked on it since.

Most of the feedback we have gotten from people in Pittsburgh has been negative–addresses not found, routes on the highway, etc.

We have never had the resources to work on the Pittsburgh version ourselves and have been hoping that a Pittsburgh bike organization (or some individual) would step up to the task, especially given that a proof-of-concept version had been created and, in all likelihood, just needed a bit of ongoing love and attention.

Many times we’ve discussed whether we should remove the Pittsburgh region. On the plus side, we had something that worked and that someone could work from to create something better. On the minus side, it was unsupported, didn’t work well, and was reflecting poorly on us. (Please note that I’m not saying the other regions are perfect, but they are at least nominally supported by local organizations.)

If you or someone you know or some group is interested in working on and supporting the Pittsburgh trip planner, please get in touch.

Using PostGIS with SQLAlchemy

The development version of the Trip Planner uses a Postgres/PostGIS backend (instead of MySQL) SQLAlchemy as the ORM (instead of raw SQL), and PCL for Python geometry types (instead of our own ugly hacked versions).

Question: How do you move geometries out of Postgres/PostGIS into PCL types via SQLAlchemy and vice versa?

Answer: Create a custom geometry column type.

Here’s our SQLAlchemy geometry type definition and subtypes (points, linestrings, and multilinestrings; adding other types should be trivial):

sqltypes.py

Look here for an example of using it:

tables.py

The type is pretty simple. The only tricky part was figuring out how the database stores the geometry. It’s in ASCII hex, so we use binascii.a2b_hex to get a binary representation and feed that to the PCL fromWKB factory. In the other direction we use binascii.b2a_hex on the WKB representation of the PCL geometry.

[8/7/09: Updated links to source code. Note: latest version uses Shapely, not PCL.]

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.

WordPress CMS

Previously, we were using a hacked together “content management system” (CMS) to maintain this site. We had integrated WordPress for blogging, but all the pages were stored in separate files. Keeping things updated was a pain in the ass.

In order to simplify things, we wanted to move the whole site and blog into a unified CMS. We tried Mephisto, and it’s pretty nice, but we didn’t want to be tied to using Ruby on Rails, which Mephisto is built on.

We can run WordPress almost anywhere, easily, and inexpensively. There’s also a ton of info for hacking WordPress on the Web. PHP is pretty weak compared to Python or Ruby, but that doesn’t really matter for this purpose.

The theme for the site is being developed by Wyatt and is available for download via Subversion (you might need to log in with username:password guest:guest):

svn co http://svn.bycycle.org/bycycle.org/wordpress/themes/byCycle/trunk byCycle

We may have introduced some broken links or other problems during this change. If you notice anything, please let us know.

Trevor in Austin

As you may have noticed from a previous post, Trevor is in Austin working with various people to try and get Austin integrated into the bicycle route finder. We met him some time last year (at Vita Cafe on NE Alberta) after he contacted us about the idea of bringing the trip planner with him when he moved back to Austin. He is going to be blogging about the proceedings here, so “stay tuned.”

Personal Sites

In case anyone’s interested (if anyone’s actually reading this), Lauren and I have been working quite a bit on our personal Web sites/blogs, which cover some of our other interests and pursuits outside of byCycle:

In case no one is interested (or reading), uh, well, too bad or whatever. I mean, I just put these links here to boost our page rank anyway. What I really mean is, I put them here in case anyone is interested in more detail about the people who are behind these shenanigans.

Austin By Cycle

The folks at bycycle.org (Wyatt and Lauren) have generously opened up the discussion for an Austin, TX, version of bycycle.org. Austin and Portland ARE sisters, so it only makes sense.

While Austin is not quite as advanced as Portland is when it comes to bicycle infrastructure, it comes pretty darn close, especially considering that it’s in the middle of Texas. There are some subtle similarities and differences between the two bicycle cities :

Portland cyclists primarily ride road bikes. It’s a mountain bike for Austin cyclists. Portland cyclists, in a waterproof bubble, continue to ride diligently through the winter rains. Austin cyclists drink gallons of water to replace the gallons perspired while riding faithfully through the hot summer breeze. Portland is “the most bikeable city in America”. Austin has Lance Armstrong, the greatest cyclist ever to live. In Portland, if you ride a fixed gear bike, you are rad. In Austin, if you ride a fixed gear bike, you are a badass. In Portland, “smart lights” sense a waiting cyclist and changes the light to green. In Austin, cyclists pretend the light is green. Portland and Austin BOTH have bike racks on ALL full size city buses. Portland has an intricate network of wide and continuous bike lanes which could route a cyclist anywhere within city limits safely ( arguably ). Austin has a unique infrastructure of creekside bicycle paths which are entirely separate from the streets and route the cyclists UNDER intersections. Portland has the Spring Water Corridor. Austin WILL have the Lance Armstrong bicycle highway one day eventually. If we are lucky… Austin, like Portland, will have a version of bycycle.org.

The Austin cycling community has expressed enthusiasm about the proposal for an interactive, user friendly, point to point, bicycle map. Let’s not let this opportunity slip past us.

Please feel free to chime in with any thoughts, ideas, or questions.

Bicycle everywhere !

- trevor ( trevor@bycycle.org )

Problems with the Trip Planner in the Last Day or So

Our hosting provider moved all our files to a new server–without letting us know before hand that they were going to do so. Most things kept working. A few did not, as you may have noticed.

The reason some things stopped working is, the new server is running a newer version of the operating system and some of the software the trip planner depends on[1] had to be recompiled [reinstalled from source code].

Though I think the upgrade is a good thing overall, I hope they let us know about it before they do it next time!

[1] The MySQL bindings for Python, in case you really wanted to know. I also updated Python from 2.4.3 to 2.4.4, but I don’t know if that was strictly necessary.

Revenue Report: Google Ads

I’m planning to write a longer post about our financial status, but that might take a while, so I thought I’d go ahead and post our Google Ads revenue, in case anyone’s curious. We first added Google Ads to the site on July 1st, 2006. Here are the figures:

  • July: $41.86
  • August: $53.38
  • September: $64.34
  • October: $82.79

It’s not a lot, but it almost covers our monthly server costs. One is $9.95 per month (for our Web site) and the other is $49.00 per month (for hosting the trip planner application). In the future, assuming more and more people are using the trip planner, that second figure could go up into the hundreds and possibly thousands.

Update

We are working on a partnership with Metro that would eliminate our server costs by hosting the trip planner on their servers. This would be tremendously helpful to the project. In addition to reducing costs, it would also make certain technical issues easier to deal with.

Python Cartographic Library (PCL) — Installing Just the Spatial Package

So let’s say you need a spatial geometry library for Python. You could write your own; you could also use the PCL. The PCL includes some packages we don’t need, like one for MapServer rendering. I only installed the minimum needed to get the spatial package working (which I’ll talk about below).

[Note: "geometry" refers to points, lines, polygons and other geometric forms used to represent real-world objects. Examples: intersection (point), street (line), zip code boundary (polygon).]

I wrote a rudimentary geometry library for the trip planner that’s been working fine, but now I need to do some more “advanced” stuff related to using PostGIS and SQLAlchemy. In particular, I want to convert database values to Python objects and vice versa.

The first part (database to Python) is fairly easy and our current library already does that, but it’s convoluted in that it gets the database value as well-known text (WKT), parses that, and creates a Python object. From what I can tell, the PCL can go straight from well-known binary (WKB) geometry to Python objects.

The second part (Python to database) is harder because it involves converting a Python object to a binary geometry value. I don’t know anything about the binary geometry format and I don’t want to know, and it looks like with the PCL I don’t need to know.

I’m assuming PostGIS and PCL will get along together because they both rely on the same libraries, proj4 and geos. We’ll see.

The installation was fairly straightforward. The PCL includes five sub-packages. We had to install two of them, PCL-Referencing and PCL-Spatial. PCL-Referencing requires proj4. PCL-Spatial requires PCL-Referencing and geos >= 2.2.2. Something in there also requires the OGR library, which is included with GDAL.

The basic steps are, install proj, geos, and gdal, then install PCL-Referencing, and lastly install PCL-Spatial. On Ubuntu 6.06 (Dapper), here’s what I actually did:

  • Installed proj4 using apt-get
  • Installed libgdal using apt-get
  • Installed geos 2.2.3 from source into /usr/lib. I installed this over a slightly older version of geos installed using apt-get; hopefully that won’t cause any issues.
  • Checked out the PCL trunk:
    svn co http://svn.gispython.org/gispy/PCL/trunk PCL
  • Installed PCL-Referencing with the usual python setup.py install
  • Installed PCL-Spatial with the usual…