Tag: transit

Obtaining Chicago Transit Authority geodata

A reader asked where they could get Chicago Transit Authority (CTA) data I didn’t already have on the “Find GIS data” page. I only had shapefiles for train lines and stations. Now I’ve got bus routes and stops.

You can download General Transit Feed Specification (GTFS) data from the CTA’s Developer Center. It’s updated regularly when service changes.

Screenshot from ESRI ArcMap showing the unedited shapes.txt file loaded via Tools>Add XY Data. Shapes.txt is an 18 MB comma-delimited text file with thousands of points that can be grouped together with their shape_id.

The GTFS has major benefits over providing shapefiles to the public.

  1. It can be easily converted to the common shapefile format, or KML format.
  2. Google, the inventor of GTFS, has defined and documented it well; it is unencoded and plaintext. These attributes make it easy for programmers and hackers to manipulate it in many ways. (see also item 4)
  3. Google provides a service to the public on its website, an easy to use and robust transit planning service.
  4. The data is stored as plaintext CSV files.
  5. While an agency like CTA may have a geodata server on its intranet, it is less likely it has the addons that provide mapping and geodata services for the internet. A server like Web Mapping Service, or ArcIMS. These systems can be expensive to purchase and license. And we all know how the CTA seems to always be in a money crunch. While the CTA updates its GTFS data for publishing to Google Maps, the public can download it simultaneously to always have up-to-date information, providing the same geodata that ArcIMS or WMS would offer but for no additional cost.

I couldn’t have pulled off this conversion in 24 hours without the help of Steven Romalewski’s blog, Spatiality. He pointed me to the right ArcMap plugin in this post about converting the Metropolitan Transportation Authority’s GTFS data into shapefiles. I hope Steven doesn’t move to Chicago less my authority on GIS and transit be placed in check!

Make your own map of the CTA train routes and perform some kind of analysis – then share it with the rest of us!

Read more about my exercise in geodata conversion in the full post.
Continue reading

How to convert GTFS to GIS shapefiles and KML

This tutorial will teach how you to convert any transit agency’s General Transit Feed Specification (GTFS) data into ESRI ArcGIS-compatible shapefiles (.shp), KML, or XML. This is simple to do because GTFS data is essentially a collection of CSV (comma separated values) text files (really, really large text files).

Note: I don’t know how to do the reverse, converting shapefiles or other geodata into GTFS data. I’m not sure if this is possible and I’m still investigating it. If you have tips, let me know.

Converting GTFS to GIS shapefiles

Instructions require the use of ArcGIS (Windows only) and a free plugin called ET GeoWizards GIS for any version of ArcGIS. I do not have instructions for Mac users at this time.

I wrote these instructions while converting the Chicago Transit Authority’s GTFS files into shapefiles based on a reader’s request. “Field names” are quoted and layer names are italicized.

  1. Download the GTFS data you want. Find data from agencies around the world (although not many from Europe) on GTFS Data Exchange.
  2. Import into ArcGIS the shapes.txt file using Tools>Add XY Data. Specify Y=lat and X=lon
  3. Using ET GeoWizards GIS tools, in the Convert tab, convert the points shapefile to polyline.
  4. Select the shapes layer in the wizard, then create a destination file. Click Next.
  5. Select the “shape_id” field
  6. Click the checkbox next to Order and select the field “shape_pt_sequence” and click Finish.
  7. Depending on the number of records (the CTA has 466,000 shapes), it may take a while.
  8. The new shapefile will be added to your Table of Contents and appear in your map.
  9. Import the trips.txt and routes.txt files. Inspect them for any NULL values in the “route_id” field. You will be using this field to join the routes and trips table. It may be a case that ArcGIS imported them incorrectly; the text files will show the correct data. If NULL values appear, follow steps 10 and 11 and continue. If not, follow steps 10 and 12 and continue. This happens because ArcGIS inspected some of the data and determined they were integers and ignored text. However, this is not the case.
  10. Export the text files as DBF files so that ArcGIS operates on them better. Then remove the text files from the Table of Contents.
  11. (Only if NULL values appear) Go into editing mode and fix the NULL values you noticed in step 9. You may have to make a new column with a more forgiving data type (string) and then copy the “route_id” column into the new column. Then continue to step 12.
  12. Join routes and trips based on the field “route_id” – export as trips_routes.dbf
  13. Add a new column to shapes.shp called “shape_id2”, with data type double 18, 11. This is so we can perform step 14. Use the field calculator to copy the values from “shape_id” (also known as ET_ID) to “shape_id2”
  14. Join routes_trips with shapes into routes_poly based on the field “shape_id” (and “shape_id2”)
  15. Dissolve routes_poly on “route_id.” Make sure all selections are cleared. Use statistics/summary fields: “route_long,” “route_url.” Save as routes_diss.shp
  16. Inspect the new shapefile to ensure it was created correctly. You may notice that some bus routes don’t have names. Since these routes are well documented on the CTA website, I’m not going to fill in their names.

