Hello Pieter, Well, dfrouter is surely one of the most orphaned tools in the package. It's more complex than the jtrrouter which in fact is so trivial that making mistakes in programming it would be hard. But it's too seldomly used to be pushed towards a stable state. As Matthew said, a student is currently working on a honest classification of the dfrouter into existing demand generation approaches and algorithms. I wrote dfrouter initially (with Eric), but I find the implementation quite bad - too many features were wanted and are only partially - or buggy - implemented while the underlying idea could be solved more elegant, probably. Meanwhile, I find the code hard to read (...).
The basic idea is that if you have detectors given at each subsequent edge of a junction, you may compute the probability to chose one - uh?? Yes, well, trivial, isn't it? I cite an earlier mail (not to this list): "[...] In the end, it's a trivial assumption and yes, we were aware that it's under-defined. Given that we had to simulate a highway-ring, there is even the possibility that a vehicle runs in cycles. But: we were not asked to simulate specific persons and/or their drives to somewhere but only to represent (and forecast) the flows correctly. For this purpose (remember, we did not used lanes), the idea seemed to be quite right - and I still think it is. But, on a theoretical level, you cannot say it's a OD-guesser - just to note it. [...]" Now, in any case this only works for highway scenarios that have a sufficient coverage of detectors only. This was the case in the project we used it for. How did you made the comparison? Do you have a script? I did not investigate whether the vehicle numbers are correct, sorry. I just looked at the probabilities. As Matthew said, one of his students is currently working on this - from a more theoretical point of view. Maybe they want to share some information. Regarding the error - thanks for reporting. Sincerely, Daniel 2014-03-11 19:57 GMT+01:00 Pieter Loof <[email protected]>: > Hello Daniel, > > Thank you for your reaction. So far, I mainly looked at the detector > validation results, I didn't notice the problem in the route probabilities > yet. I looked into the code and didn't quite understand what was happening, > so altering the code is not really possible then. I still wonder if someone > can explain in a few sentences how the vehicles are distributed over the > routes. > > I do not need the --all-end-follower option, I had this option enabled for > another scenario on the same network and I just didn't remove it. > > I just keep informing you as developers about the problems or unexpected > behavior I encounter, because I think it could be helpful to do so. So don't > feel pushed or hurried. Unfortunately I am currently not in a position to > spend much time contributing to the code. > > Best regards, > Pieter > > > On 11 March 2014 18:17, Daniel Krajzewicz <[email protected]> wrote: >> >> Hello Pieter, >> >> thanks for the input files. >> It seems as the --all-end-follower option would be broken. I set up a >> reduced input file for your scenario with only one time slice and >> values one can easily understand. What I get when running the setting >> with the option set is a distribution: >> >> <routeDistribution id="RWS01_MONIBAS_0671hrr0180ra_0"> >> <route refId="78878493_to_41875271" probability="0.50"/> >> <route refId="78878493_to_43651334" probability="0.50"/> >> <route refId="78878493_to_34601778" probability="0.25"/> >> <route refId="78878493_to_34600847" probability="0.25"/> >> </routeDistribution> >> >> When running the same inputs without setting --all-end-follower, I get: >> >> <routeDistribution id="RWS01_MONIBAS_0671hrr0180ra_0"> >> <route refId="78878493_to_40790785" probability="0.50"/> >> <route refId="78878493_to_44353562" probability="0.25"/> >> <route refId="78878493_to_44353583" probability="0.25"/> >> </routeDistribution> >> >> What is correct. >> Well, this may help for now? If you need the vehicles to be driving to >> the end of the road (for being rerouted or whatever), you may use >> --arrivalpos -1 (hope this works). >> >> I cannot tell you whether the bug will be fixed, soon. We are quite >> busy doing other things - and, as you mentioned, it's an open source >> project. You are welcome to contribute. >> >> Sincerely, >> Daniel >> >> >> 2014-03-11 14:33 GMT+01:00 Fullerton, Matthew <[email protected]>: >> > Dear Pieter, >> > A student of mine is investigating these problems and has a good grasp >> > of what is going on and what should be improved. Maybe we could talk on >> > Skype in the coming days to save on duplicated efforts... >> > >> > Best, >> > Matthew >> > >> > On 8 Mar 2014 16:50, Pieter Loof <[email protected]> wrote: >> > Hello, >> > >> > I ran some simple tests to see how well DFRouter is able to generate >> > flows >> > similar to the real data. So far, I noticed that the flow at source >> > detectors is exactly correct, so the vehicles are generated based on the >> > source detectors. But when it comes to the distribution of the vehicles >> > over available routes, DFRouter can make large errors. >> > >> > Attached is a picture that I made, which summarizes the output of a test >> > scenario. The green detector is a source, the red detectors are sinks. >> > The >> > numbers shown at each detector are the number of vehicles that pass in a >> > 3 >> > hour time period, the top number being the real data measurement and the >> > bottom number being the number of vehicles in the simulation. >> > >> > As you can see, this is a simple problem where one vehicle flow should >> > be >> > distributed such that about the right number of vehicles reaches each >> > sink. >> > As you can see from the picture, about 1000 vehicles receive the wrong >> > route. >> > >> > I looked into the code to see how DFRouter computes the vehicle >> > distribution, but I don't really understand what is happening (I looked >> > at >> > the code of RODFNet::buildEdgeFlowMap). >> > >> > So my questions are: >> > 1) Can someone explain to me how DFRouter computes the number of >> > vehicles >> > per route? >> > 2) How large can the errors become, are there any garantuees under >> > certain >> > conditions? >> > 3) Will the computation of vehicles per route be improvement in the >> > (near) >> > future? >> > >> > Best regards, >> > Pieter >> > >> > ------------------------------------------------------------------------------ >> > Learn Graph Databases - Download FREE O'Reilly Book >> > "Graph Databases" is the definitive new guide to graph databases and >> > their >> > applications. Written by three acclaimed leaders in the field, >> > this first edition is now available. Download your free book today! >> > http://p.sf.net/sfu/13534_NeoTech >> > _______________________________________________ >> > sumo-user mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/sumo-user > > ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ sumo-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sumo-user
