Missing GTFS table attributes - A wishlist.

[splendidbits]

Some updates to possibly bear in mind going forward, if it's not a big headache. Below are a list of (at least my personal) nice-to-haves, written under in the context of the GTFS tables in question. I'll keep this updated.

As always thanks for your work. Please see this as more of a wishlist.

General:

• The bus and rail csv's are in different line-termination encoding methods. \n vs \r\n (mac vs windows).

  Bus GTFS data:

  agency

• _agencyid - Include agencyid primary key that corresponds to the existing rail agency table data ("SEPTA"_)?.

  fare_rules

• _routeid - Any corresponding route_id information.

  feed_info

• This is personally the big one GTFS attribute documentation. While _startdate, _enddate, and _feedversion are not "required", they would provide a nice way for 3rd-party server / client aggregators to query if the GTFS bundle(s) are outdated. It may also help Google pick up the new schedules in a timely manner, although I know nothing about this process.

  frequencies

• Ignorable as it's only for frequency-based schedule data, which SEPTA does not employ.

  routes

• _agencyid - See the above comment regarding the agency_id primary key.
• _routeurl - A fully-qualified url to the SEPTA route webpage. i.e.: trolly_route_13.
• _routecolor - Route hex color information for missing route rows.

  stop_times

• _stopheadsign - would be nice (say compass direction), as it saves a trips table lookup. Not a big deal, though.

  stops

• _locationtype - For large stations such as Jefferson, please mark as 1. Not a big deal though. (docs)
• _wheelchairboarding - A bit confusing as some stations are listed with 0 but the other rows are null. Possible formatting issue.

  Rail GTFS data:

  fare_attributes

• Any corresponding fare information, although can understand potential complexity with this.

  fare_rules

• Same as above.

  feed_info

• Same as the bus _feedinfo comment.

  stop_times

• _stopheadsign - Same as bus _stoptimes comment.

  transfers

• Center City transfers would be a nice-to-have.

[RideSchedules]

This all sounds great, especially adding fare information.

[zachpepsin]

These changes would be amazing. One other thing I would love: if stations that connect with other rail lines (such as 30th St) used the same stop_id across other GTFS feeds. It would require minimal coordination with NJ Transit, but would make it much easier to handle transfers with other rail lines.

[fulldecent]

Quick note: all of the required information per GTFS specification, updated July 12, 2016, is in SEPTA's file.

https://developers.google.com/transit/gtfs/reference/

This issue relates to adding optional data that is predefined in GTFS.

---

If anyone's interested, here is a script I use to import SEPTA rail data into SQLite https://github.com/fulldecent/septa-regionalrail-otp/blob/master/Getting%20GTFS%20Data%20from%20SEPTA/sqliteGTFSImport.txt

[splendidbits]

@fulldecent Your script 404's. If you could come in Saturday and re-upload that would be great.

@zachpepsin I actually forgot to write that way back then (before NJT had any GTFS feeds at all), and yes, this would be amazing.

@septadev Just to update this thread, getting a consistent experience through both feeds is still a hardship for me. Especially having the same (SEPTA) agency_id across all tables. Thanks!

[fulldecent]

Updated link: https://github.com/fulldecent/septa-regionalrail-otp/blob/master/website/databases/README.md

[fulldecent]

Since I just redid the file. Here it is if you want it.

septaSchedules.db.zip

[fulldecent]

Since I just redid the file. Here it is if you want it.

septaSchedules.db.zip

[splendidbits]

@fulldecent thanks!