In chapter 2, an overview was given of data available or used in real-world (see Ta-ble 2.1). is section will look in more details at the data required by the extended traffic flow simulation. For data structures already existing within MATSim it will be shown how they can be adapted to be suitable for the needs of a transit simulation. For data structures yet missing, the influences for the design will the discussed and the final design presented.
7.2. Data
7.2.1 Network
e network describes the physical infrastructure available. Previously, it only represented the road network where cars could move around. Now, the network description must be extended to include multimodal aspects. To differentiate only between roads and rails is not sufficient. Not only have cars and trains to be dis-tinguished, but e.g. also cars and buses, that can share a common road or not. In addition, links may exist that are both roads and rails, as it is the case for most streetcars. Given the existing structure of networks in MATSim, the primary step towards a multimodal network is the inclusion of an additional attribute for each link, listing the transportation modes that are permitted on each link.
If the list of allowed transportation modes varies between different lanes of the same street (e.g. a bus-lane), this must be modeled as multiple links in the network. Fig. 7.1 shows an example how a real-world situation could be modeled in the network.
Figure 7.1: Example, how a physical intersection could be encoded in the network model. Each link is labeled with its allowed transportation modes.
Each link has attributes, describing physical aspects (like its length or the num-ber of lanes) as well as traffic related ones (like the flow-capacity or free speed). Al-though these attributes were once added to describe car traffic, they are also suitable
for describing transit traffic in the queue model. Flow-capacity and physical space is measured in private car equivalents. Buses, streetcars and trains can also have a corresponding car equivalent assigned, causing them to allocate more space on a link than a regular vehicle.
7.2.2 Population and Routes
MATSim distinguishes already for a long time between legs driven with a car and legs not driven with a car, by assigning each leg a transportation mode. In the past, the traffic flow simulation just ignored all legs not carried out with a car.
Each leg contains a route, describing how the agent should be moved around by the traffic flow simulation. To fully support the transit simulation, only this route information must be adapted, so the traffic flow simulation has all the data to move the agent around using transit offerings.
For car legs, the route currently describes the list of nodes an agent has to cross to reach its destination. At each node, the agent checks all outgoing links to find out which one leads to the next node. So, a route for car legs specifies a way through the road network, and is thus also called anetwork route.
For transit legs, such a route description is not practical, as transit users do not necessarily need to know what turns the vehicle they are in has to take to reach the next stop. For a passenger it is enough to known at which stop to board a transit vehicle of a specific transit line and at which stop to alight it. So, the data triple entry stop, transit line, exit stop is sufficient to describe the route of a transit user. Note the distinction between transit drivers and transit users: A transit driver needs a network route, but not the transit users.
7.2.3 Transit Schedule
e transit schedule is the central data structure regarding the simulation of transit.
It contains information about one or more transit lines, their detailed routes, the stops approached on each route, and the departure time for each course along a route. e data can be split into two parts. e first part describes infrastructure, namely stop facilities, while the second part describes the services offered.
estop facilitiesdescribe the locations where passengers can board and alight transit vehicles. Besides a unique identifier, stop facilities also have a coordinate used for estimating walk distances for agents or for finding the nearest stops at some place. An additional reference to a link from the network is used to specify on which link the stop can be reached by transit vehicles.
7.2. Data
Atransit linecorresponds to a bus line, subway line or other “line” of a transit system. In the real world, a transit line often has a number or color assosciated (e.g. the “red” subway, bus 32, etc.). In the model, a transit line has an identifier and can have multiple transit routes.
A transit routedescribes one specific route of a transit line, including its time profile. e time profile describes how long it takes (or better: it is planned to take) to travel from one stop to the next. is information is used to project the departure time of one course onto arrival and departure times of the same course on later stops. Most transit lines have at least two transit routes, one in each direc-tion. As the travel time during peak and off-peak hours may differ—either because of higher demand and thus higher stop times, or because of more dense traffic on roads, slowing buses and other vehicles with non-dedicated tracks down—the number of transit routes may increase further if the different travel times are antic-ipated in the schedule. In addition, some lines may not operate on the full extent of the line in off-peak hours, leading to additional transit routes for a transit line.
e route is described twofold: once as a list of transit route stops, and once as network route. e latter is used by the driver of the transit vehicle, while the former is required such that passengers can do route planning.
Departures are stored for each transit route. A departure specifies at which time a vehicle starts the associated transit route. e vehicle can be specified as well, making it possible to use vehicles with different capacities according to the time of day (e.g. peak/non-peak hours).
Each transit routes contains an ordered list of transit route stops. A route stop references to a stop facility for its exact location, and contains arrival and departure time offsets. ese offsets are relative to a departure time and build the time profile of a transit route.
e data is structured hierarchically, with many 1:n relationships. Example:
One transit schedule can consist of multiple transit lines, one transit line contains several transit routes, and each route usually has several departures. Fig. 7.2 shows the structure of the transit schedule as entity-relationship model [21], drawn in UML syntax [93].
MATSim provides writers (and matching readers) to store the data to a file on disk. e file format is based on a custom XML grammar [121]. is approach is widely used throughout MATSim and has proven to be useful and powerful.
Appendix B includes the full document type description (DTD) of the specified file format as well as an example of a transit schedule file.
e described structure relates closely how other tools store schedules. PTV VISUM [91] differentiates between routes (as a list of route stops) and time profiles
TransitSchedule
TransitStopFacility
TransitLine TransitRoute TransitRouteStop
Departure
0..N
1
0..N 0..N 0..N
1 1 1
1 0..N
0..N
1
Figure 7.2: Entity-Relationship (ER) model of the transit schedule data structure, in UML syntax
(which reference the route stops), whereas the aforementioned data structure stores the time profiles directly in the route stops. On the one hand, separating route and time profile allows one to have multiple time profiles for the same route, giving a route a strong meaning. On the other hand, the additional hierarchy makes the data structure much more verbose (especially when written to file) and more complex due to the additional references from the time profile to the route stops.
VISUM stores the data in flat ASCII tables, similar to a relational database schema.
e Association of German Transport Operators (Verband Deutscher Verkehrs-unternehmen, VDV) publishes recommendations called ÖPNV data model [114, 115] that describes data structures and file formats for the exchange of transit re-lated data. As the structures are mainly designed for data exchange, the number of tools that use the file formats natively is limited. Also, the recommendation dealt only with database structures in a first version for data exchange, before defining ASCII data formats in a later version. Still, it influenced the design of data struc-tures in other tools such that a high level of compatibility could be reached, and
“compatibility with the ÖPNV Data Model” is often claimed. e model, often also just called VDV data model, defines lines and route sequences (corresponding to list of ordered stop facilities), similar to MATSim or VISUM. e schedule is given as journeys with a departure time and assigned to routes and lines.
e Berlin Transit Company BVG used BERTA, as system developed by IVU [53], to manage its data and plan their services. BERTA allows to export data into hierarchical XML files, that resemble closely to the format specified by the aforementioned ÖPNV data model. A more detailed description of the format can be found in [111], where a transit router based on that data was developed.