Notes on imported railML® data

From the following railML® subschemas, elements are adopted into Visum:

  • Infrastructure
  • RollingStock
  • Timetable

Below it is explained which elements of the individual subschemas are imported and how the course is determined in Visum based on the railML® data.

Allocation of Operation Control Points to stop points

From the 'Infrastructure' subschema only the 'OperationControlPoints' (OCPs) element is taken. It contains the OCPs used in the timetable. In Visum OCPs are modeled as stop points. For this purpose, the OCP ID and the selected OCP matching attribute are read for each entry and a search is made for this attribute value in the values of the stop point matching attribute. All corresponding stop points are checked further. If the value does not exist, the OCP cannot be allocated and will be listed in the log file and in the message window. Normally only part of the OCPs exist in the Visum target network. The import fails if an OCP cannot be allocated. However, a warning will be displayed which allows aborting the import process if an OCP which is relevant with regard to traffic cannot be allocated. An OCP is considered relevant concerning traffic if its 'propService' element is specified and the 'passenger' attribute is true.

If the target network has several stop points with a matching attribute value, the exact allocation can depend on the track information. If the use of track information within an OCP has been switched off or if the stop points in the matching attribute for track information contain the same values, Visum will try to select one of the eligible stops, provided that both of the adjacent OCPs can be assigned uniquely using a shortest path search. OCPs with ambiguous stop assignments are listed in the log file.

An import in case of non-allocated, relevant OCPs may lead to a loss of stops for the vehicle journeys concerned or to their split-up into several journeys.

Even 'trainPart' elements with only one OCP assigned in the target network can be imported if they occur in the context of 'commercial trains' whose route course includes at least two valid OCPs in total and thus the corresponding 'trainPart' elements are extended by other 'trainParts'.

Identification of vehicles (from RollingStock)

From this subschema, the vehicles ('formation ID') are transferred.

For vehicle journey sections, you can store a text in an attribute to be specified that represents the "formation"(Attributes for timetable data tab) This text provides the "vehicles" specified at the "formation". If the railML® attributes for "vehicle" are specified in the railML® file, description is output as text, otherwise name. If this is also not specified, the id is output.

Optionally, vehicle data can also be imported from the subschemas "vehicles" and "formations". “Vehicles" become vehicle units and "formations" become vehicle combinations. The vehicle combination referenced in the ‘trainPart’ (from which the vehicle journey section was created) is then set at the vehicle journey section (railML attribute "formationRef").

Identifying vehicle journeys

Vehicle journeys and the related objects of the line hierarchy in Visum are generated for the 'train' elements of the railML® data stock. These 'train' elements themselves do not comprise any information on the course but contain so-called 'trainPart' elements. These carry information on the course and the times as well as - optionally - on the valid day, on the vehicles, the operator, the line and the category. Hereby, a 'train' element contains 1 to n 'trainPartSequence' elements with a reference to 1 to n 'trainPartSequence' elements. Each 'trainPartSequence' element represents one local section, the 'trainPart' elements displayed herein are vehicle groups/train parts that jointly cover this section. Accordingly, the 'ocptts', i.e. the details of place and time of the 'trainParts' occurring together in a 'trainPartSequence' element, have to match.

This structure allows two different views on the same data. They are realized by trains of the 'operational' type as well as by those of the 'commercial' type. A train of the 'operational' type describes the network view, according to which there can only be one train at each time and at each place. If several train parts are operating together (coupling, destination coaches etc.), there is only one operational train that combines several 'trainParts' on this local section – i.e. in this 'trainPartSequence'.

Commercial trains

The commercial train describes the traffic view. Hereby each vehicle group takes a defined path, possibly stretching over several train numbers. Therefore, jointly operating vehicle groups are in separate commercial trains.

In Visum each ‘commercial train’ becomes one or several vehicle journeys.

The course of a vehicle journey, i.e. the data of its line route and its time profile, result section per section from the course data of the integrated 'trainPart' elements. Hereby, the 'trainParts' become vehicle journey sections in Visum - apart from a few exceptional cases.

