Proposal: add a "live info" file with live information about transit vehicles' locations

[tompw]

Motivation
--------------
The number of transit agencies supply live information about their
vehicles' locations and expected arrivals times has been increasing
steadily. However, the format of these information feeds varies from
agency to agency. Further, where the live information is supplied by a
3rd party (e.g. NextBus), they must also duplicate the information
about routes, stop locations/names, etc.

Given that many of these agencies have GTFS feeds available (if only
to Google), I propose that a standardised format for live information
be included within the GTFS spec. This would be defined in a way as to
eliminate duplication of information an agency supplies through the
rest of the GTFS feed.


Proposal
-------------
A new optional liveinfo.txt file will be added to the specification.
Unlike other files in a GTFS feed, this will (almost certainly) be
generated by the provider's server on-the-fly. The provider could
allow optional parameters to be passed via the URL to limit or control
the information being provided

The table would have the following fields:

trip_id (Required): references the trip_id in trips.txt and
stop_times.txt

info_type (Required): takes one of three values
1 = the information is not the most recently available current
location for this vehicle ("past")
2 = the information is the most recently available current location
for this vehicle ("present")
3 = the information is a prediction about future location ("future")

location_lat (optional): the latitude of the vehicle location (past/
present/future)

location_lon (optional): the longitude of the vehicle location (past/
present/future)

stop_id (optional): a stop or station on the route. References stop_id
in stop_times.txt and stops.txt

location_time (required): the time the vehicle was/will be at the
given location, in standard "noon minus 12 hours" form.

location_date (optional): the date the vehicle was/will be at the
given location. Assumed to be "today" if blank.


The location must be specified by either location_lat/location_lon or
through stop_id.


Other thoughts
---------------------
* I had originally considered having the option of making the
location_time relative to schedule, rather than an absolute time.
However, some systems don't like the idea of negative times.
* I decided against using stop_sequence, even optionally, as a way of
referencing location. This is because any use I can think of would
require converting this into the stop's name or lat/long anyway.
* The use of info_type=1 would be particularly useful, for example, on
a commuter train service that wishes to provide how late/early a train
was at each station. (See http://ojp.nationalrail.co.uk/service/ldbboard/dep/BHM
- click on some of the "details" links)
* location_time could indicate either arrival time or departure time.
I am not sure whether the feed should ditingiush between them (perhaps
through a field named time_type taking the value of 1 if its an
arrival time, and 0 otherwise). The spec could say that they are
departure times if info_type si 1 or 2, and arrival times if
info_type=3. I'd welcome some input on this.

Any comments or suggestions would be welcome.