-
Notifications
You must be signed in to change notification settings - Fork 68
Creating an unmapped MATSim transit schedule
The GTFS converter's main job is transforming GTFS trips to MATSim transit routes. Trips and transit routes are not equivalent: A trip defines the stop sequence and the departure time for a vehicle while a MATSim transit route defines the stop sequence but usually has more than one departure time. The time offsets between stops is stored in the routeProfile within the transit route in MATSim. GTFS offers two ways: Either with explicit time stamps in stop_times.txt or as frequencies in frequencies.txt. The converter can use both. Finally, routes in GTFS are like transit lines in MATSim. Stops are converted straight to stop facilities. GTFS offers no explicit information that could be used as isBlocking value for MATSim stop facilities, so false is set by default.
For each trip, a service id defines on which days the trip is carried out. MATSim normally only simulates one day, therefore one sample day has to be extracted from the GTFS feed. Although possible, it is not recommended to use all trips in the feed. The following methods are suggested:
- Define the date to extract all affected trips from it.
- Use the day on which most services run.
- Use the day on which most trips are carried out.
The converter can be run by calling the main() method of
org.matsim.pt2matsim.run.Gtfs2TransitSchedule
with the following arguments:
[0] folder where the gtfs files are located (a single zip file is not supported)
[1] Which service ids should be used. One of the following:
- date in the format "yyyymmdd"
- "dayWithMostServices"
- "dayWithMostTrips"
- "all"
[2] the output coordinate system. Use "WGS84" for no transformation. EPSG:* codes are supported.
[3] output transit schedule file
[4] output default vehicles file (optional)
If a feed contains shapes, the shape id is stored in the transit route's description.
HAFAS is a data format used by Swiss public transit agencies (particularly SBB) and other agencies in Europe (e.g. Deutsche Bahn). Data is given in ASCII text files that contain information about operators, stops, vehicles and stop sequences, stop times and additional information. HAFAS data for Switzerland is publicly available and provided by SBB. A report that comes with this exported data provides information on the structure of the files.
Stop facilities are created from the stops defined in the file BFKOORD_GEO (uses WGS84). The transit lines, routes, departures and stop sequences are generated from FPLAN. The file BETRIEB_DE is used to add the agency's name to the transit line id. The reference day is extracted using BITFELD. A default transport mode is assigned to each transit route depending on the vehicle defined in HAFAS. The transport modes correspond to one of the eight transport modes defined in GTFS (see GTFS reference). Optionally, a default vehicle file is provided using predefined values (based on data provided by M. Rieser and P. Bösch) for different vehicle types such as interregional trains, S-Bahn trains or trolley buses.
Converts all files in hafasFolder and writes the output schedule and vehicle file. Stop Facility coordinates are transformed to outputCoordinateSystem.
The converter can be run by calling the main() method of
org.matsim.pt2matsim.run.Hafas2TransitSchedule
with the following arguments:
[0] hafasFolder
[1] outputCoordinateSystem. Use "WGS84" for no transformation. EPSG:* codes are supported.
[2] outputScheduleFile
[3] outputVehicleFile
[4] (optional) chosenDate for which to build schedule, format dd.MM.yyyy
OSM offers tags to specify spatial public transit data on stop locations and transit routes. The converter provided as part of the package creates an unmapped transit schedule from OSM data. It creates stop facilities from OSM nodes withthe tag public_transport=stop_position. Relations with the tag route=* are converted to transit routes. These transit routes contain only stop sequences. Link sequences are not converted even if they are available. The transport mode is set based on the respective route=* tag value of the relation.
The quality of the generated transit schedule for a region depends largely on the accuracy of the data in OSM. Often route data is either inconsistent or not even available. The lack of naming conventions further complicates using the data. In addition, OSM does not offer any tags to store temporal information. Thus, departure times and stop offsets have to be gathered from other sources.
The converter can be run via
org.matsim.pt2matsim.run.Osm2TransitSchedule
with the following arguments
[0] osm file
[1] output schedule file
[2] output coordinate system (optional)