Computing the optimal stop placement for transit

Like many people, I take the bus to work most days. My commute isn’t actually that far (about 3 miles), but I am incredibly lazy, and the bus lets me catch up on the magazines that would otherwise be accumulating dust on my table. (And if I keep up on my Harper’s, I can at least pretend I’m up to date on what’s going on).

Anyway, here’s my bus route:

bus route

The main thing to notice here is that it stops an awful lot.  During peak commute hours, I can sometimes walk faster than the bus.  Given that I’m out of shape and my commute involves a big hill, that’s not a good sign.

It’s been pointed out many times that perhaps stops are placed too close together in many locales:

So there are potentially good reasons why you want to have stops closer together than what might be optimal; though I would mostly bucket these into having a customer base that is old, fat, lazy, grumpy or some combination of those 4.  You can see in the humantransit post the outrage expressed at having stops more than 300 meters apart.  The horror of having to walk more than 1.5 blocks to your stop!

But let’s go ahead and assume we live in a world where people are happy to walk longer distances.  Let’s go further and assume they’re willing to walk as far as they need to ensure their overall trip time is minimized.  If we have such a cooperative public, then what’s our optimal stop distance?  I made up a trivial model of what happens in this case in a Ipython notebook here:

Here’s the resulting plot:

This model is incredibly contrived, but still, it’s interesting to toy with the tradeoffs.  Note that even with a very slow walking pace (2 minutes/block, or 50 meters a minute), the optimal distance is over 5 blocks apart.  (Compare that with the spacing on my route at a ~2 blocks between stops.)
If you have ideas on how to improve the model, please let me know!


We use Slack extensively at Iodine. It’s where most of our communication takes place, even within the same office! (You can argue that this isn’t especially healthy…)

Sadly, we’re still forced to use email to interact with some services that haven’t added a hook for Slack. These include some monitoring services, or just when we want a “read-only” address for people to send us updates.

The pain point I was feeling recently was with the Luigi package, which makes building data pipelines a snap. We use it extensively to build the data that backs the openfda API. Since some build steps can take several hours, it’s nice to start up a pipeline and go off to lunch (or to sleep). But when there’s a failure we want to know about it: Luigi conveniently supports email notifications for this task, but there’s no way to add a webhook.

Now the reasonable thing to do would be to just add support for a webhook notification to Luigi and send them a PR to get it merged. But then we’d still be stuck with email for all of our other services. So instead, I thought why not just proxy email to Slack directly? I know absolute nothing about SMTP or MX records, so how hard can it be?  But if I made such a service, we could use it for any service that supported email notifications. (My guess is that Slack will add support for such notifications like… 3 minutes after I post this, but anyway it will be useful until then).

With that in mind, I whipped up slackmail: a SMTP server that forwards messages to Slack. To make this super-extra-convenient, there’s 2 servers: one you can use locally for testing and another one that supports adding and removing hooks dynamically. To avoid getting spammed, you can specify an authorization token which must be present in the incoming mail for it to be forwarded. The code illustrates my almost perverse lack of knowledge about SMTP, but nonetheless appears to work.

If you don’t want to run your own server, feel free to play with my example server. To register a new hook, email [email protected]. Here’s an example using the `mail` command line client:

mail -s 'Add me, yo.' '[email protected]' <<HERE
target_email: [email protected]
authorization_token: you can't guess me

To remove a hook, just email [email protected] with the same content. Once you’ve registered a hook, any emails to `[email protected]` will be forwarded to your webhook. Feel free to email me at [email protected] to say hi!

(You can also email [email protected] if you like building interesting tools and helping make healthcare better!)

on dreams

The other night I dreamed about a plane full of people.  Somehow, I even knew the exact number (240).

Then I dreamed about something else.

Then I started feeling bad, because I realized the lives of those 240 people depended on me dreaming about them, and once I stopped, they disappeared.