vehicles block each other after undercutting safety gap (trac #3486)

[behrisch]

there are multiple reasons:

• vehicle width is slightly underestimated when ignoring car-following releated neighbors but overestimated when checking blocking status. Thus a vehicle which is already within the minGap distance (as may happen with aggressive driving) blocks all further movement

• when using ballistic update, negative minSpeed is passed to the patchSpeed() method of the car following model. This is not handled well

Migrated from http://sumo.dlr.de/ticket/3486

{
    "status": "new", 
    "changetime": "2017-10-05T20:21:47Z", 
    "description": "there are multiple reasons:\n\n- vehicle width is slightly underestimated when ignoring car-following releated neighbors but overestimated when checking blocking status. Thus a vehicle which is already within the minGap distance (as may happen with aggressive driving) blocks all further movement\n\n- when using ballistic update, negative minSpeed is passed to the patchSpeed() method of the car following model. This is not handled well", 
    "reporter": "namdre", 
    "cc": "", 
    "resolution": "", 
    "_ts": "1507234907304006", 
    "component": "sharps", 
    "summary": "vehicles block each other after undercutting safety gap", 
    "priority": "major", 
    "keywords": "", 
    "time": "2017-10-05T12:15:20Z", 
    "milestone": "1.0.0", 
    "owner": "", 
    "type": "defect"
}

[behrisch]

@namdre changed description from:

this happens because vehicle width is slightly underestimated when ignoring car-following releated neighbors but overestimated when checking blocking status.

to:

there are multiple reasons:

• vehicle width is slightly underestimated when ignoring car-following releated neighbors but overestimated when checking blocking status. Thus a vehicle which is already within the minGap distance (as may happen with aggressive driving) blocks all further movement

• when using ballistic update, negative minSpeed is passed to the patchSpeed() method of the car following model. This is not handled well

[behrisch]

@namdre committed ed86c25 (aka r26347): dealing with negative minSpeed and with getting away from overlap. refs #3486

[behrisch]

@namdre committed b48eb11 (aka r26348): increased threshold for meaningful lateral change. refs #3486

[namdre]

I think this is fixed (there is no test to contradict this). Hence, I'm closing it.