Committee Report 2013 Sep

Owned by Michael Zilske
Last updated: Feb 28, 2024 by Joschka Bischoff

MATSIM-97 - Getting issue details... STATUS

MATSIM-75 - Getting issue details... STATUS

All routes should have expected travel time and expected distance as required attributes, to be calculated by a router. They will be written to XML. These attributes will be removed from the Leg. Routes should be considered immutable. The fact that, at the moment, a Route is typically created with only start and end link, with the path only set later as an attribute, has technical reasons related to the replacibility of the implementation of the data type (e.g. is the path stored in a compressed form or not). It is not meant to be used for actually modifying a Route object more than a few lines of code away from its creation. At least not for Routes which are in Plans which are in Persons which are in a Population which is in a Scenario. So the standard Route implementations should be made immutable and the setters removed.

All routes should have start and end link id as required attributes, which will be written to the XML, and not guessed based on previous or later activities.

 

MATSIM-60 - Getting issue details... STATUS

MATSIM-119 - Getting issue details... STATUS

MATSIM-65 - Getting issue details... STATUS

Changes to defaults: Plan memory size to 5 (from infinite), BrainExpBeta to 1.0 (from 2.0)(will possibly be renamed to "mu"), removeStuckVehicles to false (from true), time after which a vehicle is considered stuck to 10 seconds (from 100).

 

MATSIM-146 - Getting issue details... STATUS

QSim is going to be the default MobSim. QSimConfigGroup is going to become a "normal" default config group with the usual syntax. The current "simulation", which is the QueueSimulation, will be renamed and put to the same status as the JDEQSim.

 

MATSIM-68 - Getting issue details... STATUS

We are not too happy about the current way custom scenario elements are added (by class), which seems to be a slight misuse of the Java class concept: For instance, if one had added an X, and wanted to add another X later (with a special, different meaning), then one wouldn't be able to use the same class for that (or even a subclass). We would prefer a simpler, map-like interface where an Object can be added under a String key. 

 

 

MATSIM-124 - Getting issue details... STATUS

We think that semantically conflicting Config parameters should be reported by a ConsistencyChecker, but not automatically adjust themselves to the nearest permissible point, or similar. Of course, one should try to design config options as orthogonal as possible.

 

MATSIM-111 - Getting issue details... STATUS

Contribs or other extensions can access their custom config groups like this:

OTFVisConfigGroup oc = (OTFVisConfigGroup) config.getModule("otfvis");

Existing config groups which configure things which are not part of the core are removed and do not get a custom accessor method.