MTA LIRR feed missing "calendar.txt"?

[Adam Ernst]

The New York City MTA has released its data feeds in GTFS format,
which is a great step forward.

One bump I noticed: the LIRR feed seems to be missing calendar.txt,
which makes it useless. Has anyone else noticed this? I'm trying to
figure out how to get in contact with the appropriate department.

Adam Ernst

[db.code]

Calendar.txt isn't technically needed for a feed file (although the
specification says it's required - it could be empty). They have
specified all of their service in calendar_dates.txt as exception_type
"1", added service. Portland does the same thing IIRC.

Devin Braun

[Adam Ernst]

Interesting. Thanks for the tip.

Adam

> --
> 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.
>
>
>
>

[Ethan]

Hi Devin,

Without Calendar.txt, how do I know which days a particular service
runs on? Do I just assume everyday?

Also, for NYC the calendar_dates.txt file is a bit weird -- it repeats
the same service many times with the exception_type "1". What would
that mean? Finally, do you know what exception_type = "2" means?

Thanks!!
-ethan

[Jehiah Czebotar]

Ethan, you can find the description for the GTFS format here

http://code.google.com/transit/spec/transit_feed_specification.html#calendar_dates_txt___Field_Definitions

exception_type 1 is schedule added on a given date
exception_type 2 is schedule removed

--
Jehiah

[db.code]

calendar_dates.txt is an exception list to calendar.txt. Since
exception_type 1 is added service, they are simply adding the
service_id listed on that line for that day. So instead of saying
service id "MF" runs Monday through Friday in calendar.txt, they're
spelling it out in calendar_dates.txt as individual lines for each
date. For a major system with many different services, it's probably
easier only to use calendar_dates.txt with exception_type of "1".
Otherwise you have to specify patterns of service_ids in calendar.txt
and then list all of the deviations from the pattern in
calendar_dates.txt with exception_type "2" and replacement services on
those dates with exception_type "1". However, for a small system
whose schedules never change, calendar.txt is the way to go.

Jehiah gave you the link to the GTFS specification document which if
you're going to use GTFS is definitely required reading.

Devin

[Ethan]

Thanks guys this helps a ton!

[Amtrak7]

Also regarding the LIRR feed, I have noticed one big problem. The
LIRR system is comprised of many branches that converge at Jamaica and
then diverge again into various terminals. The problem is, the MTA
apparently has separated each different terminal combination into a
different entry at routes.txt. For example, the Port Jefferson branch
is divided into Port Jefferson-Huntington, Port Jefferson-Jamaica,
Port Jefferson-Penn Station, Port Jefferson-Hicksville, Huntington-
Penn Station, Huntington-Flatbush Av and a few others. The biggest
example is Jamaica, obviously:

http://maps.google.com/maps/place?ftid=0x89c260cf96b42105:0x448a22db3e089d99

As anyone familiar with the service patterns of the LIRR can tell you,
this is an overly confusing way to display what is not a very
confusing operation. It appears the MTA is trying to bypass a
limitation of Google Transit, but it's not obvious to me what that
limitation is. Other agencies don't have this problem. NJTransit's
North Jersey Coast Line is a prime example. There is shuttle service
between Long Branch and Bay Head, as well as through service from Bay
Head to Hoboken and from Long Branch to New York. However, if you
click on Long Branch, all you see is North Jersey Coast Line and the
next trains.

Any clues what the MTA is trying to do here?

[Michael Frumin]

I tend to doubt the MTA is 'trying' to do anything here per se. Having studied a wide range of ways that transit services are represented in different kinds of network modeling scenarios and also worked for rail operators and managers, I actually think this is a totally reasonable way to represent your schedule because it is totally precise and non-arbitrary.

It is up to the application developers to figure out the best way to display the information. For example, imagine a subway line that runs every 3 minutes with a single route pattern. It would be easy to represent this schedule in GTFS, but the most effective way to show it to users is _not_ to show departures at 8:00, 8:03, 8:06, etc. Rather, just show that this line runs every 3 minutes. Similarly, for LIRR, an application should be able to figure out that many of these LIRR routes are similar (depending on my ultimate destination) and show me the info in the best possible way.

Isn't this the whole point of open transit data -- let the operator/agency give out just the facts, and let the market figure out the best way to support passengers. Under that thinking, if Google isn't displaying the info as well as it could be, well, maybe the product could use some iteration.

Mike