Package org.matsim.core.router

Packages
package	costcalculators
package	priorityqueue
package	speedy
package	util

Classes
interface	AnalysisMainModeIdentifier
class	AStarEuclidean
class	AStarEuclideanFactory
class	AStarLandmarks
class	AStarLandmarksFactory
class	BeelineTeleportationRouting
class	DefaultAnalysisMainModeIdentifier
class	DefaultRoutingModules
class	DefaultRoutingRequest
class	Dijkstra
class	DijkstraFactory
class	FacilityWrapperActivity
interface	FallbackRoutingModule
class	FallbackRoutingModuleDefaultImpl
class	FreespeedFactorRouting
class	FreespeedFactorRoutingModule
class	InitialNode
class	InvertedLeastPathCalculator
class	LeastCostPathCalculatorModule
class	LinkToLinkRouting
class	LinkToLinkRoutingModule
class	LinkWrapperFacility
class	LinkWrapperFacilityWithSpecificCoord
interface	MainModeIdentifier
class	MainModeIdentifierImpl
interface	MultimodalLinkChooser
class	MultimodalLinkChooserDefaultImpl
class	NetworkRoutingInclAccessEgressModule
class	NetworkRoutingModule
class	NetworkRoutingProvider
class	PlanRouter
class	RouterUtils
class	RoutingModeMainModeIdentifier
interface	RoutingModule
interface	RoutingRequest
class	SingleModeNetworksCache
class	StageActivityTypeIdentifier
class	TeleportationRoutingModule
class	Transit
class	TransitRouterWrapper
class	TripRouter
class	TripRouterFactoryBuilderWithDefaults
class	TripRouterModule
class	TripStructureUtils

Detailed Description

Contains different routing algorithms and org.matsim.core.population.algorithms.PlanAlgorithm PlanAlgorithms} to use the routing algorithms on plans.
The routing algorithms, responsible for finding the least-cost-path between two nodes in the network, all implement the interface org.matsim.core.router.util.LeastCostPathCalculator. Currently implemented are PlansCalcRouteDijkstra Dijkstra's shortest path algorithm} and some optimizing variants of it (e.g. AStarLandmarks A* with Landmarks}).
As the routing algorithms are all time-dependent, they need not only weights on the links, but time-dependent weights and additionally the (estimated) travel times on these links. This data is provided by the interfaces org.matsim.core.router.util.TravelTime, org.matsim.core.router.util.TravelDisutility and org.matsim.core.router.util.TravelMinDisutility. A few commonly used implementations of these interfaces can be found in the subpackage costcalculators.

All modes are not necessarily routed on the network; moreover, a trip may consist in a series of stages (movements with one vehicle, reprensented by legs), which may be separated by "dummy" activities ("<i>stage activities</i>"). A trip is defined as the longest sequence of consecutive plan elements consisting only of legs and stage activities. For this, the following three layer architecture is provided:

• the org.matsim.core.router.RoutingModules are responsible for computing trips between individual O/D couples, for a given mode.
• the org.matsim.core.router.TripRouter registers org.matsim.core.router.RoutingModules for each mode, and allows to route between O/D pairs for any (registered) mode. It does not modify the plan, but provides convenience methods to identify trips and easily insert a trip between two activities in a plan.
  
• the org.matsim.core.router.PlanRouter provides a org.matsim.core.population.algorithms.PlanAlgorithm to route all trips in a plan.

The behaviour can be modified by implementing custom org.matsim.core.router.RoutingModules.
The previous behavior was based on legs rather than trips: the corresponding classes are temporarily kept in the org.matsim.core.router.old package for backward compatibility.
Note that the routing algorithms are generally seen as not thread-safe! If threads are used, one must ensure that each thread uses its own instance of a routing algorithm.