Hallo Pieter, Daniel,
Just to jump in here, without fully understanding what's going on...
You don't have probabilities in your output ("emitters-output") file? Like this:
<additional>
<routeDistribution id="Junction1_du_0">
<route refId="143033383#1_to_196306586" probability="0.16"/>
...
</routeDistribution>
<vehicle id="emitter_Junction1_du_0_0" depart="0.00" departLane="0"
departPos="-100.00" departSpeed="9.08" route="143033383#1_to_41866858"/>
...
What we have found here (at least after the improvements, which were checked in
at the weekend, and there are more coming) is that the probabilities given
match reasonably well with the vehicles emitted. So if we have twice
probability = 1.00, we see probabilities of ~0.45/0.55 in the emitted vehicles.
The vehicle emissions are done following some distribution model, so we can't
expect them to be quite correct.
For me the bigger issue is that SUMO can already do this based directly on the
routeDistributions, like this:
<routes>
<routeDistribution id="RouteDist_for_0">
<route id="1_to_2" edges="1 2" probability="1.0"/>
</routeDistribution>
...
<flow begin="0.0" end="9999.0" id="0_0" route="RouteDist_for_0"
vehsPerHour="2000"/>
...
</routes>
So I see no need to output the individual vehicles - its duplication of the
vehicle departing code and makes for really large files.
Regarding the MATLAB script, maybe you can send it so it can at least go in the
tools folder, maybe I or someone else could port it to Python.
Thanks,
Matthew
> -----Ursprüngliche Nachricht-----
> Von: Daniel Krajzewicz [mailto:[email protected]]
> Gesendet: Mittwoch, 12. März 2014 12:53
> An: Pieter Loof
> Cc: Fullerton, Matthew; sumo-user
> Betreff: Re: [sumo-user] DFRouter - poor vehicle flow distribution
>
> Hello Pieter,
>
> Ok. We are using Python, here, and I have never seen Matlab running :-)
> While collaborating with Matthew and his student, I have to put some time
> into a similar evaluation thing, that's why I asked. I will try to implement
> something and will let you know - but it won't be fast, as this is basically
> not a
> part of any paid project.
> I found the probabilities in the routes file, I think.
>
> Sincerely,
> Daniel
>
>
>
> 2014-03-12 12:46 GMT+01:00 Pieter Loof <[email protected]>:
> > Hi Daniel,
> >
> > Thanks for the explanations so far. Regarding how I compared the real
> > data with the simulation: I ran a SUMO simulation with the vehicles as
> > created by DFRouter, I used the flag --validation-output to let SUMO
> > produce the number of vehicles passing each detector per minute. Then
> > I ran a script that sums up these results per five minutes and that
> > writes these aggregates values to a file, accompanied by the values
> > from the measurement file as given to DFRouter. Then I used Matlab to
> > compute the sum of vehicles for each detector and I generated plots.
> > From a plot for the source detector I see that the vehicle flow that
> > is generated there mimics the real data almost exactly. For the other
> > detectors the form of the graphs show similarities too. These results
> > tells me that DFRouter generates the vehicles correctly and that my
> validation script is likely correct.
> >
> > I see why I didn't saw the error in the probabilities yet: I cannot
> > find these probabilities at all, they are not in the route file or vehicle
> > file.
> > By the way, I forgot to mention that I used the svn version of
> > February 20 for the problem scenario of this thread.
> >
> > Greetings,
> > Pieter
> >
> >
> > On 12 March 2014 00:23, Daniel Krajzewicz <[email protected]>
> wrote:
> >>
> >> 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