Click on the screenshot to see various steps in the tutorials.

Converting GTFS to KML

After you have it in shapefile form, converting to KML is easy – follow these instructions for using QGIS. Or if you want to skip the shapefile-creation process (quite involved!), you can use KMLWriter, a Python script. Also, I think the latest version of ArcGIS has built-in KML exporting.

Converting GTFS to XML

If you want to convert the GTFS data (which are essentially comma-separated value – CSV – files) to XML, that’s easier and you can avoid using GIS programs.

  • First try Mr. Data Converter (very user friendly).
  • If that doesn’t work, try this website form on Creativyst. I tested it by converting the CTA’s smallest GTFS table, frequencies.txt, and it worked properly. However, it has a data size limit. (User friendly.)
  • Next try csv2xml, a command line tool. (Not user friendly.)
  • You can also use Microsoft Excel, but read these tips and caveats first. (I haven’t found a Microsoft application I like or think is user friendly.)

Travel grief

I came back to Chicago today after a trip to New York City.

The first thing I did when I arrived was imagine all the things that I want to change based on what I saw and learned in New York City. Someone told me this is travel grief, states of emotion and motivation in order to effect change.

What was the first thing I saw?

The Chicago Transit Authority (CTA) has three types of ticket vending machines (TVM) in the O’Hare Blue Line station. One is the common TVM that can create cards with cash value, add value to existing cards, or add value to Chicago Cards (with cash). The second TVM did all of this and accepted credit cards. The third TVM issued single or multi-day passes (I don’t remember if it took credit cards).

The vending machines in the New York City subway perform the functions of all CTA three machines AND all accept credit cards. Since 1999.

There’s more. I tried to keep a list. As I process my 500+ photos, I’ll be reminded of the ones I forgot to write down.

Road pricing is more fair than other funding schemes

I’ve written several papers on congestion and road pricing*. The most common type seen in the United States is HOT (high occupancy tolling) lanes. This is where drivers can pay to use uncongested lanes; drivers who carpool may use the lane for free or at a discount. Transit buses can always use the lane for free.

From the University of California Transportation Center comes new research on paying for roads with congestion versus paying for roads with sales taxes and their respective burden on poor residents.

Will research show that more people will benefit from paying sales tax to support a transit system than from paying (all kinds of) taxes to support a highway?

Their finding is that funding transportation with sales tax is less fair than funding with congestion pricing. In the latest issue of Access, Lisa Schweitzer and Brian Taylor write:

This analysis has focused on one side of the ledger: the question of who pays. But transportation systems have both costs and benefits. Indeed, the access benefits of travel are transportation’s raison d’être. So while regressivity can be viewed as a cost of road pricing (and of most other ways of paying for roads), pricing confers transportation benefits that other transportation finance mechanisms do not. Tolls and taxes can both pay to build a road. But congestion pricing can also reduce traffic delays, fuel consumption, and vehicle emissions, often to a surprising degree. Sales tax finance for transportation, by comparison, does none of these things.

I think the appropriate direction of this research should next discuss and examine the fairness of using sales taxes to provide operational and capital funding for transit. In Chicagoland, the Regional Transportation Authority is partially supported by a local sales tax. While sales tax financing for road building may not reduce traffic delays, fuel consumption, or vehicle emissions, supporting a reliable, robust and expansive transit network can do all of those things by reducing the number of single occupant vehicles on the road.

*Here’s one I’ve written: Implementing value pricing on a highway in Southern California, which I excerpted in HOT lanes and equity.

I think I finally figured out the purpose of making plans

No, not plans with friends for dinner at Ian’s Pizza in Wrigleyville (which was great last night, by the way).

I graduated in May 2010 and I’m just now figuring out why we should make plans. What did I come up with?

Plans are to give a basis for the future so that the future is shaped from what people collectively need and want. They keep you on track so you focus on what’s most important and not the things that will derail the path to the plan’s stated goals.

(You can quote me on that. But I wouldn’t rely on that statement to stay the same – it’s still a work in progress.)

For example, you go out and survey the bike parking situation at all transit stations in your city. You collect data on how many bike parking spaces are available, how many bikes are present (both on bike racks and other objects), and bike rack type.

You then gather information like ridership, access mode, and surrounding residential density. From this you can list the stations in order of which ones need attention now, which ones need attention later, and which ones won’t need attention. Talking to people who work at the stations, who use the stations, and others will help you fine tune the ranking.

That’s the plan. The plan might also include narratives about the rationale for having high quality, sheltered, upgraded, or copious bike parking at transit stations (hit up the Federal Transit Administration for that).

Then the plan sits. Two years later, someone reads the plan and decides to apply for funding to build bike parking shelters at the transit stations in most need.

What stations are those? Oh, the plan tells us.