Hi Pieter, Am 2014-02-17 10:39, schrieb Pieter Loof: > I use DFRouter to generate the vehicles from detector definitions. > Those > detectors usually record all vehicles together, so they do not > distinguish > different vehicle types.
That really depends on the detector you use. Most of the motorway detectors we use can differentiate between cars and trucks. > This means that if I use the "--vtype" flag, then > all vehicles will have type "PKW". Because I want to have a nice > randomization of vehicle types, including trucks, I defined vehicle > type > PKW as a distribution which contains all my vehicle types. This seems > to be > the only way of generating vehicles that seems logical in this case. No, if you know that some vehicles can't be trucks because they are too fast, they should not be drawn from a distribution containing trucks. > Now, all your suggestions of fixing this do not work in my case. I > already > use speed factors and distributions for vehicle types... I understand. speed deviations won't work here. > The other solution you name is fixing the speed after the vehicle file > is > generated. This also is not straight forward, since in the vehicle > file all > vehicles have type PKW and I do not know in prior which of these > vehicles > will (by the random seed) become trucks. But you know which vehicles can't be trucks. You could simply define a second distribution "fast" containing all the vehicles which are fast enough and assign this distribution to all vehicles which are too fast to be trucks (via an intermediate script between routing and simulation). > You said that departure speeds that exceed the maximum speed of > vehicles > could be considered a flaw in my configuration. But I hope that I made > clear with my explanation above that the configuration that I use now > is by > far the most reasonable choice when the data comes from loop > detectors. So > this is the reason I ask for the possibility to let SUMO fix the > depart > speed instead of producing an error. I understand that in other cases > the > error would be the better option, but maybe a flag could be added for > this > to the SUMO command. I opened a ticket here: http://www.sumo-sim.org/trac.wsgi/ticket/1154. I am still undecided whether it is better to solve this in the router or in the simulation. > In an other reply I was told that I could also contribute to the > documentation myself. I wonder how I can do this, because maybe I then > would do it now and then. The sumo documentation is generated from the wiki http://sumo-sim.org/wiki/ and we very much welcome contributions :-). You can try to use an OpenID-Login (for instance a Google account) and notify us such that we give you the editor rights or you tell us your favorite login name and we create an account for you, if you wish. (Sorry for the hassle but we need this to prevent account creation spam.) The short documentation for the command line options is generated from the source code. Here you will need to send a patch. Best regards, Michael ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ sumo-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sumo-user
