[GTFS Full Support] Resolve stops/transfers situation

[jamespfennell]

We want to support:

• Having plain old transfers between arbitrary stops, sourced from transfers.txt. We want to expose these in the HTTP API.
• Still having a notion of grouped station, with the use case being NYC Subway stations.
• Configuring the GTFS Static parser on a feed-by-feed basis to determine the right "transfer strategy".
• Maintain the current service maps philosophy, which is that only genuine stations can be a part of a service map.

[jamespfennell]

feeds:

  gtfsstatic:
    http:
      url: 'http://web.mta.info/developers/data/nyct/subway/google_transit.zip'
    parser:
      built_in: GTFS_STATIC
      options:
        transfers:
          strategy: DEFAULT  # or GROUP_STATIONS
          exceptions: 
            - [L26, 254] 
    required_for_install: true
    auto_update:
      enabled: false

[jamespfennell]

We can create a new Transiter-only stop type "STATION_GROUP".

[jamespfennell]

One detail is that we should view transfers not as between stops but as between stop trees. This is because we assume that if you're in one stop in the tree, you can easily move physically to another stop in the tree.

In the HTTP API, perhaps it would be something like:

{
    "name": "Union Sq",
    ...
    "parent_stop": ...
    "child_stops": ...
    "transfers": [
        {
            name: "Root station in the transfer stop graph."
        },
    ]

I think there's not need to expose transfer times in the API.

[jamespfennell]

Tasks:

• ~Reform the stop table as per the GTFS Static spec. Create an is_station function (or property?) that has the right logic depending on the presence of a parent or the type of the stop. At this point, there should be no regressions or changes in behavior in general.~ Done.

• ~Fix #48.~ Done.

• ~Enable adding options to parsers.~ Done.

• Add the option described above the GTFS Static Parser. Half done

• Create the transfers table and parse type and the associated infrastructure in the ETL code for importing transfers data.

• Implement transfers in the HTTP API. This will be hard because the potential for code duplication is large. The transfers data should also be (optionally?) presented in the route endpoints (via service maps) and the trip endpoint so that consumers can show all the data. Possibly file follow up tickets for this.

[jamespfennell]

Stop trees have a base, which is not necessarily the root of the tree. We can return certain nodes and/or traverse a subset of it in different ways.

• Return ancestors (of the base).

• Return descendants (of the base).

• Return children of any stop returned. Aka, descendants of ancestors. Filter by stations here?

• Return only stations (if the base is not a station, return it anyway).

When returning a stop tree, we want two different things:

• Specific data on other stops, like service maps at those stops and their names.

• Data on the tree as a whole, like the overall service maps.

Based on this, these are examples of endpoints and what we should return by default:

• Get stop endpoint: descendants, ancestors, children, only stations

• List stops endpoint: none

• Get route endpoint: ancestors (so that we can see the service maps of the whole stop tree)

• Get trip endpoint: ancestors (as above)

For transfers, we probably want to just return the root of any stop tree that can be transferred to.