Demand/Routes from Observation Points
Since version 0.9.5, the SUMO-package contains a routing module named DFROUTER. The idea behind this router is that nowadays, most highways are well equipped with induction loops, measuring each of the highways' entering and leaving flows. Given this information one may assume that the flows on the highway are completely known. DFROUTER uses directly the information collected from induction loops to rebuild the vehicle amounts and routes. This is done in several steps, being mainly:
- Computing (and optionally saving) the detector types in the means that each induction is set to be a source detector, a sink detector or an in-between detector
- Computing (and optionally saving) the routes between the detectors
- Computing the flow amounts between the detectors
- Saving the flow amounts and further control structures
Contents |
Computing Detector Types
The idea behind the DFROUTER assumes that a network is completely covered by detectors, meaning that all off- and on-ramps have an induction loop placed on them. Such an information whether an induction loop is a pure source or sink or whether it is placed between such is but not given initially. It must be computed. To do this, the DFROUTER needs the underlying network as well as a list of detector definitions where each describes the position of an induction loop. The network, being a previously built SUMO-network, is supplied to the DFROUTER as usual using the --net-file <SUMO_NET_FILE> (-n) option, the list of induction loops using --detector-files <DETECTOR_FILE>[,<DETECTOR_FILE>]+ (-d for short). A detector file should look as follows:
<detectors> <detectorDefinition id="<DETECTOR_ID>" lane="<LANE_ID>" pos="<POS>"/> ... further detectors ... </detectors>
This means that each detector is initially described using its id, a lane it is placed on, and a position on the lane. To be exact:
- id: A string holding the id of the detector
- lane: The id of the lane the detector lies on. Must be a lane within the network.
- pos: The position on the lane the detector shall be laid on in meters. The position must be a value between -1*lane's length and the lane's length. In the case of a negative value, the position will be computed backward from the lane's end (the position the vehicles drive towards).
Given a network and the list of detectors, DFROUTER assigns types to detectors and saves the so extended list into a file if the option --detectors-output <DETECTOR_OUTPUT_FILE> is given. This list looks like the input described above except that an aditional attribute is given for each detector, "type", which may have one of the following values: "source", "sink", "between", and "discarded". You can also generate a list of points of interests (POIs) which can be read by SUMO-GUI where each POI represents a detector and is colored by the detector type: green for source detectors, red for sink detectors, blue for in-between detectors, and black for discarded detectors. To force DFROUTER to do this, use --detectors-poi-output <POI_FILENAME>.
When wished, if for example other parameters chage, the extended <DETECTOR_OUTPUT_FILE> can be fed back again into DFROUTER instead of the previous <DETECTOR_FILE>. In this case the detector types do not have to be computed again. To force DFROUTER to recompute the types, use --revalidate-detectors.
Computing Routes
Now that we do know where vehicles enter and where they leave the network, we may compute routes for each of the pairs. The DFROUTER is told to build and save routes using --routes-output <ROUTE_OUTPUT_FILE> where <ROUTE_OUTPUT_FILE> is the name of the file the computed routes shall be written to. The generated file only contains routes, no vehicle type definitions and no vehicles.
Normally, only routes starting at source detectors and ending at sink detectors are computed. Using the option --routes-for-all you can force DFROUTER to also build routes that start at in-between detectors. The option --all-end-follower will make the routes not end at the edge the source detector is placed on, but on all edges that follow this edge. --keep-unfinished-routes will also keep those routes where a sink detector could not be found for what may be the case if the network is not completely covered with induction loops.
Computing Flows
The next step is to use the computed routes and flow amounts from the real-world detectors to compute flows across the modelled network. The flows are given to DFROUTER using --measure-files <STRING> (or -f <DETECTOR_FLOWS>[,<DETECTOR_FLOWS>]+. They are assumed to be stored in CSV-format using ';' as dividing character. The file should look as follows:
Detector;Time;qPKW;qLKW;vPKW;vLKW myDet1;0;10;2;100;80 ... further entries ...
This means the first time has to name the entries (columns). Their order is not of importance, but at least the following columns must be included:
- Detector: A string holding the id of the detector this line describes; should be one of the ids used in <DETECTOR_FILE>
- Time: The time period begin that this entry describes (in minutes)
- qPKW: The number of passenger cars that drove over the detector within this time period
- vPKW: The average speed of passenger cars that drove over the detector within this time period in km/h
The following columns may optionally be included:
- qLKW: The number of transport vehicles that drove over the detector within this time period
- vLKW: The average speed of transport vehicles that drove over the detector within this time period in km/h
These are not quite the values to be found in induction loop output. We had to constrain the <DETECTOR_FLOWS> files this way because DFROUTER is meant to read very many of such definitions and to do this as fast as possible.
Because in some cases one reads detector flow definitions starting at a certain time but wants the simulation to begin at another, it is possible to add a time offset using --time-offset <INT> which is the number of seconds to subtracted from the read times.
Saving Flows and other Values
If flow definitions were supplied, we can let the DFROUTER save the computed vehicles together with their routes. Vehicles will be generated at the source detectors which are placed at certain positions of the networks' lanes. Prior to version 0.12.3, emitters (see "Emitter") are used to insert those vehicles into the network. In these versions, DFROUTER can be forced to generate such emitters using --emitters-output <EMITTER_OUTPUT_FILE>. This file will contain emitter declarations for each of the source detectors. If no value is given, emitters will not be written. Accompanying, there will be emitter definitions written named "emitter_<DETECTOR_ID>.def.xml" where <DETECTOR_ID> is the id of the according source detector. These definitions are called within the <EMITTER_OUTPUT_FILE> and contain vehicles which depart the emitter in accordance to the read flows and have routes computed using the flows.
Since version 0.12.3, vehicles are generated as part of the route definitions as is standard in the rest of the SUMO suite of applications. In future releases, the use of emitters will not be supported at all.
As some approaches use a speed limit to avoid open-end boundary problems, the DFROUTER can generate a list of speed triggers (see "Variable Speed Signs (VSS)") placed on the positions of sink detectors. The name to save the declaration of these speed triggers into is given using the option --variable-speed-sign-output <VSS_OUTPUT_FILE>. The according variable speed sign definitions will be written into files named "vss_<DETECTOR_ID>.def.xml" where <DETECTOR_ID> is the name of the according sink detector.
In order not to end vehicle routes on off-ramps, it is possible to place rerouters (see "Rerouter") at the positions of the sink detectors, too. Giving the option --end-reroute-output <REROUTER_OUTPUT_FILE> will generate a list of rerouter declarations. Please remark that in this case, no rerouter definitions are written, because the DFROUTER has no further information about possible routes beyond the area covered by the detectors.
It's quite nice to have the possibility to check whether the simulation does what one wants. To validate whether the same flows are found within the simulation as within the reality, the option --validation-output <SUMO_DETECTORS_OUTPUT> may be helpful. It generates a list of detector definitions (see "inductive loop detectors") placed at the positions of sink and in-between detectors. Their output will be saved into files named "validation_det_<DETECTOR_ID>.xml" and should be easily comparable to the detector flows previously fed to the router. The option --validation-output.add-sources will let DFROUTER also build inductive loop detectors for source detectors which are place 1m behind the real-life detector's position.
How to include the files
For example, a MyConfig.sumo.cfg file should look as follows:
<input>
<net-file value="MyNet.net.xml"/>
<additional-files value="MyRoute.rou.xml MyDetectors.det.xml MyEmitter.emi.xml" />
</input>
As you may notice the route file is listed as additional file and not as separate file.