I am starting to work on a new population format as a part of MATSIM-847. This issue is to document and discuss the decisions relative to it.
changes compared to the v7 are currently:
add a waypoint element
add a subpopulation attribute to persons
add a "routingHandler" attribute to legs
I will try to keep the development of the file format in a separate branch, to allow code reviews independent of the Waypoint implementation. Not sure how much this will work. The branch should be listed on the right of this issue once it is pushed.
I would prefer to to have both mode and routingHandler mandatory. It just makes the whole thing more explicit.
And from the perspective of the QSim, it's not clear that if the mode is missing, the value of the routingHandler should be used e.g. to find the DepartureHandler.
For me, the mode is an important piece of information of the leg itself and should not be made optional, even if it results in having attribute-values duplicated.
Good point. I mostly thought in it with the usecase of empty legs in the initial population: there, the mode only has the purpose to say what router should be used, and I could not really decide what a good "mode" value would be. I did not think in having no "mode" on a "routed" trip.
Still unsure what the best is (force to have a mode on empty legs vs. have the risk of having legs with routes but no modes)
Good point with the initial population. Technically, only the routingHandler would be necessary in that case, indeed.
I'm not sure what's easier to understand for the user: Specifying a mode the leg should use, or some abstract "routingHandler", in the initial population. Currently, the leg-mode seems easier to understand, but that's probably just because it used to be that way in the past.
So, for me it's okay to say that "mode" is optional in the file-format, but is required by the mobsim. Any leg where the mode is missing first needs to be handled by a router (e.g. in PersonPrepareForSim). I just don't want the mobsim to start guessing the leg-mode based on the routingHandler.
While working on intermodal pt routing I started wondering how we would actually implement the routingHandler attribute. E.g. when an intermodal pt router would calculate a drt -> pt -> walk route it ideally should simply call the drt router for the drt leg and the walk router for the walk leg and calculate the pt leg in between itself.
So either it takes the drt leg from the drt router and modifies the routingHandler attribute of these legs or we have to pass the routing mode to the drt router (which somewhat confusingly would be "pt" although we ask for a drt route).
If something goes wrong we have different routingHandler attributes in the legs of that single trip and no clue which one is right.
I know that the idea of a trip element was rejected a couple of years ago, but it would make life much easier here:
A trip would have the routingHandler attribute only once, so we save the same piece of information only once and not multiple times and thereby obtain an unambigous routingHandler attribute. There is no need to tell the router which routingHandler attribute it should write into the legs.
Instead of unrouted legs we could simply have an empty trip which has only the routingHandler attribute and no legs.
Implementing a trip element does not mean that we would need to allow subtrips.
We eventually came back to this and introduced an attribute "routingMode" at legs PullRequest738. The TripRouter adds the "routingMode" attribute, so this is done by central infrastructure. PersonPrepareForSim checks for consistency, i.e. having the same routingMode all over the trip.
That solution seems ok, maybe in the long term we can come up with something better (but harder to implement, such as the trip element).