Adventures in Amateur Cartography

or, Making a map I couldn’t find anywhere else

A few months ago I moved to a different neighborhood and started exploring more. My list of preferred ways of getting around the city (in order) goes:

  1. Walk
  2. Bike
  3. Take public transit
  4. Taxi/Lyft/Uber
  5. Ride from a friend going that way
  6. Hitchhike with a stranger
  7. Run/jog
  8. Drive a car

For much of my day to day travels, walking or biking just aren’t as much of an option as I’d like them to be. I usually want to get where I’m going within a reasonable amount of time, and I almost always don’t want to show up sweaty and holding a bike helmet. I end up taking a bus, trollybus, streetcar, trollycar, lightrail, or cable car (herein after referred to as “bus”) most everywhere I go.

I’ve lived in San Francisco for several years, but always within a couple blocks of the initial friend’s-couch-to-crash-on apartment I stayed in when I first got here. I thought I knew the MUNI system pretty well, but it turned out that I just knew the MUNI busses that passed through my old neighborhood.

When I use the internet to look up directions I will look at the map to see the whole route rather than the turn-by-turn directions. I like being able to see the whole route. I like having a map in my head of the area. I like being able to go to a bus stop, look at the route listing, and know if any of the busses listed can get me closer to my destination.

For instance, if I’m waiting at Van Ness and Market street and I want to get to Haight-Ashbury, a quick check of Google Maps might tell me to wait for the 6. If I have a better sense of the bus system I would know I could take the 6 or the 7, and depending on where I’m headed, I can take an N train walk an extra 3 or 4 blocks and the time saved by going underground might get me there faster.

I set out to learn the bus system by trying to find a map that would let me easily explore a bus line’s entire route, in context with other bus routes and streets. Of course, the canonical way is with a MUNI map, and a great copy can be downloaded from their website:
Aside: When I first moved to San Francisco, I bought a paper copy of the MUNI map and hung it by the door to the apartment as decoration. In retrospect, that was a major part of how I learned my way around the city, and I highly recommend that to anyone else who is not adverse (and/or whose partner is not adverse) to the whole maps-as-decor aesthetic.

The limitation with the MUNI system map twofold: to find an unfamiliar route one has to search the entire map and to see an individual route from start to finish one has to trace it. The MTA does provide a map of individual routes (two, actually):

The first is, to be frank, pretty much useless as it provides almost zero context. Unless the question you’re asking is “does this bus go from this general area of the city to that general area of the city?” or you have an amazing ability to overlay a mental street map on top of a landmass outline, this map will not help.

The second is much more helpful, but lacks the feature that allows one to see the entire transit network at once and jump quickly to another route. To see another route map, one has to navigate through the MUNI website, which can be clunky.

I couldn’t find exactly what I wanted on the internet, so I decided to make it. I ended up with something that looks like the following:

I can see the entire system in context with streets, zoom and pan, highlight bus routes by name, and see the entire route from start to finish.

The first step in creating this transit route map is finding the data. Luckily for this project, the SFMTA provides data on the entire transit system in a standardized format, the General Transit Feed Specification.

We want to use this data to create GeoJSON linestrings for each SFMTA bus route, then draw and provide some interaction with those linestrings on a web map using Mapbox and D3.

Downloading the GTFS zip file from SFMTA provides several text files (comma separated) with data describing every scheduled trip, every stop, every fare, every route name, every prescribed path for the entire system. The three files that are most important to this map are “routes.txt”, “shapes.txt”, and “trips.txt”.


“routes.txt” identifies each route with a unique key and lists the route names we are familiar with: 1-California, 22-Fillmore, J-Church, etc. We want to get the route_id, route_short_name, androute_long_name.


“shapes.txt” contains lists of coordinates representing every different path that a bus will drive while making a trip. A bus on the same route might drive a different path depending on the time of day or day of the week. For example, on weekdays during the day the 5-Fulton route goes between the Transbay Terminal and 7th Avenue/Fulton St, but in the evenings and on weekends the 5-Fulton route goes between the Transbay Terminal and Ocean Beach; same route, different path. Another reason paths might differ is because of one-way streets. This is obvious in the difference between inbound and outbound paths for the 1BX-California:

The properties we’ll use from “shapes.txt” are shape_id, shape_pt_lon, and shape_pt_lat.


“trips.txt” is a list of every single time a bus is scheduled to make a trip from start to finish. We can use that data to figure out the “most common” trip to represent the path of the bus route. We’ll need to make note of the properties route_id, direction_id, and shape_id.

We’ll also need to note from “calendar.txt” that service_id can be 1, 2, or 3, meaning the trip schedule applies on weekdays, Saturdays, or Sundays respectively.

(Most of the following describes the script I wrote to parse the GTFS data files and transform them into GeoJSON files. That script can be found on Github.)

Using “routes.txt” we can define a Map between the route_id and route_short_name/route_long_name. This will allow us to assign a human readable name to each route.

By using “trips.txt” we’ll count how many times a shape_id is used for a trip, at the same time keeping track of the route_id and sorting each trip by its calendar schedule (weekday/weekend) and direction (inbound/outbound or East/West or North/South). Then we’ll set up another Map between route_id and the path, or shape_id, of the most common path for a route on a given calendar schedule going a given direction. This will give us a representative path for both directions of each route on weekdays and weekends.

Finally, using “shapes.txt”, we will create reate a dictionary between route_id and path, which is described by an array of coordinates (shape_pt_lon and shape_pt_lat).

With the two Maps and dictionary in hand, we then create a GeoJSON string for each route by joining 1) human readable name and the 2) path for the most common trip 3) to the path coordinates to the using route_id and shape_id.

As a result, we get a series of GeoJSON files that look something like the following:


Now that the schedule data has been transformed into GeoJSON linestrings representing the most common path in both directions for each route, the remaining task it to draw those linestrings on a map.

I used D3, Leaflet, and Mapbox for this because 1) I’ve used them before 2) I like open source libraries and 3) Mapbox tiles are very pretty.

That task is accomplished with a script that functions as a front-end app, which can be found here. “map.js” requests a list of bus routes and creates a list item for each route and direction. It attaches some event handlers which provide user interaction. Then “map.js” starts up a Leaflet map, requests tiles from Mapbox, uses D3 to download the GeoJSON linestrings for the bus routes, draws them on the page, and attaches some additional event handlers.

The result is a fairly simple map that allows one to explore different bus routes easily and quickly: exactly what I wanted to be able to do.

My map is live at

The source code can be found on Github.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.