List each platform as GTFS stop in the generated GTFS, and various GTFS semantic fixes

[miklcct]

This pull request does the following:

• Generates all platforms which exist in the timetable data as distinct GTFS stops, with the ID in the format as CRS_3 and the code (which is public facing) as CRS. All platforms (GTFS stop) are associated to a GTFS station representing the whole station. TIPLOC is no longer used as it is irrelevant in passenger service - from a customer's perspective the code of a station is the CRS code.
  • The name of individual platforms are in the format of Paddington (platform A), consistent to the general labelling of TfL bus stops and to the best practice here
  • For multi-part stations, the minor CRS code is used for the platforms in the minor part, linked to the station which has the main CRS code. For example, Paddington (platform A) is listed in the data with stop_id PDX_A, stop_code PDX, which is part of the station with stop_id PAD and stop_code PAD.
  • RFC: Should we use Naptan code as the stop_id for compatibility of bus / tram GTFS generated from TransXChange?
• Adds the ability to supply alternative station data from an external JSON file, for example, one containing station names and coordinates extracted from OpenStreetMap provided as an example.
• Changes the short name of GTFS routes from some meaningless symbols to the RSID (without the portion suffix), such as SW9283. The RSID is the train number which is designed to be shown to public in customer facing systems including reservation slips, but for unknown reasons it hasn't actually been implemented. If the train doesn't have an RSID, the UID is used in place instead.
• Changes the long name of GTFS routes to ${origin} → ${destination}, for example, Brockenhurst → Poole
  • RFC: According to the best practices, the brand name (such as Stansted Express, London Northwestern Railway) should be included in the long name, but it isn't included in the data. It is possible to hardcode them in the code but should we do that?
• Changes the description of GTFS routes to ${this.modeDescription} service from ${origin} to ${destination}, ${this.classDescription}, ${this.reservationDescription}
• Removes the trip headsign. The headsign, by definition, is the destination shown on the front of the train. It is available in Darwin, but it is not available in the schedule data. For example, for a Strawberry loop service, the headsign should be Strawberry Hill in the beginning, which is changed to Wimbledon and London Waterloo as the train progresses along the journey. The placement of UID there is wrong.
• Removes the stop headsign. The explanation is the same as above. The use of platform number there is wrong.

Closes #69

[linusnorton]

This is a difficult one. I think it might be best to split up some of the changes. There are several we can integrate easily:

• Wheelchair access
• Station data from an external file
• Route names

Unfortunately changing the CRS codes, headsign and general structure is difficult because there are people (myself included) that rely on those fields being in those places. A compromise might be to use some custom fields for the additional data but it also might be best to just maintain a fork with those changes.

[miklcct]

We will then decide later as our company business plan may require some other custom fields as well.

[miklcct]

Closing this one as our codebase has since revolved, and further changes have been made to improve the data quality including grouping trips into routes by origin - destination, putting colours into GTFS, loading schedules starting from 7 days ago for journey planning purpose, etc.

Our work is available at Jnction:aubin-master .