Skip to content

Check Mapped Schedule Plausibility

Flavio Poletti edited this page Nov 5, 2019 · 1 revision

After running the PublicTransitMapper, the schedule is validated automatically. However, while the TransitScheduleValidator offerst a good first indicator of the quality of a schedule, it does not check how plausible a transit route is. Possible implausibilities are for example if a route has loops, if sudden direction changes happen between links (u-turns) or if the travel times given by the schedule are cannot be met. If the travel time between two stops is higher than the scheduled time this points to either a too long (i.e. wrong) route or too low freespeed values on the network.

Run

The package provides a plausibility check via

org.matsim.pt2matsim.run.CheckMappedSchedulePlausibility

that looks for implausible parts of a route and warns accordingly. It needs the input:

[0] schedule file
[1] network file
[2] coordinate system (of both schedule and network)
[3] output folder

Output

The following files are created in the output folder:

  • allPlausibilityWarnings.csv: shows all plausibility warnings in a csv file
  • stopfacilities.csv: the number of child stop facilities for all stop facilities as csv
  • stopfacilities_histogram.png: a histogram as png showing the number of child stop facilities
  • plausibilityWarnings.geojson: Contains all warnings for groups of links
  • schedule_transitRoutes.geojson: Transit routes of the schedule as lines
  • schedule_stopFacilities.geojson: Stop Facilities as points
  • schedule_stopFacilities_refLinks.geojson: The stop facilities' reference links as lines
  • network.geojson: Network as geojson file containing nodes and links

Geojson files can be viewed in a GIS, a recommended open source application is QGIS. It allows drag and drop loading and viewing of the plausibility results, network and schedule files.

Warnings

Travel Time Warning

Warns if the travel time given by the schedule cannot be achieved by a transit route. This indicates that the network's freespeed values or link lengths are not suitable for the given transit route. A warning can also point to large detours due to one-way or missing links.

Artificial Link Warning

Warns if a link is an artificial link (i.e. created by the pt mapper). To prevent these warnings, edit the network before pt mapping in a way that every stop - that should not use artificial links - has a feasible link nearby.

Loop warning

Warns if a transit route's link sequence passes a node twice. This might be intended behaviour if a route really has loops. Otherwise it might indicate detours due to wrongly chosen link candidates.

Direction Change Warning

Warns if a link sequence has abrupt direction changes. This means by default >60° for bus and >30° for rail. Whether they point to real problems depends on network accuracy. Abrupt direction changes in itself do not impact a simulation.

How to handle Warnings

CheckMappedSchedulePlausibility only shows you where there might be problems with the network or schedule (thus warnings and not errors). It's more about having a look at them and less about eliminating them all. So in general it's suggested to inspect the generated geojson files visually to see where the warnings are located.

There are two ways to deal warnings: Check and then ignore if it is a false positive. Or you can adjust the network and run the PTMapper again, maybe with different config parameters. Changing the schedule is discouraged because it's more difficult to do so and errors are more likely to be within the network. If your network is based on OSM, it's best to correct errors (like missing streets/bus lanes or wrong classified streets) on Openstreetmap, before converting to MATSim. It is also possible that you have to adjust some settings in the converter, e.g. for neighbourhood street etc. You shouldn't fix the MATSim network by hand (for example with JOSM), as the steps are not really reproducible by code. Finally, there are a some settings/thresholds in the PlausibilityCheck class that can be adjusted.

To summarize: There is no general approach to "fixing" those warnings and it depends on the use case whether this is even necessary.