• Rerouter

Rerouter#

Rerouter changes the route of a vehicle as soon as the vehicle moves onto a specified edge.

A rerouter is set into the simulated network by adding the following declaration line to an additional-file: <rerouter id="<REROUTER_ID>" edges="<EDGE_ID>[;<EDGE_ID>]*" file="<DEFINITION_FILE>" [probability="<PROBABILITY>"]/>. Rerouter may be placed on several edges, at least one edge is necessary. Furthermore, it is possible to define the probability for rerouting a vehicle by giving a number between 0 (none) and 1 (all) already within the definition. The declaration values are:

A rerouter may work in several different ways. Within a time period you may close an edge, or assign new destinations or predefined routes to vehicles. The next sections will describe these actions in detail.

Definition styles#

There are two styles in which to declare rerouters.

everything in one file#

The additional-file looks like this:

<additional>
   <rerouter id="<REROUTER_ID>" edges="<EDGE_ID>[;<EDGE_ID>]*" [probability="<PROBABILITY>"]>
      <interval begin="<BEGIN_TIME>" end="<END_TIME>">
         ... action description ...
      </interval>

      ... further intervals ...
   </rerouter>

   ... further rerouters ...
</additional>

definitions in a separate file#

The additional-file looks like this:

<additional>
   <rerouter id="<REROUTER_ID>" edges="<EDGE_ID>[;<EDGE_ID>]*" [probability="<PROBABILITY>"]>
     <include href="definitions.xml"/>
   </rerouter>

   ... further rerouters ...
</additional>

And the file definitions.xml (which describes the actions over time) looks like this:

   <interval begin="<BEGIN_TIME>" end="<END_TIME>">
      ... action description ...
   </interval>

   ... further intervals ...

Note, that the definition file has no root-level element

All the following examples use the everything-in-one-file-syntax.

Closing a Street#

A "closingReroute" forces the rerouter to close the edge <EDGE_ID>. Vehicles which normally would pass this edge will get a new route as soon as they reach one of the edges given in the edges-attribute of the rerouter's declaration. The algorithm for selecting a new route is the same as described at #Assigning_a_new_Destination with the additional constraint that closed edges must be avoided. A closingReroute definition may look like this:

<rerouter>
   <interval begin="<BEGIN_TIME>" end="<END_TIME>">
      <closingReroute id="<EDGE_ID>"/>
   </interval>

   ... further intervals ...

</rerouter>

The attributes used within such definitions are:

When using a <closingReroute> without attributes allow and disallow, vehicles that cannot reach their destination by an alternative route simply continue on their old route and will effectively ignore the closing of the edges. When using either attribute allow or disallow (only one may be used in the same definition), vehicles which cannot change their route will stop in front of the closed edge until the defined interval ends. This may be used to simulate traffic jams, caused by spontaneous road closing.

Closing a Lane#

A "closingLaneReroute" forces the rerouter to close the lane <LANE_ID> by setting its permissions to authority (this can be customized). Vehicles that pass this route and which are equipped with a rerouting device may compute a new route as soon as they reach one of the edges given in the edges-attribute of the rerouter's declaration. A closingLaneReroute definition may look like this:

<rerouter>
   <interval begin="<BEGIN_TIME>" end="<END_TIME>">
      <closingLaneReroute id="<LANE_ID>"/>
   </interval>

   ... further intervals ...

</rerouter>

The attributes used within such definitions are:

Reversible Lanes#

Two closingLaneReroute definitions may be used to simulate a reversible lane in the following way:

• Define two edges in reverse directions with at least 2 lanes each
• prohibit driving on one of the central lanes (disallow="all")
• and modify the edge geometry so that the central lanes occupy the same space.
  • by shifting geometry of both edges sideways (-1.6 for default lane width)
  • or by setting the geometry directly

To change their direction for a specific duration, the following rerouter may be used:

<rerouter id="example" edges="E1 -E1">
      <interval begin="7:0:0" end="8:30:0">
            <closingLaneReroute id="E1_1" allow="all"/>
            <closingLaneReroute id="-E1_1" disallow="all"/>
      </interval>

   </rerouter>

Alternatively to changing lane permissions with a rerouter, the traci functions traci.lane.setAllowed and setDisallowed may also be used.

Assigning a new Destination#

A "destProbReroute" forces the rerouter to assign a new route to vehicles that pass one of the edges defined in the edges-attribute of the rerouter's declaration. A new route destination is used, defined by the name of a new destination in the according element:

