Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 26 commits into from

Conversation

miklcct
Copy link
Contributor

@miklcct miklcct commented Aug 23, 2023

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

Michael Tsang added 26 commits March 31, 2023 10:32
This increases the memory limit as the original isn't enough to process the current timetable. Also, the executable bit is added into the script, and source map is added to enable debugging.

Related work items: #637
Update all train operating companies' name and contact details.
Update stations list to use coordinates from the latest stations knowledge base, and add a field for wheelchair access

Related work items: #638
The original upstream implementation lists passing points (where the train doesn't stop) as stops in the GTFS. This is misleading to customers so they are removed.

Also it fixes the case where one of the public arrival or departure times are not available, which should fall back to working time independently.

Unadvertised stops remain as stops in the GTFS.

Related work items: #639
# Conflicts:
#	src/gtfs/repository/CIFRepository.ts
@linusnorton
Copy link
Collaborator

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
Copy link
Contributor Author

miklcct commented Aug 24, 2023

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

@miklcct
Copy link
Contributor Author

miklcct commented Nov 9, 2023

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 .

@miklcct miklcct closed this Nov 9, 2023
@miklcct miklcct deleted the feature/platforms branch November 23, 2023 15:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

list both stations and platforms in the GTFS output
2 participants