The data of a vehicle journey are determined from a 'train' element of 'commercial' type by processing the 'trainPartSequence' entries one after the other as follows:

  • First of all, such 'trainParts' whose 'category' cannot be found in the categories to be read are filtered out. Furthermore, all 'trainParts' whose valid day does not operate in the given filter period are ignored.
  • If the 'trainPartSequence' is not empty and if there has not been a course so far, the transport system of the vehicle journey is determined to be the transport system allocated to the railML®' category' to which the 'trainPart' element belongs.
  • If there is a course from previous 'trainPartSequences', it will be checked whether the transport system allocated to the category of the 'trainPart' matches that of the vehicle journey. If not, a new vehicle journey is created. The vehicle journeys are connected by means of a passenger trip chain.
  • If the 'trainPartSequence' of the 'train' is empty after the filtering, it will be ignored. If there has already been a non-empty 'trainPartSequence' for the current trip (i.e. the trip has already a non-empty course), a new trip will be created. This means that the same commercial train may generate several trips.
  • If the 'trainPartSequence' is not empty, the course for the first 'trainPart' element found is calculated (the courses of the other 'trainParts' have to be matching).
  • For that purpose, each OCP occurring on the course (represented by an 'ocptt' element) is allocated to a stop point in Visum. This is achieved by comparing the contents of the matching attribute on the source (railML® data) and on the target side (Visum stop point attribute). If there are several possible stop points and track information is used, the stop point that lists the specified track information in its second matching attribute is used. If an OCP cannot be allocated, it will be deleted from the course.
  • Arrival and departure times are taken from the ‘times’ elements which are arranged under the ‘ocptt’ elements. ‘Times’ elements can occur multiple times yet with a different ‘scope’. For the determination of the times the 'scopes' are evaluated: The following 'scopes' are possible:
  • published
  • scheduled
  • calculated
  • actual
  • earliest
  • latest
  • userdefined (in railML© any number of user-defined ‘scopes’ can occur, these are combined in one scope type “user-defined” in Visum.)

    • You can define the priority of the 'scopes' for the evaluation. If no matching ‘times’ element can be found (because, for example, no such element exists), the stop point has no times, i.e. in Visum only a route point is created for the stop point, yet no time profile point. If only one time value exists (usually the departure), this value is used for the arrival and the departure.

  • If link information is used, too, links with the specified link number and direction (in the sense of timetable links, not Visum link numbers) starting from each stop point of the course are searched, thus clearly determining the path to the subsequent stop point. If no matching links can be found, a shortest path search to the subsequent stop point will be started in the target network.
  • If the import does not use link information, a shortest path search from each stop point to its successor on the course will be started.
  • In each case, the paths found between the stop points form the line route.
  • From each 'trainPart' element of a 'trainPartSequence’, one or several vehicle journey sections may be created. For vehicle journey sections, you can store a text in an attribute to be specified, which represents the "formation". This text provides the "vehicles" specified at the "formation". If the railML® attributes for "vehicle" are specified in the railML® file, description is output as text, otherwise name. If this is also not specified, the id is output. Optionally, vehicle information can also be read from the railML® data 'vehicles' and 'formations'. In the process, 'vehicles' become vehicle units, and 'formations' become vehicle combinations. Exactly one 'formation' is referenced at each vehicle journey section.
  • Normally each of the journey sections stretches over exactly that part of the course originating from this 'trainPartSequence' and is provided with the valid day of the 'trainPart' element.
  • The case in which the change from one 'trainPartSequence' to the subsequent one coincides with a passing ('ocptt' of type 'pass') is an exception. In the Visum data model, a vehicle journey section can start or end only at a stop. Therefore, in this case, the vehicle journey sections cover the change of 'trainPartSequence' connected to a passing. This generates data distortions if the train ('formation') or the valid day changes here. But it has to be considered a data error in the input data.
  • The ‘ocptt’ element has an attribute ‘ocpType’. It can have the characteristics begin, end, stop, or pass. The ocpType pass indicates a pass through at the stop point considered. A pass through can also be provided with ‘times’ elements.
  • For the import to Visum the times at the time profile points must be monotonously ascending. Run times at ‘ocptt’ elements with different scopes can have different values. This can cause conflicts between successive ‘ocptt’ elements. If a pass through point (‘‚ocptt’ element with ocpType pass) causes a conflict, it will not be imported as a time profile point but only as a route point (and therefore without times).

If a vehicle journey including its sections is created that way, the vehicle journey sections which do not overlap locally but have the same valid day and identical vehicle (and other) information are aggregated.

Operational trains

‘Train’ elements of the type operational are not read in as vehicle journeys railML attributes, which are indicated at 'operational trains', can be taken over into user-defined attributes at vehicle journey sections. There is exactly one operational train for a vehicle journey section that contains the 'trainPart' from which the vehicle journey section originated. If a 'trainPart' is bound in several operational trains, the data of the operational train is transferred with the smaller alphanumeric key (ID of the train).

