Even though EMME/2 does allow coding a two-way transit line as a single line with a stopover separating the two directions, it is in general preferable to code each direction as an independent transit line. This has the advantage that the frequencies of the two directions do not need to be the same (which is often the case during peak hour) and also this way the standard statistics (max. load, no. of boardings, ...) are given by direction. Separate coding of the two directions is mandatory in cases in which passengers will transfer at the first layover node from one direction into the other direction of the same line (this sometime happens for lines which do not follow exactly the same itinerary in both directions).
If the circular line has a normal layover point where the vehicles pause, circular lines can be coded normally, just as any other line. If, however, the circular line operates in a continuous mode, with no layover apparent to the passengers, normal coding would penalize travelers that pass through the layover node, by adding undue boarding and waiting times. In this case, the best solution is to let the circular line start and end at a special dummy node, which is located somewhere inbetween to stops of the line. This node is given a zero boarding time and a zero wait time factor, so that the travelers passing through this node do not incur any transfer penalty. As outlined above, each direction of a circular line should be coded independently, and also use different dummy nodes (otherwise passengers could ``flip'' directions at no cost at the dummy node and this way cheat on the waiting time).
Even though EMME/2 does allow entering transit time function
indices explicitly for turns with the keyword ttft, these
function indices are not used during the assignment.
This is a historic ``leftover'' that will most likely be removed
at some future release. Thus, while it is currently possible to use
this ``sleeping'' attribute to store some additional segment related
data, this should only be done for short term projects -- it is
not guaranteed to work in future releases.
Note that the ttft attributes can not be used for this
purpose (see the previous question).
But since Release 7 this can be done in a much more flexible way using
the turn calculator feature in 2.41 to copy the relevant turn penalties
into a segment user data from where it can then be accessed in the
transit time functions. This allows the inclusion of the turning times at the
I-node (e.g. us1n=ptimau) and/or the J-node (us1=ptimau)
of a transit segment, depending to the exact location of the transit
stops at both nodes.
I do not recommend clipping the headway with a maximum value. When preparing a transit assignment you should not use as source for effective headway the option 2= actual line headways with maximum unless you know exactly what you are doing. At first sight, this option seems an intuitive solution to reduce the waiting time for lines with long headways to reasonable values. But the price for using this method is paid later on when analyzing new scenarios with changes in the line structures or the headways: On the one hand, the assignment is no longer sensitive to any headway changes above the maximum. On the other hand, splitting a line into two alternating lines with different ``antennas'' or turn-around points can lead to inconsistent results, when comparing them to the original scenario.
A more viable alternative for reducing the waiting times is by using node specific wait time factors. While for nodes with a high frequency transit service the standard value of 0.5 is a good choice, a lower value can be used for nodes with an infrequent transit service. While not being an ideal solution either, this approach is preferable to clipping of the frequencies, since it does not lead to the gross inconsistencies when changing headways or splitting lines later on.
For theoretical and technical reasons, the line specific boarding times are actually implemented as ``alighting times'', i.e. they not are added to the impedances at the boarding segment, but at the alighting segment. As the alighting always occurs from the same as was previously boarded to, line specific boarding or alighting times are mathematically equivalent. However, the different position of the line specific ``boarding'' times, compared to node specific or constant boarding times, will change the topological order of the segments, and hence, the order in which they are examined when the optimal strategy is constructed. This implies that ties (ex-aequo situations) will not necessarily be broken in exactly the same manner. Thus, replacing a constant boarding time with line specific boarding times of exactly the same value will not always result in exactly the same assigned transit volumes.
If the demand used for the transit assignment is not based on one hour, it is by far the easiest solution to normalize it to one nominal hour within the period and then use hourly demand matrices for the transit assignment to obtain the usual hourly traffic volumes.
If for some reason it is not desireable to use a one hour assignment period, it is important to note the following:
The standard way of doing a ``select-line'' assignment which is documented in the EMME/2 Users Manual is based on the hypothesis that, within a single trip, the selected line is boarded once at most. Only with this (here very reasonable!) assumption, the maximum operator will produce indeed the desired results. Would the selected line be boarding more than once, the additional options assignment would not retain all trips using the selected line, but only those, using the selected lines for the maximum number of times.
The assumption of a single boarding obviously does not
apply for the general case in which the trips
using one of several lines are to be retained in the additional options
assignment. Thus, a different approach must be used here to perform a
``select-lines'' or ``select-mode'' assignment.
This approach consists in the computation of the complementary trips,
i.e. those trips that do not use any of the selected lines. This corresponds
to the retaining minimum attribute sub-strategy, i.e. to those
trips trips that do exactly 0 boardings to the selected set of
transit lines. In technical terms, this is implemented by an
additional options transit assignment with the following specifications:
- addl. boarding attribute 1 for selected lines, 0 else
- minimum sub-strategies
- .max. or + path operator
- (0,0) threshold
Note that this assignment results in the trips not using any of the specified lines. Thus, in order to obtain the results for those trips using the selected lines, the difference to the full assignment has to be computed. This can either be done explicitly, by using the network calculator and storing the results in some user attributes. Or, with the following little trick, this difference can be obtained directly in the assignment: Assuming that the scenario already contains a full transit assignment (which is usually the case), the above mentionned additional options assignment is not done as a new assignment, but is added to the existing volumes, using a demand matrix which is multiplied by -1 (i.e. effectively subtracting the trips from the total).
Yes, this is possible (even though I am not sure that there is any good reason why one would like to do this). The multi-path feature in the optimal strategy assignment is solely due to the fact that waiting time can be reduced by accepting to ride on non-shortest lines -- if they show up first. Thus, the higher a wait time weight is used, the more the strategy will spread on non-shortest lines, and --at the other end-- with a wait time weight of zero only shortest lines will be used.
Since simply using a wait time weight of zero would lead to an assignment in which the line headways are not reflected at all, it is now necessary to include an additive single-line waiting time into the assignment. This can be done by specifying a line specific boarding time that corresponds to half the line headway.
As the standard EMME/2 transit assignment is a fixed cost assignment, the route choice of one passenger does not influence the route choice of the other passengers. Thus, the assignment of multiple user classes is separable by class and the classes can be assigned sequentially. For this purpose, EMME/2 offers the possibility of ``stacking'' several assignments on top of each other in a single scenario (by using in module 5.11 the option 1= assign more demand on existing transit volumes).