Progress on my printable timetable generator

[Jack Kittle]

My partner just tested positive for Covid which she caught at a doctor's office -- the SECOND TIME she's caught Covid at a doctor's office -- so I'm gonna be a little distracted. I'm still testing negative so far. I still think I should be able to get the baggage implemented today...

I'm finding there are additional options I want to put in which don't fit neatly into the CSV-based tt-spec format. Notably, the page title, though also the author, portrait vs. landscape, etc. So far I've just been making them command-line options or hacking directly in the templates folder. My current thought is to have a second file ".tt-aux" or something similar for the options, since I like being able to load the tt-spec file directly into a spreadsheet for all the table-based layout (stuff specific to rows and columns).

Hope COVID does not hit your family too hard!

I like a second aux file for options rather than on the command line. Perhaps it could specify general stuff like author and date, then include a set of table specific files. Each table reference could point to a current spec file and have a name for the generated table.

 

[neroden]

Mmmm, you just answered the question of how to specify two tables on one page. I like it, but it may take me some time to implement. For now, I'm just grabbing foo.tt-aux files with the same name as foo.tt-spec files. At least this gives me semi-respectable timetable titles (though I do want to work more on them).

I'm still requiring that the author be specified on the command line to avoid *misattribution accidents*, when one person adapts someone else's .tt-aux/.tt-spec files.

Thanks for the positive wishes.

I may not be able to work much more on this for some time. But I'm kind of itching to, so you never know.

I updated the documentation. You might want to take a look at find_trains.py and get_station_list.py, which dump information which is useful for preparing a .tt-spec...

 

[neroden]

Couple of quick fixes -- we have route names. I still plan to try to fix a couple more bugs and add a few more features before starting to release a full set.

 

[neroden]

Wheelchair access symbols working. I've only got a couple more things on my list before I start going through and making timetables for everything; I don't want to be perfectionist. But I do want to get the "currently supposed to be valid on the following dates" implemented, since that is in the GTFS and gives an important warning.

Unfortunately, now I am doing taxes so next update will probably not be until after April 15th.

 

[neroden]

Here's an update. I have some internal work to do to make it a little easier to mass produce timetables (not visible in the final output).

But I'm pretty proud of what I've achieved. I DID get the TuThSa->WeFrSu->ThSaMo pattern working.

There's a lot more to add (which stations are staffed, for instance? an indicator of sleepers other than color?) but I'm thinking this is good enough for a mass timetable release (which I will probably start in on next week after I finish my taxes). Agreed?

BTW, I can now produce timetables as HTML, PDF, or JPG. And in landscape mode (see tt_empire-w.pdf).

 

[neroden]

The engine has pretty quick turnaround, as you can tell because I sneakily replaced the tt_empire-w.pdf file three times with improved versions since I made that post.

 

[neroden]

So, requesting opinions -- is this good enough that I should go ahead and produce a full set for RPA to put on their website? (Before making Yet More Improvements?)

I will continue to make improvements regardless, but I figure at this point it's more of a service to have a full set of these up even if they're missing stuff like staffed-station status. Am I right?

 

[jis]

I think this is good enough for V1.0

 

[dadonatrain]

So, requesting opinions -- is this good enough that I should go ahead and produce a full set for RPA to put on their website? (Before making Yet More Improvements?)

I will continue to make improvements regardless, but I figure at this point it's more of a service to have a full set of these up even if they're missing stuff like staffed-station status. Am I right?

This is marvelous work! Anything in analog form (aka hard copy paper) that this ol’ near-Luddite can read in hand while enjoying a glass on my patio, as I’m doing now, would be wonderful! Great work, sir. Don’t forget to file on time!

 

[neroden]

Great. Then my only planned changes before V1.0 will be the internal code changes to make the invocation interface a little better for batch-producing timetables. (For the obvious reason that this will speed up my rate of producing timetables.)

 

[Ryan]

These are awesome, and way better than none at all.

A minor nit, looking at the cono_short, is it possible to put the "AR" and "DP" in the cell they refer to? Having them in the column for 393 is odd looking (particularly the final arrival time in CDL being listed next to the "DP").

Edit: same timetable - the Mo-Fr looks much nicer than the "TuWeThFrSa". Can you say "Tu-Sa" in the same way?

 

[joelkfla]

Is this stuff available in the GTFS?

 

[neroden]

Is this stuff available in the GTFS?

View attachment 28074

The on board services information is NOT available in the GTFS, or in any other computer readable source I've found.

For which trains have checked baggage, I had to make my own database based on asking around here!

The station services information is not in GTFS but I can pull it direct from the Amtrak station webpages in computer-readable form; it's just a bit of a pain.

 

[neroden]

These are awesome, and way better than none at all.

A minor nit, looking at the cono_short, is it possible to put the "AR" and "DP" in the cell they refer to? Having them in the column for 393 is odd looking (particularly the final arrival time in CDL being listed next to the "DP").

It's possible. To save space I don't want to do it on every column. Which column it's on is selected by the spec file, and I just threw it on the left column. This is selectable by the person designing the timetable.

Edit: same timetable - the Mo-Fr looks much nicer than the "TuWeThFrSa". Can you say "Tu-Sa" in the same way?

Yeah, probably. The amount of bit-twiddling involved in getting those done is *extensive* and I only picked out Mo-Fr because it is common for day trains.