If you want to evaluate the attributes of an operational train, in Visum, you can use the relations of the vehicle journey to access its vehicle journey sections and aggregate them with the desired aggregation function.

Note: You can enter the number of calendar days a vehicle journey section is served, then output the data to a Visum attribute in order to perform projection calculations. To do this, allocate the desired target attribute to TrainPart_NumValidDays on the Attributes for timetable data tab of the RailML import window or create a user-defined attribute(Importing RailML® data).
Identifying couplings

A coupling in Visum is created when two or more 'trainPart' elements from different 'commercial trains' operate jointly in one 'operational train', i.e. which is in the same 'trainPartSequence'. This means that the 'operational trains' are read and checked for such 'trainPartSequence' elements. For each 'trainPartSequence' containing 'trainPart' elements belonging to different 'commercial trains' found a coupling is generated for the part of the course it describes. If the same 'trainPart' is used in two 'commercial trains', a coupling is also created.

Example for filtering the categories

Filtering the categories is useful to cut off usually undesired sequences before and after the actual train course in Visum. A typical train course of an IC from Hamburg, for example, does not start in Altona but begins as an empty coaching stock from Langenfelde to Altona. In railML® this is displayed as a separate ’trainPart‘ with a separate ‘trainPartSequence‘ and is normally filtered out, so that in Visum the vehicle journey then actually starts in Hamburg-Altona with the IC product and not with the empty coaching stock.

Determining line block data

Visum line blocks are created from the railML® attributes and subordinate elements of the “rostering” element. They are then added to the line block version specified. Several line blocks can be created for each 'rostering' element. The railML® file contains the subordinate elements 'blockParts', 'blocks' and 'circulations' of the railML® 'rostering'. Specifying 'circulations' is optional, but data import to Visum can only be done if 'blockParts', 'blocks’, and 'circulations' are available.

The 'blockParts' elements roughly correspond to the block items in Visum. They contain no information on the position in the line block but only a time. Each ‘blockPart’ element includes the 'mission' attribute. The following types are available:

  • Vehicle journey as a reference to a train part: mission=timetable corresponds to the line block item type vehicle journey in Visum. The 'blockPart' element must contain a trainPartRef attribute.
  • Trip without reference to a train part: mission=fullRun or emptyRun corresponds to the line block item empty trip in Visum.
  • Service that is not a trip: e. g. maintenance, refueling

Activities other than timetable and empty trip (all “missions” that do not correspond to the value timetable, fullRun or emptyRun) are imported as user-defined line block item types.

The ’block' element describes all information for a 'vehicle service' and defines any sequence ('blockPartSequence' elements) of activities ('blockPart' elements). It most likely corresponds to a display level of the Line block view or just a part of it. The activities in this sequence are performed one after the other, possibly on several days of the calendar. The 'blockGroupNumber' does not influence the representation in Visum.

In the 'blockPartSequence' element, the 'blockParts' referenced are grouped to a “service” as single tasks. For this purpose, their chronological sequence including preparation and post-processing times is determined. Several 'blockPart' elements can be referenced within a ’blockPartSequence'. If this is the case, the times specified in the 'blockParts' determine the chronological order of the 'blockParts'.

In 'circulation' elements, "services" (blocks) are concatenated to a line block schedule and specify on which valid days which 'block' is used and which 'block' follows it.

In the railML® line block data, vehicle data can be referenced in both the ‘rostering’ element and the ‘blockPart’ element via the railML attributes ‘formationRef’ or ‘vehicleRef’. If the import is done without vehicle data, no vehicle combination is set at the line block. If the import is done with vehicle data and the ‘formationRef’ is set in the railML® line block data, each line block is assigned the vehicle combination that corresponds to the ‘formation ID’ specified in the ‘formationRef’. If the import is done with vehicle data and the ‘vehicleRef’ is set in the railML® line block data, an additional vehicle combination is created, which consists only of the referenced vehicle unit and is identified in the name by a preceding "railML-vehicle-".

Regardless of whether you import vehicle data, you can store a text representing ‘formation’ or ‘vehicle’ in an attribute for line blocks (tab Attributes for blocks , information ‘Rostering_Formation’, ‘Rostering_Vehicle’, ‘BlockPart_Formation’, ‘BlockPart_Vehicle’). This text is provided by the railML® attribute "name" specified at ‘formation’ or ‘vehicle’. If "name" is not available, the railML® attribute "code" is used.

Optionally, only line block data without timetable data can be imported. The line block information is assigned to existing vehicle journey sections during import.