<rerouter>
   <interval begin="<BEGIN_TIME>" end="<END_TIME>">
      <destProbReroute id="<EDGE_ID1>" probability="<PROBABILITY1>"/>
      <destProbReroute id="<EDGE_ID2>" probability="<PROBABILITY2>"/>
   </interval>

   ... further intervals ...

</rerouter>

The fastest route is computed automatically using the Dijkstra-algorithm and starting at the edge the vehicle is located at and ending at the new destination. The following travel times are considered for routing (the first applicable value is used):

• the current (smoothed) travel times in the network are used if the vehicle is equipped with a rerouting device
• subjective edge costs for the current vehicle if set via TraCI command change edge travel time information
• edge weights loaded via the sumo option --weight-files
• travel times in the empty network

The attributes used within a destProbReroute are:

Special Destination Values#

• keepDestination: the vehicle continues on its current route
• terminateRoute: the vehicle immediately leaves the simulation and counts as arrived at its current position on the rerouter edge

Assigning a new Route#

A "routeProbReroute" forces the rerouter to assign a new route to vehicles which pass one of the edges defined in the edges-attribute of the rerouter's declaration. In this case, the id of a complete route must be supplied instead of a new destination:

<rerouter>
   <interval begin="<BEGIN_TIME>" end="<END_TIME>">
      <routeProbReroute id="<ROUTE_ID1>" probability="<PROBABILITY1>"/>
      <routeProbReroute id="<ROUTE_ID2>" probability="<PROBABILITY2>"/>
   </interval>

   ... further intervals ...

</rerouter>

The attributes used within such definitions are:

Repeated public transport routes#

If the new route assigned with the rerouter contains stops, the vehicle will use these stops. If the stops use attribute 'until' then the route should use attribute 'cycleTime' to shift the until-times by a set amount on each repeat.

Rerouting to an alternative Parking Area#

Vehicles that stop at a parking area may encounter the situation that the parking area has reached the limit of its capacity and does not permit parking.

In this case the vehicle either waits on the road until a parking space becomes available or it may reroute to an alternative parking area. For the latter behavior a parkingAreaReroute-definition must be specified. This rerouter definition defines a set of parking areas that may be mutually used as alternatives. Rerouting to another parking area is triggered in two cases:

• when a vehicle reaches a parkingArea and is unable to stop due to lack of capacity
• when a vehicle enters one of the rerouter-edges and the following conditions are all met:
  • its current destination parkingArea is among the set of parkingAreaReroute definitions and has attribute visible="true"
  • its current destination parkingArea is full

The definition looks like this:

   <rerouter id="myRerouter" edges="a b">
      <interval begin="0" end="2000">
         <parkingAreaReroute id="ParkAreaA"/>
         <parkingAreaReroute id="ParkAreaB"/>
      </interval>
   </rerouter>

The attributes used within such definitions are:

Memory in parking search#

Parking search refers to the situation where a vehicle encounters an occupied parkingArea and has to pick among a list of alternative destinations without knowing their occupancy state. The vehicle has to iteratively drive to alternative destinations until a free parking space is found. ParkingAreas that were visited earlier (and occupied) might be reasonably visited again with the expectation that they have cleared up since the last visit. By default, vehicles will not visit an occupied parkingArea again for 600s. This can be modified with vehicle-param or vType-param as follows:

   <vehicle ...>
      <param key="parking.memory" value="300"/>
   </vehicle

Determining the alternative parking area#

