|
SUMO - Simulation of Urban MObility
|
|
SUMO - Simulation of Urban MObility
|
Recheck whether this class could be replaced by a "normal InputDevice"
Maybe some kind of a well-defined types should be used (so that they have a well-defined length)
Maybe the byte-order should be defined
recheck/describe what happens with characters when a new element is opened
describe characters processing in the class' head
recheck/describe encoding of the string-representation
do not generate and report the string-representation
recheck/describe encoding of the string-representation
do not generate and report the string-representation
Consider using a reference to the table
Check whether the name should be stored in GUIParameterTableItemInterface
Consider using a reference to the table
Check whether the name should be stored in GUIParameterTableItemInterface
Should never be dynamic!?
Consider using a reference to the table
Check whether the name should be stored in GUIParameterTableItemInterface
Should never be dynamic!?
This is partially unsecure due to concurrent access...
Recheck vehicle deletion
No checks are done so far during reading/setting position etc.
Should not IOError be thrown if something fails?
| IOError | If an error on writing occurs (!!! not yet implemented) |
evaluate signature
update interactionGap logic to IDM
update interactionGap logic to IDM
Rechek usage of the lane change model
probably, more things should be checked...
Complete work on pass position
Join with MSLane
Recheck return value
What exceptions may occure?
| IOError | If an error on writing occurs (!!! not yet implemented) |
| IOError | If an error on writing occurs (!!! not yet implemented) |
Recheck whether a visitor-pattern should be used herefor
Recheck usage
Recheck whether a visitor-pattern should be used herefor
Recheck usage
Removing unwished edges: Recheck whether this can be done during loading - whether this option/step is really needed.
Finding isolated roads: Describe
There is no interaction with explicit node setting options? Where is this done?
Check whether throwing an exception is really necessary, here
revalidate node retrieval
One day, one should rethink the order of parsing. Now, the handler is able to load edges, using information from the types, first, and extending them by given information. In addition, if the read edge is already known, it's values are also used. Then, defining vehicles allowed per lane, and additional edge split definitions add some further complexity. This all works somehow for most of our use cases, but it's definitely not as consistent that everything what seems to be possible would also work appropriately.
Options are only given to determine whether "flip-y" is set; maybe this should be done by giving a bool
Why are options not const?
Refactor this class - it's too large
Resort method by one of the topics.
Where are these parameter used? Describe!
Can a parameter be overwritten?
min/max is used only by one junction type. Recheck
min/max: maybe only one type of a phase definition should be built
Throwing ProcessError would get unneeded if the container would be built by default (see prepare)
The type of the junctions shoould probably be checked when supprted (in openJunction)
Why is the type not verified?
Recheck, describe usage of detectorOffset (where does the information come from?)
| InvalidArgument | If one of the referenced structures was not found or is invalid |
Check which parameter is used herein
Describe what is saved
Why is the container given? Everywhere else not...
probably, more things should be checked...
Check whether a const pointer may be returned
Rename myRoutes to myRouteDefinitions
The edge is "built" first, then the nodes are added; should be done while constructing, probably a legacy issue
No exception?
In fact, the junction should be built given its position.
No exception?
1.7.3 
