Really glad you like it! I should confess Prawn isn’t mine – there’s just an old fork sitting in my github repo. But the website side of cycle.travel is indeed all written in Ruby – my favourite programming language by a country mile. The route-planning is of course OSRM. (My major open-source project these days is tilemaker, which generates the vector maps for the c.t apps.)

I’m very interested by the bike bus concept, not least as Junior and his cousin ride across a busy city every day to get to their school. In particular I’ve been wondering whether there’s potential for a spontaneous bike bus app. In other words, rather than the bus being solely pre-defined routes at pre-defined times, an app could allow people to come together to form a bike bus from scratch. By users registering their intent like “I’m going to be riding from A to B at 8am on weekdays”, the app could coordinate them meeting at particular points and riding together. (I did put a bid in for some funding the other year to explore the idea but wasn’t successful, sadly.)

For that sort of project, I’d be very keen to help with a routing API or whatever. I wouldn’t categorically rule out working with an alternate c.t client but I think it’d be a harder call – partly maintaining the full API stability/documentation would be a big task in itself, and partly I’m not sure how it could work financially. c.t doesn’t yet pay for itself but it’s getting there and I’d love to be able to work on it (near) full-time.

But that said I’m very keen to make c.t work better in North America. It’s a good point about the location search – that’s based on OpenStreetMap data, which works well in Europe where there’s an active OSM community and (put simply) residential roads are shorter. So even if the house numbers haven’t been mapped on the road you’re starting from, it’s not a big deal to start somewhere else on the road. In the US, the OSM community is smaller and housenumbers regularly run into four figures, making it more important to start/finish at the right bit of the road. I could potentially look at integrating another geocoder for the US – perhaps the Apple Maps one, which I use in the iPhone app.

Absolutely do feel free to dump any suggestions here for how c.t could work better in North America – I’d love to hear them. (Having visited Portland for an OSM conference about 10 years ago I have ambitions to return one day…)

On the customisation angle: in theory c.t can ingest additional data to influence its routing weightings pretty easily. As ever the challenge is that no two people ever have the same opinion as to what’s a bikeable street (one of the reasons I’ve shied away from popularity-type weighting). But having some local knowledge could really help. Do you have any thoughts about how that sort of data might be organised?

Just seeing this now- thanks for the extensive response!

> In particular I’ve been wondering whether there’s potential for a spontaneous bike bus app

Oh, that's an interesting idea! I will toss it around, see what others think. I am a bit leery of anything that depends too much on network effects for its utility. If it's focused on existing communities, like schools, and we give people a way to 'import' their address and intent, that could work, potentially. But this is a cool idea- I need some time to digest and consider it.

> partly maintaining the full API stability/documentation would be a big task in itself

True- I think though it's okay to acknowledge a high "truck factor", where most of the knowledge the additional client has comes from source or spec diffs, not published documentation, changelogs, and backwards compat commitments. It'd be some extra coordination, but probably not to a substantially different degree than you have to deal with already.

> partly I’m not sure how it could work financially

I wouldn't have a financial interest in this. I'd be fine to point any user funding your way, or even just develop this as cycle.travel IP (though we would need to figure out something with copyright if the work is not paid for, etc), but the main point is, I think it would potentially help c.t financially.

> But that said I’m very keen to make c.t work better in North America.

Interesting about street length, that's something I hadn't even considered. I will say though that I have never had an issue with geocoding with OSM- the homes that aren't in OSM yet tend to be newer subdivisions which are unlikely to be cycling, and aren't part of cycle routes (this suburban development pattern still predominates here...). This seemed more like a UX thing- for example, I believe that with something like Google Places autocomplete, you can bias the search to the current location. When I search for 'Cathedral' while in PDX, I want 'Cathedral Coffee' or 'Cathedral Park', not Cathedrals in France :) That said, the route it chose was excellent :)

It's hard to use c.t with this behavior, since I generally need to find the address myself, then copy it into c.t. Once I can use c.t more I would have additional US-specific feedback.

> Do you have any thoughts about how that sort of data might be organised?

You are spot on here. It's actually a consistent source of disagreement in our mapping group even just in PDX. Some people want to keep people on our 'greenways' (theoretically low-stress, low-traffic streets), but some greenways are much worse in terms of elevation/paving/crossings/distance than local alternatives, for some trips. If I have kids with me, I will choose one route (no major streets, even if they have bike lanes). If I'm on an e-bike, I'll choose another (short distances on certain 'collectors' with no bike facilities are ok). If I'm on an acoustic bike, I would choose a third (avoid any collector without a bike facility).

I was actually thinking of organizing the additional layer of weights based on 'personas.' In Portland we have a concept of 'categories of cyclists': 'strong and fearless', 'enthused and confident,' 'interested but concerned.' And then I think level of ability, like 'still getting comfortable' (most elementary kids), 'capable' (adults and older kids), and 'fast' (can sustain speeds of 15-20mph, usually due to e-assist). So I was thinking that, with some additional weighting, we could choose better routes for the type of trip people are looking for. I've seen things that try to prioritize certain features, like elevation, or safety, etc., but I think in most choices it's much closer to a binary decision given a particular type of rider, than a continuous weighting about 'safety' vs. 'elevation gain'. I even thought of publishing these routes as separate maps, akin to our greenway maps.

Here is an example of different examples for a short trip: https://felt.com/map/different-rider-examples-B5jv3ix8RRqbIbAMsPW7PB

The red route is the 'suggested' route but it's pretty terrible- it sends you across a stressful crossing at 30th, at the top of a hill, then right back down, to another somewhat stressful crossing (one of those overengineered marked crosswalks), then back up a hill on 30th, then back down.

There is a flatter, low-stress route, in blue. It avoids both significant hills, and has the same number of unsignalized crossings, with better visibility IMO.

Then there is a route that is significantly faster, and lower stress, but requires a bit faster speed. There are no significant unsignalized crossings, but you do ride for about 100m on a street with no facilities (and then up and down a hill, but it avoids one harder hill).

I wonder if it would work to categorize each of these pieces ('flatter local alternative', 'high-value but fast-rider-only connector'), and then weigh them against the 'profiles' above.

This wouldn't solve the problem- as you say, no two people have the same opinion- but I think we could weigh decisions against persons and get broader agreement.

What would you say next steps are? (I'm going to think about the idea you suggested too)