1 2 Boarding 3 Next Page 4 5

Local OSM spotted in the wild

Spotted this map while out and about yesterday (…and quickly appropriated it for the geography grad office).

osm-screenprint mapPeople I don’t know making maps?? WHHAAAAT? How exciting! And screen-printed no less.

As everyone may or may not know, there’s no obvious and standard ontology in the world of cartography and map data, meaning that each dataset has its own way of describing and encoding the objects of the world. Its own familiar quirks. I was able to pick this out as OSM data by the too-thick blotches in the railyard, where I remembered I had failed to properly classify some of the shorter segments.

Comments: 1
Posted in: Data | Maps
Tags: |

GIF of the day

Just another way of looking at speed distributions. This shows the distribution of observed speeds across several thousand route segments by percentile of the speeds on each segment. The animation changes as we’re shown different parts of the speed distribution on each segment.

relative speed distributions on route segmentsNot totally sure if it’s useful yet, but it is kind of pretty.

Comments: Leave one?
Posted in: Data
Tags: | | | |

Average vs Scheduled Speeds

Some news from the thesis front:

I think I’ve finally perfected my method for linking real-time data with scheduled stops. This is a comparison of the average (weekly) scheduled speeds to the observed average speed for each stop->stop segment. Results that look roughly as expected are what we all hope for.

TTC - differences in observed and scheduled speeds

Note that each classification is broken into eight equal sized quantiles

There is a lot of information in that little gif! More than I can explain here. More to come…

Higher resolution here by the way. It’s interesting to look at even if you don’t know Toronto. Also, the line widths are determined by the number of trips scheduled for each segment.

Comments: Leave one?
Posted in: Data | Maps | Method
Tags: | | | | |

SORTA’s Real-time API Now Available for Developers

Yep. It’s finally here! :-D

Vehicle location feed:
http://developer.go-metro.com/TMGTFSRealTimeWebService/vehicle
Trip update feed:
http://developer.go-metro.com/TMGTFSRealTimeWebService/TripUpdate

The data is structured according to the GTFS real-time specification. I was able to parse it pretty easily in Python by following the instructions on that page. The fields currently included in the feed (many are optional in the specification) are as follows.

VehicleLocation feed sample data:

id: "4001"
vehicle {
  trip {
    trip_id: "940867"
  }
  position {
    latitude: 39.1043395996
    longitude: -84.3908996582
  }
  timestamp: 1421889007
  vehicle {
    label: "4001"
  }
}
...

TripUpdate feed sample data:

id: "938755"
trip_update {
  trip {
    trip_id: "938755"
    start_time: "17:07:00"
    start_date: "20150121"
    route_id: "1"
  }
  stop_time_update {
    stop_sequence: 5
    departure {
      delay: 60
      time: 1421878357
    }
    stop_id: "EZZJOHe"
  }
...
  stop_time_update {
    stop_sequence: 32
    arrival {
      delay: 60
      time: 1421880000
    }
    stop_id: "PAR2610e"
  }
  vehicle {
    label: "1001"
  }
}
...

The feeds update every 30 seconds, which seems a little slow, but oh well.

Right now, my understanding is that these feeds have been tentatively released as-is for developers only, and that SORTA is not ready yet to make a general public announcement that real-time data is available. Tim Harrington at SORTA, who shared the links with us, has politely asked to see the neat stuff that we’re able to develop with this data. I imagine that the sooner someone sends him a link to a decent, working app, the sooner they’ll give us the go-ahead and the sooner we’ll all be able to use this data in every-day situations.

So who’s gonna make an app? There must be a dozen open-source applications that are already designed to work with GTFS-realtime. We probably just need to plug this feed in and maybe make a few localization tweaks. If you or anyone you know has the skills and/or interest to make an app…then for the love of transit, let’s make this happen ASAP!

Comments: 12
Posted in: Data | Events
Tags: | | |

“without raising fares”

