The operating calendar is managed in the Configurations window.
It contains and manages different patterns of operating days for different trains in the timetable scenario, for example "daily", "Monday to Friday", "only 05/04/" or "not on holidays".
Define new pattern in the list by clicking on the + symbol. Select a suitable name which will act as identifier in the timetabling process and select the relevant active days. It is possible to combine regular days, special days and holiday deviances. It is also possible to deselect special days from a list of regular days.
Check the selected active days in the calendar view with the following colouring scheme:
- Red days - outside timetable validity period
- Yellow days - not active
- Green days - active
Apart from a standardised Operating calendar it is also possible to select a Custom calendar on the train level. In the Custom calendar single days can be activated, or by click and wish a user-defined period selected. In the ustom calednar it is also possible to deselect single days in a pariod where the train otherwise would be active all days.
How to use the Operating Calendar
The Operating Calendar follows the RailML logic of operatingPeriods. This allows for very flexible definition of precise Operating Calendars, but it also requires a more profound understanding of how different concepts work together. To create refined Operating Calendars in trenoLive, we suggest to read the following in-depth explation as cited from the RailML website.
General Information on Date References, Validity Periods, and Holidays
When exchanging concrete timetables, the timetable data contained in a RailML file usually also includes a date reference. The date reference is created in the element timetablePeriod and optionally in the elements operatingPeriod.
Typically, a timetablePeriod element contains:
- The beginning and end of the validity period in the attributes startDate and endDate,
- An optional list of holidays within the validity period.
- Representation of Special Operating Day Rules without Date Reference
In the simplest case, only the existing timetablePeriod element contains a date reference via startDate + endDate and possibly also via holidays. The operatingPeriod elements can, without specifying an exact date, reference arbitrary weekdays within the validity period (see following examples).
The specification of holidays is the reference basis for the sub-elements operatingDayDeviance of the operatingPeriod elements. Therefore, the elements holidays and operatingDayDeviance only make sense when used together. If no operatingDayDeviance elements are given, holidays would not be evaluated. However, it is still conceivable to state holidays merely for completeness.
A RailML file can, but does not have to, contain a validity period. A RailML file may also include multiple validity periods, but each operatingPeriod, and therefore each train or train section, can only refer to one validity period at a time.
RailML files without a validity period either do not have a timetablePeriod element at all, or only have timetablePeriod elements without startDate + endDate. If no validity period is defined, the operatingPeriod elements must also not contain the attributes startDate, endDate, bitMask, or the sub-element specialService.
startDate and endDate may only be specified together, never individually. That means there must be no “open” periods. The difference between startDate and endDate defines the length of the bitmasks (bitMask attribute) of the operatingPeriod elements.
Representation of Special Operating Day Rules without Date Reference
Operating day rules (seasonal rules) are coded in the RailML element timetable.operatingPeriods. In such an operating rule (operatingPeriod), the individual days are coded in two redundant ways:
- In the attribute bitMask across the entire period, and
- In the sub-elements operatingDay and specialService, broken down according to the exact user input into regular and special operating days.
The reason for this duplication is that although the bitmask is technically easy to process, it cannot be uniquely converted back into the original user input. (That is, multiple inputs can lead to the same bitmask.) For some applications, it is important to transmit the information exactly as the user entered it. Moreover, it can be relatively complex to separate regular and special operating days from a bitmask (for example, reconstructing the input “Mon–Sat, except 24.12. and 31.12.; also 17.11.” might require correlation analysis).
The description with operatingDay elements is especially important when, for example, “strategic” (long-term) timetables are used where no validity period is defined (no timetablePeriod or without startDate + endDate; see previous section).
The operatingDay element contains a sub-element operatingDayDeviance, whose meaning will be explained with the following examples:
In general, operatingDayDeviance indicates that the operating rule deviates from operatingCode, i.e. runs or does not run, when a weekday has a certain relation (offset) to a holiday. The attribute ranking defines which operatingDayDeviance applies if several are valid at the same time. For example, in Germany, 25.12. is both a holiday and a day before a holiday.
Example 1 Rule: W[Sa] = Mon–Fri, but not on holidays
<operatingPeriod id='…' name='W[Sa]' …>
<operatingDay operatingCode='1111100'>
<operatingDayDeviance operatingCode='0000000' holidayOffset='0'/>
</operatingDay>
</operatingPeriod>
Explanation: operatingCode='1111100' means it operates Monday to Friday. operatingCode='0000000' holidayOffset='0' means it does not operate on days that fall on a holiday (offset = 0)
Example 2 Rule: S = Sundays and all public holidays
<operatingPeriod id='…' name='S' …>
<operatingDay operatingCode='0000001'>
<operatingDayDeviance operatingCode='1111111' holidayOffset='0'/>
</operatingDay>
</operatingPeriod>
Explanation: operatingCode='0000001' → runs only on Sundays. operatingCode='1111111' holidayOffset='0' → additionally runs on all holidays
Example 3 Rule: vS = Working days before Sundays and holidays
<operatingPeriod id='…' name='vS' …>
<operatingDay operatingCode='0000010'>
<operatingDayDeviance operatingCode='1111110' holidayOffset='-1' ranking='2'/>
<operatingDayDeviance operatingCode='0000000' holidayOffset='0' ranking='1'/>
</operatingDay>
</operatingPeriod>
Explanation: operatingCode='0000010' → runs on Saturdays (= before Sundays). operatingCode='1111110' holidayOffset='-1' → also runs on Mon–Sat if the day falls one day before a holiday. operatingCode='0000000' holidayOffset='0' → does not run on holidays.
If a day is both a holiday and the day before a holiday (e.g., 25.12.), the rule does not run, since the holidayOffset=0 entry applies (lower ranking wins). Interpretation:
- Runs on Saturdays,
- Mon–Sat before a holiday,
- but not on holidays.
Representation of Special Operating Day Rules with Date Reference
This section covers cases such as “does not run on 24 and 31 December” or “only from 01 July to 31 August”. The prerequisite is that a related validity period (timetablePeriod with startDate + endDate) is defined.
For these cases, the following additional elements and attributes can be used:
- startDate + endDate attributes of the operatingDay element,
- specialService sub-elements of the operatingPeriod element.
The attributes startDate and endDate in operatingDay restrict the application of the operating rule of the operatingDay element to this date range. Both must always be used together and may only refer to days within the validity period of the timetablePeriod.
The element specialService is a list of exception days on which the rules defined by the operatingDay elements are overridden. The attribute type is used with the following values:
- include → additional operating days,
- exclude → non-operating days.
The attributes startDate and endDate define the first and last day of the exception. They must always be used together and may only refer to days within the timetable period. If it is only a single day, the attribute singleDate is used instead of startDate + endDate.
Example 1 Runs only from 14.12. to 28.12.
<operatingPeriod id='…' name='only 14.12.–28.12.' timetablePeriodRef='ttp_2020_21'
bitMask='011111111111111100000…000'>
<operatingDay operatingCode='1111111' startDate='2020-12-14' endDate='2020-12-28'/>
</operatingPeriod>
Example 2 Runs daily, except on 25.12. and 01.01.
<operatingPeriods>
<operatingPeriod id='…' name='daily; not 25.12.; not 1.1.'
timetablePeriodRef='ttp_2020_21'
bitMask='11111111111101111110111…111'>
<operatingDay operatingCode='1111111' startDate='2020-12-13' endDate='2021-12-11'/>
<specialService type='exclude' singleDate='2020-12-25'/>
<specialService type='exclude' singleDate='2021-01-01'/>
</operatingPeriod>
</operatingPeriods>
If multiple operatingDay elements appear within an operatingPeriod, they must always be disjoint — either by their startDate–endDate ranges or by their operatingCode bitmasks.
Additional Notes on Special Operating Day Rules
The handling of exceptions with specialService enables a very fine-grained definition of traffic days. However, some restrictions must be observed:
- The specification of startDate and endDate is only permitted together, never individually. “Open-ended” exceptions are not allowed.
- If multiple exceptions apply to the same day, the sequence in the XML file is irrelevant; they must not contradict each other.
- Exceptions must always refer to days within the validity of the timetablePeriod to which the operatingPeriod belongs.
The combination of operatingDay rules and specialService lists allows nearly any operating pattern to be represented.