Hello, 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. 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.
Now, all your suggestions of fixing this do not work in my case. I already use speed factors and distributions for vehicle types. The problem with trucks is that their global speed limit is 80 in my case and setting a speed factor of 0.6 would mean that they drive close to 80 when the limit is 130, but when the limit is 100 the trucks would drive only 60 instead of 80 and the same problem applies to all lower speed limits. Because I do not want this behaviour, I cannot set the speed factor to a lower value. So instead I set the maximum speed of trucks to 80. My trucks also have a speed factor and distribution, but a starting speed above 80 will now always fail because of the maximum speed for trucks. So using a speed factor and distribution results in unwanted behaviour and therefore it is not a solution for me. 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. The only thing I could think of is to define trucks in a separate vehicle type LKW. Then I could make a script that goes through the generated vehicle file and that for each vehicle it changes it's type to LKW with a certain probability, and changes the speed accordingly. This is not so hard to implement, but then I'm actually performing tasks that are implemented in the SUMO command as well. 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. 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. Best regards, Pieter ------------------------------ > > Message: 6 > Date: Mon, 17 Feb 2014 07:57:37 +0100 > From: Michael Behrisch <[email protected]> > Subject: Re: [sumo-user] Vehicle departspeed: detector value vs > maxSpeed > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Pieter, > > Am 04.02.2014 15:03, schrieb Pieter Loof: > > When I use the detector speed measurements as departure speed of cars, > the > > simulation quits with an error on startup, because DFRouter created > trucks > > with a departure speed that is higher than the maximum speed of trucks. > An > > alternative to avoid this error is to use the flag "--departspeed max", > but > > then SUMO will ignore the speeds from the detector measurement files, > right? > > That's right. > > > So I hope that a solution will be implemented which uses the detector > > readings for the depart speed of vehicles, but with automatic fixes for > the > > maximum speed of vehicles. The actual vehicle types are decided when > > running SUMO or SUMO-GUI, so on the moment of insertion the maximum of > the > > stored speed and the vehicle's maximum speed should be taken instead of > > quitting with an error. > > There is already a method to achieve something similar, which includes > using speed distributions. If you specify in the vehicle type a > speedFactor (which acts as a multiplier to allowed speed on the lane) > and a speedDeviation (acting as a relative standard deviation to the > value above), sumo will calculate a vehicle specific factor how the > vehicle tends to obey the speed limits. If this factor does not fit the > departure speed it is recalculated. > > The reason why we probably won't implement the direct fix you mentioned > is, that if your vehicle has a departure speed which is higher than > its maximum speed then there is obviously something wrong with your > configuration because the vehicle's maximum speed should never be > exceeded. We should implement something which draws again from the > vehicle distribution if the depart speed does not match the maximum > speed, but for the moment it is probably easier if you run a little > script on the generated route file which fixes the vehicle type > depending on the depart speed. (In fact, we already have this script, if > you want we can share it.) > > Best regards, > Michael > > ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ sumo-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sumo-user
