MyTTC.ca

[Kieran Huggins]

Hey everyone,

Kevin Branigan and I released MyTTC.ca for public testing the other day.
The trip planner uses Brandon's Graphserver and we're now generating a
valid GTFS feed. The site is built on Ruby with Merb; the full stack is
described here: http://myttc.ca/colophon

Kevin is still adding a lot of stops to the DB, but we focused on the
major ones (intersections) first and they're all accounted for. The TTC
dataset is kind of huge and we passed the 1,000,000 stoptime mark the
other day on our way to an estimated 3,000,000. There's a stats page at
http://myttc.ca/stats if you want to see where we are, data-wise, in the
grand scheme of things.

There's an API on the way as well as an SMS/twitter gateway (once the
API is documented) and still a hefty stack of other stuff we'd like to
implement.

All in all we've had a really positive response (and a lot of great
feedback) from people in the area. I'd love to hear comments and/or
suggestions from other transit developers as well!

Cheers,
Kieran

[Joe Hughes]

Congratulations on the launch, it's looking good! Are there plans to
allow others to help build the data set (like in the old days)? How
about a preliminary feed of the data you've entered so far?

Joe

On Jul 25, 6:09 pm, Kieran Huggins <kie...@kieran.ca> wrote:
> Hey everyone,
>
> Kevin Branigan and I released MyTTC.ca for public testing the other day.
> The trip planner uses Brandon's Graphserver and we're now generating a
> valid GTFS feed. The site is built on Ruby with Merb; the full stack is
> described here:http://myttc.ca/colophon
>
> Kevin is still adding a lot of stops to the DB, but we focused on the
> major ones (intersections) first and they're all accounted for. The TTC
> dataset is kind of huge and we passed the 1,000,000 stoptime mark the

> other day on our way to an estimated 3,000,000. There's a stats page athttp://myttc.ca/statsif you want to see where we are, data-wise, in the

[qlex]

Hi Kieran,
congratulations on a very good job.

My team doesn't neccesary say (as you ask on your website) that we can
do better, but certainly want to improve transit.
we are working hard on a deployment of a map-based journey planner for
public transport company in Poland (who would think a polish company,
state-owned almost) decided they will give us a go on preparing a
transit planner.

anyways, our plan for go-live is 1st of october and although first
version will be in polish only, i will keep you posted so you can have
a look at it. actually, does anybody want access to it now
(development version and working slowly) to give us a hand on front-
end changes ?)

regards,
Qlex

On 25 Lip, 11:09, Kieran Huggins <kie...@kieran.ca> wrote:
> Hey everyone,
>
> Kevin Branigan and I released MyTTC.ca for public testing the other day.
> The trip planner uses Brandon's Graphserver and we're now generating a
> valid GTFS feed. The site is built on Ruby with Merb; the full stack is
> described here:http://myttc.ca/colophon
>
> Kevin is still adding a lot of stops to the DB, but we focused on the
> major ones (intersections) first and they're all accounted for. The TTC
> dataset is kind of huge and we passed the 1,000,000 stoptime mark the

> other day on our way to an estimated 3,000,000. There's a stats page athttp://myttc.ca/statsif you want to see where we are, data-wise, in the

[Kieran Huggins]

Thanks Joe!

We originally planned to crowd-source the missing stops, but have since
found a new source them. Kevin finds it easier at this point to do this
importing himself, given both the number of stops and the fact that the
shapes still need manual corrections before they're generated. We'll
likely be using the crowd-sourcing part of the app when we're done in
case we've missed any.

For now, we're more interested in crowd-sourcing article information.
I'm really interested to see what kind and quality of information users
will contribute. Transit seems to have a huge following in Toronto and
has inspired loads of wicked content.

Anyway, here's a link to our current GTFS feed:
http://media.myttc.ca/myttc_gtfs.zip

The validator complains about a about 150 unused shapes, 400 unused
stops (most have been replaced) and roughly 2000 proximity warnings. The
proximity warnings resulted from a conscious design decision; we wanted
distinct stops rather than a single combined stop per intersection. Not
sure if there was a reason for the former when the GTFS was designed,
but our way doesn't seem to make anything kersplode.

The dataset is still growing rapidly as Kevin imports more in-between stops.

@Qlex: I'd be happy to have a look!

Cheers,
Kieran

[Tom Brown]

On Fri, Jul 25, 2008 at 6:57 PM, Kieran Huggins <kie...@kieran.ca> wrote:

The validator complains about a about 150 unused shapes, 400 unused
stops (most have been replaced) and roughly 2000 proximity warnings. The
proximity warnings resulted from a conscious design decision; we wanted
distinct stops rather than a single combined stop per intersection. Not
sure if there was a reason for the former when the GTFS was designed,
but our way doesn't seem to make anything kersplode.

That's pretty good results! These warnings are really common. The cutoff for proximity warnings is 2 meters. Looks like you put the stops at exactly the same location so I think the warning is fair :-) I created http://code.google.com/p/googletransitdatafeed/issues/detail?id=72 earlier today
2829,,Eastbound on Lake Shore at 37th,,0.435934181213E2,-0.795381546021E2,,http://myttc.ca/eastbound_on_lake_shore_at_37th
2957,,Westbound on Lake Shore at 37th,,0.435934181213E2,-0.795381546021E2,,http://myttc.ca/westbound_on_lake_shore_at_37th
Ideally the lat,lng is the exact location that passengers wait so these should be on opposite sides of the street, probably not feasible for you without a major crowd effort to correct automatic geocodes. You could nudge each stop a few meters in the direction you expect it to stop. But if someone uses your data for that level of precision (not unrealistic with GTFS data getting on consumer GPS devices) they may want better than a guess. Many agencies do have the location of every stop to within a few meters. There are other proposals for handling sets of logically associated locations but that is more a topic for the gtfs-changes group.

And I don't think exponents should be used to represent floats. I created http://code.google.com/p/googletransitdatafeed/issues/detail?id=75

[Kieran Huggins]

Yeah, many of the proximity cases were the result of using the Google Maps auto-route feature to generate cleaner lines in our shape editor. We do have plans to move the stops themselves to the correct point on the map, but that will likely happen after we've imported more stops.

I'll mention the exponents to Kevin, I have a feeling it's a ruby feature that we could easily circumvent.