Calendar

Table of contents

  1. Introduction
  2. ​Calednar view
  3. ​ Validity period “from-to” fields 
  4.  Calendar template selector 
  5. ​ Day selector (monthly, weekly, daily) 
  6. ​ Validation messages
  7. ​ Calendar Legend 
  8. ​ Apply to (Copy function)
  9.  Calendar tooltip 
  10. ​ Calendar acts as a switch
  11. ​ Empty calendar 

1. Introduction 

This document describes what can be done in the calendar step. 

This is the second step in the creation flow, where users can add and plan the running days for each path request when creating the reference trains on their territory.

The calendar is available for the path request level. Locations, territories, path requests and their details cannot be added or edited in this step.

2. Calendar view

The following elements are shown in the calendar view: 

  • Validity period “from-to” fields 
  • Calendar template selector 
  • Day selector (monthly, weekly, daily) 
  • Validation messages 
  • Calendar Legend 
  • Apply to (Copy function) 
  • Calendar tooltip 
  • Calendar acts as a switch 
  • Empty calendar 

On the calendar view, users can identify which path request the requested days will be applied to. Move on the sidebar between the territories or among the territories to apply the running days to all. 

3. Validity period (“from” to “to”) 

By default, the validity period is set to the whole timetable period. Users can manually change it if they want by entering their own “from-to” values, but they can do it only within the timetable period and the “to” date must be later than the from date. Days that cannot be selected are disabled in the selector and shown in grey colour.  

After the definition of the validity period, you need to define the running days for the paths.  

We advise you not to apply the calendar validity period manually by typing the date in; use the calendar icon to enter the date properly. 

4. Calendar template selector

A template of selected days can be imported into the calendar. After the import, the calendar days can be further manually modified. There will be no connection between the calendar and the used calendar template; the days from the template are copied over.  

5. Day selector (monthly, weekly, daily) 

You have several possibilities to select/deselect the days by: 

  • Monthly
  • Weekly circulation days 
  • Individually  
  • All 
  • Range

Let’s check all the options above in detail below. 

5.1 Monthly

Users can select/deselect all days in the month within the validity period by clicking to the name of the month.

5.2 Weekly circulation days

The days of the week are marked with numbers (1 – 7) for the defined period.  These buttons do not change colour when used.

If users want to select or deselect every Monday, they need to click on the “1” symbol,  

Or Friday by clicking the number “5”, and so on.  

5.3 Individually

Users can select/deselect individual days within the validity period.

5.4 Select all

Users can select/deselect all days within the validity period.

5.5 Range selection

Users need to press the Shift + select (click with the mouse) to select ranges. 

6. Validation messages 

Validation for missing days and inconsistencies is displayed. For the possible validation error and warning messages, see the validation messages document. 

7. Calendar legend 

Different colours are used in the calendar to describe the state of the days marked in the calendar compared to other path requests. The comparison goes from top to bottom. 

The following are indicated: 

  • Covered in the current path request: days that are marked in the current path request within the territory 
  • Covered in another path request in this territory: days that are marked in another path request within the territory  

See an example, for the above, both use cases, on Infrabel PR1 the train runs in January and on Infrabel PR2 it runs in February if Infrabel PR 1 is selected then the view shows the following: 

  • Missing running days from this territory: days that are not covered in this territory, but covered in the previous territory. 
  • Covered in previous territory: days that are covered in the current territory and covered in the previous territory. 

See an example of the last two options if there are two path requests on the next territory where only the first path request has an empty calendar. See the calendar legend description: 

  • Not covered in previous territory: days that are covered in the current territory, but not in the previous territory. 

See an example, if the days are not covered in the previous territory, continue the example above one day added to the Prorail PR2 as an extra day which does not exist in the previous territory: 

8. Apply to

After a calendar is set up for a path request, the same running days can be applied to all or some path requests to each territory (the originating territory cannot be selected).  

By default, the first path request without a calendar within each territory is preselected, but the users can change the selection. In the screenshot, the Infrabel PR2 is selected to copy the calendar over to Prorail PR2. 

If a path request calendar is copied to a path request calendar that already has data, it can be overwritten. Users need to confirm their action to complete the copy.

When applying the calendar to the other path requests, if there are offsets in the base path request, the offset is considered. When the midnight crossing is detected between the path requests the calendar offset is also applied.  

9. Calendar tooltip 

If any calendar days are set for a path request, the tooltip calendar is available in the sidebar, showing the days and months of the year, where at least one day is covered: 

If the user hovers over this, an overview calendar opens, showing the PR calendar for the whole year. 

10. Calendar acts as a switch 

A day cannot be double-booked in the calendar. The calendar works as a switch if a day is selected in a new path request that is already covered in another, then that day is taken out of the calendar of the other path request. 

11. Empty calendar 

The “Next” will let you proceed further with an empty calendar, but it is recommended not to proceed with an empty calendar.  

The system warns you in later steps (open, harmonization) if the reference train is not in drafted state at exiting the edit mode once if you want to create your reference train with an empty calendar: 

To create a reference train, users should define the running days for each path request. When users are ready, they can continue their work by clicking “Next” to apply the network-specific parameters in the draft state.