If this needs code modification, then I would like to know how to get
the code, and how to pack the code into a project WAR file?
Block (assuming this is synonymous with what SEPTA--and TriMet--is
calling Train) and Trip numbers are both available to the templates
that create TTPUB's output HTML files. For example, the TTPUB
'config' screen (http://maps5.trimet.org/ttpub/timetable.config),
lists both of these variables for informational purposes. To get
block information to display in the output HTML, you would simply need
to edit some of the 'templates' that TTPUB uses to produce the html
output. The TTPUB templates all sit in a directory in the war file,
and it's a given that to customize TTPUB, these templates are there to
be edited. Editing templates does not require a recompile or new war
file (and on many app servers, like Tomcat, can be edited in place,
with the results seen immediately). Navigate to where the ttpub.war
file has been unzipped, and find the ttpub/templates/include/
macros.ftl template file. In a text editor, find the simpleTimesTable
macro, to which you will add a new HTML column under the [#list rows
as rw] iterator (should be line #97). For block info, you would be
adding something like <td>${rw.getBlock()?default("")}</td> for the
new row. (Other templates exist for vertical view timetables, as well
as the XML output that goes into Adobe inDesign, etc...).
Now about code changes...you might need to go down that route for two
reasons: 1) PDF output is built using a java library called iText...so
adding new columns to that output requires a code change & recompile;
2) if you need to access data beyond that which is already in the
org.timetablepublisher.table.Row java interface, a few different code
& template changes might be necessary. Both the code (http://
timetablepublisher.googlecode.com/files/ttpub_code-1.5.1.zip) and
build instructions (section 3 of http://timetablepublisher.googlecode.com/files/Developer%20Notes%20v1.1.doc)
exist at timetablepublisher.org.
Good luck,
Frank
Thanks for the reply.
I verified and in SEPTA, we do in fact show train IDs in the block_id
column of trips.txt.
This is good because I could use your suggestion and add block_id data
to the table.
However, the code insertion that you suggested is for a standard
(horizontal) table that uses macros.ftl file to create the table.
In our case we want to:
- Use a vertical table
- Use the following file for HTML creation: templates\gtfs\vert.ftl
and templates\gtfs\webPageMacros.ftl (I found that these are the files
that are used by default. Also, this seems to have some nice features
in it, such as tool tips).
I tried to apply your suggestion to webPageMacros.ftl, but so far
couldn't manage it.
I would appreciate if you could give me a hand with this and show me
how to modify the verticalTimesTable macro to add a line with train
number (block_id) above the vertical schedule table.
Thanks,
Bijan
> build instructions (section 3 ofhttp://timetablepublisher.googlecode.com/files/Developer%20Notes%20v1...)
For train numbers, I recommend using the trip_short_name field, which
was added to the GTFS for exactly that purpose:
http://code.google.com/transit/spec/transit_feed_specification.html#trip_short_name_feed_data
Joe
Here's some FTL code you can try, which will add a table header to the
vertical table. Edit webPageMacros.ftl, #macro verticalTimesTable at
about line 235. Insert this code just after the <tbody> html element:
<tr>
<th scope="col" align="left" valign="top" width="30%">Stop
Info</th>
[#list rows as r]
[#assign trainName = ""]
[#if r?exists]
[#assign trainName = "Train #${r.getBlock()}"]
[/#if]
<th>${trainName}</th>
[/#list]
</tr>
BTW, I have this same change running on the demo site:
http://maps5.trimet.org/ttpub/timetable.print
Take care,
Frank
On Feb 4, 10:08 am, Bijan <mol...@gmail.com> wrote:
On Feb 4, 10:58 am, Joe Hughes <joe.hughes.c...@gmail.com> wrote:
> It's worth noting that block_id is not a human-readable field--that
> is, you shouldn't expect it to be a value that's necessarily
> understandable to a rider.
>
> For train numbers, I recommend using the trip_short_name field, which
> was added to the GTFS for exactly that purpose:http://code.google.com/transit/spec/transit_feed_specification.html#t...
Thanks a million. Your code worked perfectly.
There are 3 more things that we want to insert in our train schedules
(which have vertical layout):
1- We want to be able to add a column on the left of stations column
that will contain a 'Fare Zone' number for each stop. We could use
zone_id field in the stops.txt table to indicate Fare Zone numbers. I
found the getFareZoneID() method in stops.java and thought that a call
to this method should give the zone_id. But I couldn't use it in
FreeMarker. Is there a way to call this method from FreeMarker?
2- We also would like to have another column on the left of stops
column that contains a wheelchair icon if the stop is accessible. We
could use the stop_desc field in stops.txt for this: A value of 1
would mean 'accessible', and 0 would indicate not accessible. Then,
I'll need a method call from FreeMarker to check the value of
stop_desc and based on the value, put a wheelchair icon.
3- Instead of using the bold typeface for pm hours, we would like to
use it for our rush hour trips. At present we are not using
trip_short_name in trips.txt table. I thought we could fill
trip_short_name by 1 to indicate rush hour trip, and 0 otherwise. Then
again, I'll need a method call from FreeMarker to check
trip_short_name to decide to use bold face. Is this possible?
I would appreciate if you could help me in any way.
Thanks,
Bijan
I'm happy to hear that the block (train) number code worked out. The
three additional fields are definitely doable, but they're going to
require some java code changes (so not nearly as simple as block
number). I'm not sure when I could get to implementing these things,
so I'm going to outline places in the code that would need to be
altered. BTW, as I trace through the GTFS code, I've got to say these
changes are touching more source files than I'd like, and it's got me
thinking that I should refactor the code to make changes like this
more straightforward (esp since GTFS has evolved a lot since this code
was written, and is still evolving). Part of the problem is that I
originally wanted to be very strict in the Freemarker presentation
layer regarding the methods available for access, with the tradeoff
that I could reliable make all back end data sources (GTFS or
whatever) look the same, and behave the same.
Anyway, for Fare Zone, the stop data, like everything else available
to Freemarker, needs to come from an objects that conform to
interfaces under the org.timetablepublisher.table namespace -
specifically the, org.timetablepublisher.table.Stop interface (eg: and
it's accompanying class implementation
org.timetablepublisher.table.StopImpl). NOTE: the interfaces under
the org.timetablepublisher.table namespace are an abstraction that
TTPUB uses to make for pluggable backends (one of which is GTFS,
another is a TriMet's internal enterprise database, etc...; but the
playability comes at the cost of multiple code changes in this
instance, and it's here where I think a bit of refactoring would go a
long way). Further, beyond adding the fare-zone getter method to the
org.timetablepublisher.table.Stops interface, changes to the code that
interfaces org.timetablepublisher.table.StopImpl with GTFS (under the
org.timetablepublisher.schedule.gtfs namespace) will be necessary to
get the fare zone value into org.timetablepublisher.table.StopImpl.
It's a similar story in getting wheelchair / accessible data from GTFS
into the org.timetablepublisher.table.Stop interface for Freemarker.
A glance at the code tells me that I'm not currently doing anything
with the GTSF stop_desc field, so it does not (currently) propagate
into any code that the Freemarker template sees. BTW, a bit of a
tangent, but there might be a better field than stop_desc to represent
accessible stops, ala http://groups.google.com/group/gtfs-changes/browse_thread/thread/6caaadd2e1ec9b65
and http://groups.google.com/group/gtfs-changes/browse_thread/thread/1a4f3c41841882dc
Finally, same story for #3...and having a rush hour flag of some sort
from GTFS to org.timetablepublisher.table.Stop. You'd need both the
interface getter, and a way to move that data from GTFS.
At some point, I'd like to find more time to work on this and improve
the GTFS support...but I can't say when that time would be exactly.
That said, I'm here to answer questions where I can. And there might
be others on the list (paid or volunteer) who might be available to
help dig into this...
Take care,
Frank
My alphanumeric character in that field was triggering footnotes
specifically, but may be amenable to the peak hour trigger also.
Tim Sobota
Metro Transit, City of Madison
On Feb 17, 4:51 pm, Frank <fxpurc...@gmail.com> wrote:
> Hi Bijan,
>
> accessible stops, alahttp://groups.google.com/group/gtfs-changes/browse_thread/thread/6caa...
> andhttp://groups.google.com/group/gtfs-changes/browse_thread/thread/1a4f...
> > > > > > the code, and how to pack the code into a project WAR file?- Hide quoted text -
>
> - Show quoted text -
There are several (conflicting) proposals involving a field of that
name, but none have been adopted yet pending the resolution of these
issues.
Joe