San Francisco Muni GTFS Problem

[Matt Conway]

There seems to be something wrong with the SF Muni GTFS:

(That's a screenshot from schedule_viewer.py)

Most of the routes look like that. They also look the same way in an OTP instance. Anyone have any ideas? The CSV files look OK, there are increasing trip_ids and stop_sequences; stop_sequences increase with time. There are quite a few warnings from feedvalidator (see http://indicatrix.wordpress.com/strata/sfmta-feed-validation-results/); in particular, the 'Too Fast Travel' and 'Overlapping Trips with Same Block' errors concern me. But there are only 120 of those two types combined, and it looks like almost every trip in the SFMTA's feed has this problem.

I'm using GTFS from http://www.sfmta.com/transitdata/google_transit.zip, downloaded today.

Any thoughts?

Thanks,
Matt

[Brian Ferris]

It looks like the shapes.txt data was generated with out-of-order shape sequence numbers.  Instead of getting a nice smooth shape along the route, the shape jumps back and forth between points along the route.  I'm guessing the schedule data itself is fine, but anything that depends on the shape data will look wonky.

Brian

--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To post to this group, send email to transit-d...@googlegroups.com.
To unsubscribe from this group, send email to transit-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/transit-developers?hl=en.

[Matt Conway]

Thanks, Brian! Looks like that was it... I unzipped and ran trips.txt through cut -d , -f -6 to drop the shape_id field, then rezipped. Looks much better now. I'll send a ticket to the SF Muni folks.
-Matt

[Andrew Byrd]

Hi Matt,

Did you hear back from SFMTA about this? The feed I recently
downloaded from their website still has the incorrect shape data, and
it expired on 2012-01-20. I'm wondering if we can expect an updated
feed with correct shapes sometime soon.

-Andrew

On Dec 29 2011, 10:48 pm, Matt Conway <mattwig...@gmail.com> wrote:
> There seems to be something wrong with the SF Muni GTFS:
>

> (That's a screenshot from schedule_viewer.py)
>
> Most of the routes look like that. They also look the same way in an OTP
> instance. Anyone have any ideas? The CSV files look OK, there are
> increasing trip_ids and stop_sequences; stop_sequences increase with

> time. There are quite a few warnings from feedvalidator (seehttp://indicatrix.wordpress.com/strata/sfmta-feed-validation-results/);

> in particular, the 'Too Fast Travel' and 'Overlapping Trips with Same
> Block' errors concern me. But there are only 120 of those two types
> combined, and it looks like almost every trip in the SFMTA's feed has
> this problem.
>

> I'm using GTFS fromhttp://www.sfmta.com/transitdata/google_transit.zip,

[Matt Conway]

All I heard was a message from their webmaster saying he had forwarded the message to their dev team. A phone call might be warranted; unfortunately I am very busy this week and won't be able to do anything on this until next week at the earliest.
-Matt

[Andrew Byrd]

I've been working with the new SFMTA GTFS feed posted last night, and
ran into a few problems. Anyone who will be working with this data, you
may want to unzip the feed and repair the following issues:

1) Suspect stops:

A) about 30 stops named "REFERENCE & REFERENCE" with coordinates of
37.82,-12.24 or 37.772889,-122.397866.

B) Stop 7247 "EMBARCADERO & ST" (-122.4, 37.82, NaN) is located in the
bay near Treasure Island.

C) Stop 4014 "Laguna Honda" does not appear to be used in any trips.

These stop ids do not seem to be referenced in stop_times.txt, so I just
deleted the lines from stops.txt.

2) Duplicate trips:
4696502 Existing: <Trip SFMTA_4696493>
4696504 Existing: <Trip SFMTA_4696490>
4696507 Existing: <Trip SFMTA_4696492>
4696500 Existing: <Trip SFMTA_4696491>
4696992 Existing: <Trip SFMTA_4696993>
4696989 Existing: <Trip SFMTA_4696990>
4657163 Existing: <Trip SFMTA_4657158>
4657025 Existing: <Trip SFMTA_4657026>
4657030 Existing: <Trip SFMTA_4657031>
4661040 Existing: <Trip SFMTA_4661030>
4661042 Existing: <Trip SFMTA_4661029>
4661041 Existing: <Trip SFMTA_4661026>
4680709 Existing: <Trip SFMTA_4680707>
4680702 Existing: <Trip SFMTA_4680710>
4695206 Existing: <Trip SFMTA_4695249>
4695190 Existing: <Trip SFMTA_4695204>
4695195 Existing: <Trip SFMTA_4695216>
4695194 Existing: <Trip SFMTA_4695214>
4695193 Existing: <Trip SFMTA_4695212>
4695192 Existing: <Trip SFMTA_4695222>
4695188 Existing: <Trip SFMTA_4695202>
4695189 Existing: <Trip SFMTA_4695203>
4723560 Existing: <Trip SFMTA_4695210>
4674329 Existing: <Trip SFMTA_4674302>

Hopefully your GTFS-consuming software will handle this gracefully.
Also, trip 4671496 overtakes trip 4671499.

3) shapes.txt still seems to be generated incorrectly. I deleted
shapes.txt from the feed and removed the shape_id column from trips.txt
by piping it through "cut -d , -f -6" as Matt suggested in a previous
message.

I cannot find a contact email for the development team on the SFMTA
website or in the feed's license agreement. I will submit a comment via
the web site feedback form, but does anyone know who at SFMTA could best
make use of this information?

-Andrew

[Matt Conway]

Andrew-
I've reported stop 7247 before, about six months ago now. I presume http://www.flickr.com/photos/mattwigway/5976949450 is the issue you refer to. I can't speak to the REFERENCE & REFERENCE, but I think I've seen them before and simply ignored them. Duplicate trips may or may not be correct; I know the bus I take in the morning has a reinforcement with exactly the same stop_times (that's not an SFMTA bus though). I would say use the feedback form, usually they get back to you within a few days. You might also tweet to @datasf. I may also have a contact at SFMTA, I'll look in my Rolodex when I get home and send an email if I do (I might be thinking of BART or SFCTA).

The last thing I have to recommend is that you might try the whole-bay data feed from 511/MTC; see http://511.org/developer-resources_transit-data-feed.asp.
-Matt

--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.

To post to this group, send email to transit-developers@googlegroups.com.
To unsubscribe from this group, send email to transit-developers+unsub...@googlegroups.com.