Divide GNEChange_Additional in subclasses (trac #2912)

[behrisch]

Due a problem found in Ticket #2885, is neccesary to divide the GNEChange_Additionals into differentes GNEChanges, every for a type of additional:

• GNEChange_Calibrator
• GNEChange_Detector
• GNEChange_Rerouter
• GNEChange_StoppingPlace

The reason is that every type of additional has different dependences (Lanes, Edges, anther additionals, etc..) and this cause problems during Undo/Redo.

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

{
    "status": "closed", 
    "changetime": "2017-04-25T07:15:13Z", 
    "description": "Due a problem found in Ticket #2885, is neccesary to divide the GNEChange_Additionals into differentes GNEChanges, every for a type of additional:\n\n- GNEChange_Calibrator\n- GNEChange_Detector\n- GNEChange_Rerouter\n- GNEChange_StoppingPlace\n\nThe reason is that every type of additional has different dependences (Lanes, Edges, anther additionals, etc..) and this cause problems during Undo/Redo.", 
    "reporter": "pablo", 
    "cc": "", 
    "resolution": "invalid", 
    "_ts": "1493104513426651", 
    "component": "netedit", 
    "summary": "Divide GNEChange_Additional in subclasses", 
    "priority": "major", 
    "keywords": "GNEChange", 
    "time": "2017-03-03T13:33:13Z", 
    "milestone": "0.30.0", 
    "owner": "pablo", 
    "type": "defect"
}

[behrisch]

@namdre commented:

Why can the different dependencies not be handled by triggering additional GNEChange_* objects at the time of modification/deletion/creation? I would discuss this before making major redesigns.

[behrisch]

@palvarezlopez commented:

Finally GNEChange_Additional will not be divided into subclasses. Instead all cases will be implemented in GNEChange_Additional.h/.cpp

[behrisch]

• @palvarezlopez changed resolution from "" to "invalid"
• @palvarezlopez changed status from "new" to "closed"

[behrisch]

@behrisch changed milestone from "1.0.0" to "0.30.0"