The alternative parkingArea will be selected among all parking areas that are visible and have at least 1 free space according to the minimum weighted sum over a number of attributes. For invisible parkingAreas (attribute visible="false", the occupancy value is a taken as a random number from [0,capacity[ which means they are always among the set of alternatives even when full. Each attribute (i.e. occupancy, time, distance) is normalized to [0-1] with the maximum value of all candidate parkingAreas with positive remaining capacity) and inverted as necessary. Inversion means taking the remainder to 1 instead of the normalized value itself.

By default only the distance from the current vehicle position to the new parking area is considered. The following table describes the weighting factors that can be customized using generic parameters of the vehicle or its vType:

When 'parking.probability.weight' is set to a positive value, a random number between 0 and attribute 'probability' is drawn for each candidate parkingArea. This value is then normalized to the range [0,1] by dividing with the maximum probability value of all parkingAreaReroute elements. The inverted normalized value is then multiplied with parking.probability.weight to enter into the candidate score.

Further parameters to affect parking behavior#

Destination after rerouting#

Generally, vehicles that reroute to a new parking area will continue to their original destination after finishing the stop. In the special case where

1. the original route ended at the original parkingArea edge and
2. the arrivalPos was within [startPos, endPos] of the original parkingArea

then the new route will also end at the new parkingArea and the endPos of the new parkingArea will be set as new arrivalPos.

TraCI access to parkingSearch#

The current state of the parkingSearch can be accessed via calls to traci.vehicle.getParameter with the list permitted parameters given at TraCI/Vehicle_Value_Retrieval.

Example scenarios for parkingSearch#

Test cases can be downloaded here

Vehicle Behavior when closing a street#

The interaction of vehicles with reroutes is complex and depends on many different factors. Below we give a description of each of the factors and then describe the behavior for each combination of factors. The following assumes vehicles that have an edge affected by <closingReroute .../> along their route (other vehicles are not affected directly).

1. closing style
   • a) hard closing: <closingReroute> uses attribute 'allow' or 'disallow' to prohibit the vehicle
   • b) soft closing: attribute is not used (edge use is discouraged but not forbidden)
2. alternatives
   • a) an alternative route exists
   • b) no alternative route exists
3. detour signage
   • a) an rerouter edge is encountered before the alternative route branches off
   • b) no rerouter edge is encountered before the alternative route branches off
4. vehicle style
   • a) vehicle defined with origin and destination where the affected edge is on the preferred route (i.e. <trip from="..." to="...">)
   • b) vehicle defined with fixed route
5. closing time versus departure time
   • a) vehicle departs after closing becomes active
   • b) vehicle departs before closing becomes active (closing occurs while en-route)
6. routing mode of the vehicle (set via --device.rerouting.mode or vehicle/vtype <param key="device.rerouting.mode" value="8"/>)
   • a) routing mode 0 (or generally, not setting the 4th bit): all hard closings are visible during routing
   • b) routing mode 8 (or generally setting the 4th bit): all hard-closings are ignored during routing and will never cause a route error

The following vehicle behaviors are possible:

• R: use an alternative route upon reaching the rerouter edge
• D: use an alternative route on departure
• I: ignore the closed edge and keep driving
• W: wait ahead of the closed edge until it reopens or time-to-teleport is reached (in this case teleport across the closed edge(s))
• E: generate an error

To following effects occur:

Hard closing#

• 1a-2a-3a-4a-5a: D
• 1a-2a-3a-4a-5b: R
• 1a-2a-3a-4b-5a: R
• 1a-2a-3a-4b-5b: R

• 1a-2a-3b-4a-5a: D
• 1a-2a-3b-4a-5b: W
• 1a-2a-3b-4b-5a: W
• 1a-2a-3b-4b-5b: W

• 1a-2b-3a-4a-5a: E (becomes W with --ignore-route-errors or --device.rerouting.mode 8)
• 1a-2b-3a-4a-5b: W
• 1a-2b-3a-4b-5a: W
• 1a-2b-3a-4b-5b: W

• 1a-2b-3b-4a-5a: E (becomes W with --ignore-route-errors or --device.rerouting.mode 8)
• 1a-2b-3b-4a-5b: W
• 1a-2b-3b-4b-5a: W
• 1a-2b-3b-4b-5b: W

Soft closing#

• 1b-2a-3a-4a-5a: R
• 1b-2a-3a-4a-5b: R
• 1b-2a-3a-4b-5a: R
• 1b-2a-3a-4b-5b: R

• 1b-2a-3b-4a-5a: I
• 1b-2a-3b-4a-5b: I
• 1b-2a-3b-4b-5a: I
• 1b-2a-3b-4b-5b: I

• 1b-2b-3a-4a-5a: I
• 1b-2b-3a-4a-5b: I
• 1b-2b-3a-4b-5a: I
• 1b-2b-3a-4b-5b: I

• 1b-2b-3b-4a-5a: I
• 1b-2b-3b-4a-5b: I
• 1b-2b-3b-4b-5a: I
• 1b-2b-3b-4b-5b: I

Departure on a closed edge#

When the departure edge for a vehicle is closed, vehicles will ignore this for 'soft' closing. For a 'hard' closing the simulation will raise an error. If --ignore-route-errors is set, the vehicle will be discarded with a warning.