I was debating how much special casing to do. Originally I got the text display working for three cases: (1) three-a-week / four-a-week trains with alternate days, (2) Mo-Fr, (3) SaSu, (4) Daily. I'm not sure how much work to put into the five-a-weeks, since we're hoping they all go away soon...

 

[neroden]

So the reasons I'm putting off the onboard services information is twofold:
(1) I cannot get the data automatically, and would have to assemble my own database as I did for baggage and sleepers
(2) I have to design icons for it, which is actually a pretty slow process for me: probably a day per icon

These are not insurmountable (I did it for checked baggage) but each service logo & associated database will probably take a week, and I didn't want to delay timetables for it. This is also the reason I don't have a sleeper icon.

The station services are a little faster, since I can get the data automatically, and I was thinking of mostly using letters instead of icons. (And a round filled or half-filled circle, as previously used for staff, is an easy icon.)

But I have to pick a cutoff point somewhere; each day I make design improvements means timetable publication gets delayed by a day. Once I've got a full set up I will go back and work on stuff like that. I figured wheelchair access and checked baggage were the most critical for trip planning.

 

[PaTrainFan]

You pull this huge task off successfully (and none of us here have any doubt of that), you may get RPA's Golden Spike Award!

 

[Ryan]

But I have to pick a cutoff point somewhere; each day I make design improvements means timetable publication gets delayed by a day. Once I've got a full set up I will go back and work on stuff like that. I figured wheelchair access and checked baggage were the most critical for trip planning.

I think that your logic is sound. Let 'em fly, and then work on improvements.

 

[joelkfla]

Did you finish your taxes early?

 

[neroden]

Did you finish your taxes early?

Federal's done, state should be quick.

What actually happened is that last night I couldn't stand to do any more taxes that evening so I took a crack at the program again. Finished off the federal tonight.

 

[neroden]

Of course, the list of possible improvements is essentially infinite.

One of the large, hard problems I've been puzzling over is getting two trains into one column (for connecting services), which isn't trivial at all, and I'm not sure I'll actually achieve that.

A small, hard problem is finding first and last stops printed on each timetable (due to the way I structured the code), to eliminate spurious "R" and "D" codes. I already have all the display code done but the generator doesn't know when it's filling in the cell for the first or last stop! Each cell is simply filled in based on "train number, station code".

A longer-term problem is generalizing the code so it can be used for non-Amtrak agencies. And a really tricky problem is integrating the data from two providers: integrated Surfliner/Metrolink/Coaster timetable, for instance; though I have an idea of how to go about that.

 

[acelafan]

I think your work is amazing. It would be awesome if Amtrak's IT department could take your setup and run with it.

Regardless, I think you should release the timetables to RPA so people can effectively plan travel. Of course I will then add them to my timetable archives for safekeeping. Fantastic job!

PS. Traditionally Amtrak would publish timetables in the spring and fall with the clock changes. I realize GTFS lets you make a timetable whenever you want. However, would it be good if RPA published fresh timetables on some regular schedule, besides known changes for specific trains?

 

[Jack Kittle]

Looking great!

One thought for Ar/Dp - many Amtrak timetables used a column with a combined direction arrow and Ar/Dp field along with a another column for route miles. Value added might be average speed between stations...

 

[dadonatrain]

Sir, this really is amazing work you’ve done. Especially for those of us who still just want something we can read offline, it’s great work.

I’m nearly certain I know the answer to this Q but I’ll ask to be sure. Have you done one yet for the Acela and other trains btwn Washington and Boston?

 

[neroden]

I have not produced NEC timetables yet. We'll see what weird issues arise when I start in on them.

(Actually, an Acela-only timetable should be easy. It's the big NEC timetables, with Springfield services and Virginia services and Regionals and the Crescent and Silver Service and Palmetto and Cardinal, which will have issues.)

I have been working on Empire Service because it had a whole bunch of oddities I had to solve, and I have finally nailed those, I think. I managed to get the "first/last station" thing done in a simplistic and slightly labor-intensive way (they're simply marked in the spec file).

I then sat down to do the Empire Builder and discovered three more idiosyncracies requiring extensive additional coding.

One was the Browning / East Glacier Park situation, the first thing for which I needed to add a timetable-specific text note.

Then there was the way the train splits & joins. So it took me a while, but I *have* got a single column pulling data from two train numbers now (since Amtrak has 8 and 28 recorded as two separate trains). This should let me do connecting services on future timetables.

Third was actually the sheer number of stations; it is third after the NEC and California Coastal Services. The problem this causes is quite simply that the table started running off the end of the 8.5x11 page. It took me several days of trial and error to figure out how to alter the layout to gain the space for it. I will unfortunately probably run into this again when trying to do the NEC and California Coastal timetables.

To implement one of the space savings, I did clean up the days-of-the-week stuff some more.

I'm probably going to run into the problem of timetables which need to be split over multiple pages. Not sure how to wrap those into a PDF yet; my entire design has been based on making single sheets so far. I think I may have to learn CSS Paged Media.

I *did* fix the performance issue, so now it takes about 2 to 5 seconds to generate a whole batch of timetables once the spec files are ready (most of it is the program launch overhead), and I managed to get the batch-invocation interface into a somewhat more acceptable form. I should be able to release the first batch of timetables to RPA next week. I have not quite decided what will be in the first batch.

A preview:

 

[joelkfla]

I nominate SS & TE, being services whose schedule times have changed since the last published timetables.