A wee nit to pick from SORTA’s recent “State of Metro'” dog and pony show:
I distinctly remember one of the speakers saying something like ‘and all this without raising fares!’, and this to my feeble memory reeked of bullshit, so I found the numbers again and ran them to see if I was remembering correctly. I was indeed.

Here are the facts, as reported by SORTA to the Federal Transit Administration. Over the period where we have data on both fare revenues and ridership (currently 2002 to 2012) SORTA has been steadily getting more money from fare revenues while moving fewer passengers. We are currently at the nadir of this trend, with

  1. More fare revenue than ever
  2. Fewer passenger trips than ever

When SORTA says by the way that they are a ‘most efficient’ agency, a title pinned on them by the laughably unscientific UC Economics Center, it is precisely this measure they have in mind. There is hardly a better example of doublespeak to be found. Here’s the trend:

a shitty decade for transit

In order to plot both agencies together, I normalized fares and passenger trips to the same range. The scale is linear.

Now you may rightly note that the standard fare for a zone 1 trip hasn’t changed lately. But that’s not the only kind of fare that can be paid. It might not even be the most common! I don’t know for certain. I haven’t personally paid standard fare in quite a while because my transit use is partly subsidized by UC. So for example, the fare revenue variable in this data almost certainly includes UC’s cash subsidy for my fare as well as the dollar I put in myself. Multiply that by the dozens of private fare subsidies each agency probably negotiates (or drops) each year and you get a more dynamic picture. Fare could also be effected, though probably isn’t, by people using transit cards more or less, while paying the same monthly price.

But anyway, I’ll be damned if f the total price paid by riders or their agents, on a per-trip basis doesn’t constitute a better definition of ‘fare’ than SORTA’s standard zone-1 single-segment price. And by that definition, fares have risen from $0.76 in 2002 to $1.78 in 2012 (+134%). For TANK, the change is from $0.72 in 2002 to $1.16 in 2012 (+60%). Adjusting for inflation, the changes are 84% and 26% respectively. So much for SORTA’s unchanging fares theory lie.

—-

I’ll end with an ineffectual plea to the people at SORTA. Please, understand that when you speak in lies and euphemisms, no matter how nice your breakfast spread,  you turn off clever people and retain only the idiots and the cynical. People from all three of these categories vote, to be sure, but I know who I’d rather spend my time with. And I know who could build the better transit system.

Comments: 2
Posted in: Analysis | Data | Politics
Tags: | | | | |

Making tracks

Here are some early results from my efforts to track transit vehicles, these ones in Toronto:

ttc-early-tracks

It looks like a crude system map, and it is, but it’s actually made of thousands of vehicle GPS tracks.

The vehicle tracks are oddly pretty; I keep wasting time just zooming in on different spots as new tracks are added. Here’s a transfer point at one of the subway stations:

transit station

Bus stops shown as ~20m circles

And what looks like perhaps a train station or a bus garage, below. This image also shows the relative frequency of service on different streets, something that becomes quite visible in the data when the lines are given a high degree of transparency.

bus garage?

Buildings for scale

And here’s an expressway carrying some limited-stop services:

expresswayAs of now, after just a week of  erratic development and testing, I’ve collected ~60,000 unique tracks, representing ~160 scheduled lines, derived from 3,200,000+ vehicle location records. About 50 new vehicle locations come in each second that I have my little script running.

Here’s what I’m doing so far, described algorithmically here, and implemented in a Python script:

A track is a set of ordered points, each point with a position and a time. The next step is to line the tracks up with the stop segments to which they’re scheduled, and if they’re actually close and the direction matches, to calculate stop times and segment durations from the observations. That’s actually turning out to be pretty difficult, but I’m sure I’ll crack it fairly soon. One thing I’ll have to seriously consider as I’m doing this is error in the location reports.

downtown signal degredationAs the first image and the one immediately above show, there is significant error in the data, particularly downtown where tall buildings are presumably interfering with GPS signal reception.

Comments: 2
Posted in: Data
Tags: |
1 2 Boarding 3 Next Page 4 5