Changed writing of GTFS stop_times.txt file so that stop IDs are left
padded so that they are at least 5 characters long. This way the
resulting data in the files will line up better and will be easier to
review. Also made stop_sequence, number_arrivals, and number_departures
at least two characters.
Added method padWithBlanks() so can create cleaner stop_times.txt GTFS
files.
Changed writing of GTFS stop_times.txt file so that stop IDs are left
padded so that they are at least 5 characters long. This way the
resulting data in the files will line up better and will be easier to
review. Also made stop_sequence, number_arrivals, and number_departures
at least two characters.
Added method getDayOfYear(Date epochDate) for use with processing
arrivals/departures and creating updated GTFS stop_times.txt files.
Added getTripStartTime() but realizing that trip start time might not be
needed at all because it is just the scheduled trip start time but for
dealing with frequency based service need actual measured trip start
time. Therefore might take out tripStartTime from this class in future.
Moved the optional schedule adherence info to end of toString() so that
arrivals & departures in log file will line up better, making it easier
to debug.
Added oneDigitFormat().
Added threeDigitFormat(double arg)
Cleaned up a bit more to make output of GTFS stop_times cleaner.
Many changes. Still not complete but checking in file now that it is
working pretty well.
Made a complicated change to getGtfsStopTimes() to sort the stop times
so that they are in close to the same order as originally, but such that
the trip are not spread out and so that the stop sequences are in proper
order. But the implementation is complicated and really slow. Therefore
checking it in for posterity but will instead change to using a regular
sort. This means the resulting stop_times will be in a very different
order than originally, but the solution is much faster or simpler.
Changed so that when use
-Dtransitime.core.onlyNeedArrivalDepartures=true then processing of
batch data can be sped up (haven't measured difference) by not
generating predictions and not logging nor storing in db AVL reports or
matches.
Fixed typo in END_OF_BLOCK string.
Improved toString() to also include length of vector. Handy for
debugging.
Fixed vehicleHeadingInDirectionOfTrip(). Was wrongly returning when
previous AVL report matched to layover. This is important because will
always match to a layover since heading and distance to route don't
matter for layovers. Such a lenient match doesn't tell you anything
about direction of travel. So the method should return false for that
case.
Changed batchSize for reading in arrivals/departures from db from
6500000 back down to 500000, which uses less memory and should be
adequate.

Also, fixed how stop_times are ordered. Now using regular sort() method,
which is fast. Downside is that the resulting stop_times file that is
created will have a different ordering than the original if there were
some out of sequence rows in the original.
Fixed to use the proper schedule time for the beginning of the trip even
if frequencies are used for the trip. Also, change the max speed for the
vehicles so that if there is problem with schedule data the travel times
will be more reasonable. Before the travel speed was way to fast.
Made maxStopsWhenNoPreviousMatch and maxStopsBetweenMatches configurable
parameters. Changed the default of maxStopsWhenNoPreviousMatch from 6 to
4 since it can lead to arrivals/departures being duplicated if vehicle
becomes unpredictable and gets rematched again. For Zhengzhou an even
lower level is better since it vehicles report frequencly and should
therefore be matched pretty quickly.
Attempting to make sure that a vehicle doesn't generate previous
arrivals/departures when it is matched to the same assignment again
after becomming unpredictable. This is to prevent situation where
vehicle becomes unpredictable due to timeout, not matching to route, or
whatever, and then getting assigned again. For this case don't want to
generate previous arrivals/departures for the beginning of the block
because they were already generated. 

Still needs to be tested by looking for the log message "in theory
could" from line 311 of ArrivalDeparureGeneratorDefaultImpl.

Note: need to go over this code more. I believe it could be cleaned up
by making it more clear when the previous block assignment is set and
cleared.
Fixed type