Last week, I released byCycle under the GNU Public License, version 3. Check it out at on the project Web site. Note that trunk is currently broken-ish. The rb-0.4 branch is the current live version.
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.
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.
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.
Last week we launched a new version of the trip planner. On the surface, it doesn’t look much different from the previous version, but “under the hood”* it has changed significantly. Moving forward, it should be easier for us to add new features and fix any issues that come up (and issues are sure to come up, as you may have noticed already).
We’d love to hear your feedback on any aspect of the trip planner–what features we should add, what doesn’t work for you, etc. Please keep in mind though that the trip planner is a complicated beast and we have very limited resources with which to make improvements.
That brings me to the next topic, which is byCycle’s financial status. Since the start of the year, we have only generated $151.60 in revenue. At this rate, byCycle is not going to be “in business” much longer. We are looking into ways to remedy this situation. In the meantime, we could sure use some community support. Please consider making a donation or buying something from our online store.
In the next edition (coming soon), I’m going to write about the latest developments in our relationship with Metro**–stay tuned!
–Wyatt
* Ironic, I know. I would like to say “under the [part of the bike that contains all the complicated and mysterious machinery]” but most everything on a bike is out in the open or available for relatively easy inspection.
** Metro is the Portland area’s regional government.
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.
I found this movie clip on the BTA’s blog. The Bikini Bandits are “a specially trained team of enthusiastic young women” who encourage Danish motorists to slow down to the speed limit.
(The bandits seem to have lost their bikini tops. Be forwarned, if you follow the link, you might be subject to some partial nudity. Good heavens.)
I wonder if a campaign of this nature would encourage Portland motorists to be just a tad more patient and cautious around bikers, pedestrians, dogs, and all other things on the road that aren’t encased in metal and weigh over 500 lbs?
Lauren
We’ve been batting around the idea of becoming a non profit for almost a year, and have recently set a goal to decide once and for all.
We aren’t interested in making a profit with the trip planner, but would like to some how gather enough money to cover costs and perhaps pay the people that work on it. Being a non profit will give us access to much needed funds, but we are concerned that it will limit the types of things we are able to do with our software.
Some of our concerns are:
- what will happen to the soft ware if we do become a non-profit and later dissolve?
- what kinds of limitations will it place upon us?
- are we even eligible to attain non profit status?
Should byCycle become a non profit? Let us know by making a comment below.
I just got done installing Python 2.5 and converting the trip planner code to use it instead of 2.4. The only required change was pointing the “dispatch” file at the 2.5 executable. No other changes to the code were required to make it run on 2.5.
A few little things also got cleaned up, and I updated to the latest versions of MySQLdb (1.2.2b3) and simplejson (1.5).
Hopefully nothing will blow up.
byCycle now has a store! All proceeds go to support byCycle’s projects.
We went with a CafePress store because of it’s simplicity. It was easy to set up, and allows us to create and sell things on demand. It also makes it easier for you to buy things.
Everything is priced at five dollars over what CafePress charges us.
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.
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):
Look here for an example of using it:
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.