Demand/Routes from Observation Points
原文链接:http://sumo.dlr.de/wiki/Demand/Routes_from_Observation_Points
自从0.9.5开始,SUMO安装包里就有一个路径模块为DFROUTER。当初开发这个模块的原因就是基于,现在很多高速的测量数据是根据传感线圈测量的,得到进入流量和驶出流量。一旦给出了这些信息,那么假设高速上的流就已经知道了。DFROUTER直接使用传感线圈的数据区重建车辆的数量和路径。主要是通过以下的几个步骤实现的:
1)、计算(选择的保存)传感器的类型,每个传感器设置为源检测器(a source detector)、接受检测器(a sink detector)和内检测器(an in-between detector)。
2)、计算(选择性的保存)检测器之间的路径(routers);
3)、计算检测器之间的车流量(flowamount)
4)、保存车流量和进一步的控制结构(furthercontrol structures)
注意:
DFROUTER应用在高密度的城市路网中略显不足。另一个可用的方法是动态校准(访问:dynamic calibration)。
1、计算探测器类型
DFROUTER假设路网全部被检测器覆盖。意味着所有的路段均有检测器安装。但是它属于哪一种检测器(源、接受还是内)并没有初始化。但是这是必须的。为了实现这个,DEROUTER需要路网和检测器的定义列表,列表写明了检测器的位置。net.xml文件就是先前生成的路网文件,只需要跟在命令—net-file(可以简写-n)后面,检测器的列表文件跟在命令—detector-files(可以简写-d)后面。一个检测器文件应该按照如下的格式书写:
<detectors>
<detectorDefinitionid="<DETECTOR_ID>" lane="<LANE_ID>"pos="<POS>"/>
... furtherdetectors ...
</detectors>
这表明一个检测器可以通过一个ID、所在的车道和位置信息确定。
id:表明检测器的一个字符串;
lane:检测器所在的车道;
pos:在车道上的位置,为-1*laneLength到laneLength之间。如果是负数则从车道的尾部开始计算。
给定一个路网和一个检测器列表,DFROUTER能够分配检测器的类型,通过命令—detectors-output来实现。输出文件类似上面看到的内容,但是多了一个type属性,其中type属性的值为:source、sink、between和discarded。你也可以生成你感兴趣区域POI的列表,每一个POI代表一个检测器,通过不同颜色表示不同的类型:绿色source、红色sink、蓝色in-between和黑色discarded。要实现这个,需要使用命令—detector-poi-output。
检测器文件的输出文件(output_file)仍可以作为检测器输入文件(file)。这种情况下检测器类型不在倍计算,如果想强制进行计算,则可以通过命令—revalidate-detector实现。
2、计算路径routes
现在我们知道了车辆从哪里进入从哪里驶出了,我们可以计算每对的路径【没太明白】。DFROUTER被告知可以通过命令实现—routers-output,输出文件就是路径文件rou.xml。生成文件仅仅有路径(routes),并没有车辆类型和车辆。
现在,仅仅计算了从源检测器到接受检测器的数据。通过使用命令—routes-for-all实现全部的路径。命令-all-end-follower将会是路径不会再源检测器处停止,而是紧随其后的道路。命令—keep-unfinished-routes将会保留哪些没有覆盖检测器的路径。
3、计算车流
接下来就是根据计算的routes和真实世界的流量数据来计算flows。flows通过命令—messure-files来给出。假设存储为csv格式,分号作为分隔符。文件形式如下:
Detector;Time;qPKW;qLKW;vPKW;vLKW myDet1;0;10;2;100;80 ... further entries ...
表示了必须命名的条目,顺序无关但是不能缺少:
Detector:检测器的ID,应该是前面定义的检测器文件中的字符;
Time:开始进入的时间周期(分钟为单位);
qPKW:在时间内通过检测器的普通车辆数(passengercar);
vPKW:通过的平均速度;
接下来的两个属性是可选的:
qLKW:在时间内通过检测器的运输车辆数(transportcar);
vPKW:通过的平均速度。
These are not quite the values to be foundin induction loop output.【这句不太懂】我们不得不约束检测器流文件<DETECTOR_FLOWS>,因为DEROUTER打算读取很多的数据。
有时候检测器定义文件的时间和仿真开始的时间不相同,可以通过命令—time-offset实现,这个值就是读取时间减去后的值。
4、保存流flows和其他的值
如果流flow的定义给出,那么我们可以使用DFROUTER保存计算的车辆和他们的路径。车辆将会在源检测器处放置。DFROUTER通过命令—emitters-output生成车辆。文件将会包含在源检测器位置的车辆发射器定义。如果没有值给出,那么车辆将不会被写入。同时,there will be routeDistributions each withthe same name as a detector. These reflect the distribution of routes at thedetector with the same ID.
一些方法使用速度限制去避免open-end的问题,DFROUTER能够生成速度触发器(参考variable speed signs,VSS),放置在sink检测器上。可以通过命令—variable-speed-sign-output生成速度触发器文件。变速定义将会写入文件“vss_<检测器ID>.def.xml”中。
为了不再off-ramps处结束车辆的路径,允许车辆在sink检测器处重新进行路由(rerouter)定义。通过命令—end-rerouter-output将会生成一系列重路由定义。请注意,如果没有重路由定义,那么DFROUTER将不会进行定义,因为除了检测器周边因外不知道其他的信息。
可以检查是否仿真是想象中的那样。To validate whether the same flows are found within thesimulation as within the reality, the option --validation-output<SUMO_DETECTORS_OUTPUT> may be helpful. It generates a list of detectordefinitions (see "inductive loop detectors") placed at the positionsof sink and in-between detectors. Their output will be saved into files named"validation_det_<DETECTOR_ID>.xml" and should be easilycomparable to the detector flows previously fed to the router. The option --validation-output.add-sources will letDFROUTER also build inductive loop detectors for source detectors which areplace 1m behind the real-life detector's position.
5、如何包含文件
DFROUTER在所有的sumo中的路径模块中是比较特殊的,它的路径文件和车辆文件是分开的。你必须确保他们的顺序是正确的(参考:http://sumo.dlr.de/wiki/SUMO#Loading_order_of_input_files)另外,这个模块在它的emitters发射西文件中没有存储车辆。你可以如下操作:
dfrouter --net-file net.net.xml --routes-output routes.rou.xml --emitters-output vehicles.xml ..
.
sumo还必须进行如下操作:
sumo --net-file net.net.xml --additional-files routes.rou.xml,emitters.rou.xml
如果你想运行工具sort_routers.py(Tools/Routes#sort_routes.py),那么可以进行如下的操作:
sumo --net-file net.net.xml --route-files routes.rou.xml,sorted_emitters.rou.xml sumo --net-file net.net.xml --route-files sorted_emitters.rou.xml --additional-files routes.rou.xml