Looks good. You're going to need a way to show the time zones, though.
Yeah, that's one of the many issues I still have to work on.
Since it *is* possible to simply look up cities and find out what time zone they are in, and a lot of people know that Chicago is Central and New York is Eastern, it hasn't been my top priority. The time zone data is in the GTFS data.
The way it was displayed in the old Amtrak timetables is certainly possible, but will require some tricky HTML and is a bit nonobvious to the viewer. I think we can do better.
Do you have an opinion on where to display the time zone? City cell, time cell? What part of the cell? Column of its own?
It's easy enough to display the timezone in every row. Picking it out so it's only shown at the stations adjacent to the time zone change is harder, though I think I just figured out how to do it while I was typing; I need to do a pre-pass across the stations before the main timetable filling routine. (I'm already doing another pre-pass to find the dwell times. I think I'm going to have to add another one for another reason.)
----
In case people are curious, here's some of my rather long to-do list for timetable_kit (and mind you, I'm going to be interrupted by needing to do income taxes soon):
Top priority: I'm going to get the baggage symbol placed where it belongs, which is very important. I can extract which stations have checked baggage from Amtrak's station DB (available on the web in JSON), but I have to clean that code up. At the moment I need to maintain a list of which trains have a baggage car separately, but I think that's probably manageable, though I probably have to special-case 448 & 449.
I also have to get the implementation for less-than-daily information working properly, important right now; I had that working in an earlier version, so that should be a fairly simple matter of forward-porting.
I'm also going to get a row showing the train names implemented; that one should be easy.
Those are fairly small projects.
My next stages of major work are actually some internal code cleanup. There's some very ugly string-patching stuff in the presentation code which I'm hoping to simplify and make more maintainable with jinja2 templates. My plans for this aren't pinned down yet; I've got some prototyping and design work to do. Whatever I do has to be better than the current very long list of string concatenations and individual small file reads I'm currently doing.
A thornier problem is that I don't have a good approach for loading resource files (templates, "specs", fragments) from either the module itself or a user directory (which should override module defaults); I'm currently just doing "run it all out of the program directory and hardcode the file names". I've been trying to find out if there's a standard or preferred method of doing this in Python, but I'm not sure yet.
If anyone here knows Python and knows the answer to this, let me know. (I taught myself Python to write timetable_kit.)
I also have to patch the open-source font I'm using; I'm currently using a very hacky scheme to get the numbers in the times lined up by boxing them individually in HTML; it makes it difficult to change the font size. I know how to amend the font to provide tabular-nums which should allow a cleaner implementation; this is straightforward but will take quite a bit of tedious repetitive work.
These three changes together should allow for easier changes of font, font size, symbol choices, colors, and page layout changes (like key to the right of the timetable, two related timetables on one page, etc.)
What I have right now works well if you know which train numbers should be listed in the timetable, in what order, which have to be specified in a "spec". I am now certain that that can't be fully automated (it's an artistic decision), but I also need to write some more code for prototyping these (code to extract all the trains from NY to DC and put them in order, for instance) even though it will need manual tweaks before making it a "spec". I don't think that'll be difficult since I've got the right framework, and I already have some prototype functions, but it'll involve some code reorg.
There's more; the very tricky problem of showing connecting trains on a single timetable has been on my mind and I've got a couple of approaches. That one might not get done quickly though. (The California Coastal Services timetable is my holy grail of timetables; I'm not sure I can replicate that one but I'm gonna try.)
In the longer run, I'm going to try to separate out the Amtrak-specific stuff so this can be used for other agencies' timetables too. The underlying architecture also makes it theoretically possible to do something like a merged Amtrak / Metro-North or Amtrak/Metrolink/Coaster timetable, though it would require another layer of coding to pull out the relevant data and merge it. Right now it's entirely Amtrak-dependent (I'd need totally separate code to extract station information for a different agency).
-----
I can't really use any of this for real timetables until I get current Amtrak GTFS though. :sigh:
The main reason I'm not producing more installments is that I don't have accurate data, so these are pretty but they're no good as timetables without the GTFS data.
That's why there's just the one sample. (I actually have test runs on a bunch of other timetables in my working directory.)
When I get the data, I'll start putting out timetables, probably through RPA.