Import and export of paths use a uniform data format which is binary due to the huge amount of data.
Since the assignment is carried out per OD pair, the connection files have to be structured in the same way, that is, all connections of the same relation have to be read or written in one go, ordered according to zone numbers.
As soon as the size of the connection file exceeds the given size limit, another connection file is created. The size limit ensures that even a connection export including a huge number of paths (> 4 GB) can be read in later.
A connection file contains the following data in the following order:
1. A version number is written, which later allows the format to be modified
2. Number of path files so that Visum identifies when re-importing whether or which additional files need to be searched for
3. Indication on whether the file contains the number of fare points at the path leg
4. Level of fare data contained in the file (0 = no fares)
5. Indication on whether the file contains fares for all demand segments
6. Indication on whether the file contains connector nodes
7. Indication on whether the file contains volumes Number and codes of the assigned demand segments for future allocation of volumes and fares when reading them in again. If you import connections without volumes and fares per demand segment, no demand segments are saved and their number is set to 0.
8. The keys of all public transport systems, the PrT transport system for DRT travel times and time profiles of the network in sorted order. Thus, later (generally numerous) references to public transport systems of time profiles no longer require the output of the complete key string, but the index can be used instead. Important is the congruence of public transport systems and time profiles in the network and the connection file. The term PuT transport systems comprises all PuT line TSys, PuT Walk TSys, PuT Aux Tsys, and Sharing TSys.
9. Definition of user-defined attributes on PuT paths
10. All connections are stored separately per OD pair.
- Each connection consists of several PuT path legs.
- Pure walk link connections only have zero PuT path legs.
- A path leg is either of type PuT-Line or PuT-Aux. In the first case it connects time profile items, in the second case nodes.
Example: Connection file in binary data format
BinaryVersionNo (4 byte-integer)
scConnectionFileIdentifier = „ConnectionFile“ (string)
NumberOfFiles (4 byte-integer)
ContainsFarePoints (1 byte-integer)
LevelOfFareInformation (1 byte-integer)//value in {0,1,2}FaresForEachDemandSegment (1 byte-integer)
ContainsConnectorNodes (1 byte-integer)
ContainesVolumes (1 byte-integer)
NumDemandSegments (4 byte-integer)
for each contained DemandSegment in key order:
{..DemandSegment.Code (string)
}
NumPuTTSys (+ 1 for DRT travel time TSys) (4 byte-integer)
for each contained PuTTSys in key order:
{..TSys.Code (string)
}
DRT-travel-time-TSys.Code (string)
NumTimeProfiles (4 byte-integer)
for each contained TimeProfile in key order:
{..Line.Name (string)
..LineRoute.Name (string)
..Direction.Code (string)
..TimeProfile.Name (string)
}
NumUserDefinedAttributes (4 byte-integer)
for each contained UserDefinedAttribute:
{..ID (string)
..ShortName (string)
..LongName (string)
..Comment (string)
..ValueType (4 byte-integer)
..HasDefaultValue (1 byte-integer)
..DefaultValue (8 byte-real)
..MinimumValue (8 byte-real)
..MaximumValue (8 byte-real)
..NumDecPlaces (4 byte-integer)
..MaxStringLength (4 byte-integer)
..DefaultStringValue (string)
}
for each contained OD relation in key order:
{..SourceZoneNo (4 byte-integer)
..DestZoneNo (4 byte-integer)
..for each contained Connection:
..{....ConnectionDepartureTime (4 byte-integer)
....NumLegs (1 byte-integer)
....for each contained ConnectionLeg in logical order:
....{......DepartureTime (4 byte-integer)
......LegType (1 byte-integer)
........if LegType == 1 // 1st case, leg is of type PuTLine
......{........TimeProfileIndex (see above) (4 byte-integer)
........FromTimeProfileItem.Index (2 byte-integer)
........ToTimeProfileItem.Index (2 byte-integer)
........LegIsPassengerTripChain (1-byte-integer)
........IsHeadwayBased (1-byte-integer)
......}
......else if LegType == 0 // 2nd case, leg is of type PuTAux
......{........TSysIndex (see above) (4 byte-integer)
........FromNodeNo (4 byte-integer)
........ToNodeNo (4 byte-integer)
......}
......else if LegType == 2 // 3rd case, leg is of type Sharing
......{........TSysIndex (see above) (4 byte-integer)
........FromIsZone (1 byte-integer)
........FromNo (4 byte-integer) // number of sharing station or zone
........ToIsZone (1 byte-integer)
........ToNo (4 byte-integer) // number of sharing station or zone
......}
......else if LegType == 3 // 4th case, leg is of type DRT
......{
........TSysIndex (see above) (4 byte-integer)
........FromNodeNo (4 byte-integer)
........ToNodeNo (4 byte-integer)
........DRTDetourFactor (8 byte-real)
........DRTWaitTime (4 byte-integer)
......}
......if ContainsFarePoints (4 byte-integer)
......{........NumFarePoints (4 byte-integer)
......}
......if LevelOfFareInformation = 2
......{........if(FaresForEachDemandSegment)
........{..........for each contained DemandSegment in key order:
..........{............LegFare (8 byte-double)
..........}
........}
........else
........{..........LegFare (8 byte-real)
........}
......}
....}
....for each contained DemandSegment in key order:
....{......Volume (8 byte-double)
....}
....if LevelOfFareInformation = 1
....{......if(FaresForEachDemandSegment)
......{........for each contained DemandSegment in key order:
.........{
..........ConnectionFare (8 byte-double)
........}
......}
......else
......{
........ConnectionFare (8 byte-real)
......}
......if ContainsConnectorNodes
......{
........FromNodeNo (4 byte-integer)
........ToNodeNo (4 byte-integer)
......}
......for each contained UserDefinedAttribute:
.......{
........HasValue (1 byte-integer)
........if HasValue
........{
..........Value (1 byte-integer/4 byte-integer/8 byte-double/string)
........}
......}
....}
..}
..-1 (4 byte-integer)
}
-1
With regard to semantics the following has to be taken into account.
- If transfer walk links are used between two PuT path legs, these are not contained in the file. They result from the beginning and end of the path (zone or stop area) and the TSysSet of the assignment.
- In contrast to the internal connection search it will not be checked whether the PuT vehicle journey sections used in the connections read from file are active.
With regard to the exact format the following has to be considered:
- The Intel order ("Little Endian") has to be kept.
- There is no alignment, which means 4+1+2 bytes are actually exported as 7 bytes.
- Strings are written as follows:
- Length as 2-byte integer
- Signs as sequence of characters (each 1 byte)
For user-defined attributes the following applies:
- The attribute values of a connection are saved in the same sequence as the attributes are defined in the header.
- The values permitted for ValueType correspond to those listed in the COM documentation (cf. in the Online COM help > Enumerations > EnumValueType Enumeration). Formula attributes must not be defined in the connection file. The corresponding data types are listed in the table below.
|
Identifier |
Numeric value |
Data type |
|
ValueType_Int |
1 |
4 byte-integer |
|
ValueType_Real |
2 |
8 byte-double |
|
ValueType_String |
5 |
string |
|
ValueType_Duration |
6 |
4 byte-integer |
|
ValueType_TimePoint |
7 |
4 byte-integer |
|
ValueType_Filename |
8 |
string |
|
ValueType_Bool |
9 |
1 byte-integer |
|
ValueType_LongLength |
12 |
8 byte-double |
|
ValueType_ShortLength |
13 |
8 byte-double |
|
ValueType_StringLong |
62 |
string |
|
ValueType_LongDuration |
165 |
4 byte-integer |
