facility ids

Description

I keep coming back to this because it is really awkward to use. Maybe we took a wrong turn there, and should consider recitifying it.

The current problem is that we have

The consequence is that we cannot put an Id<TransitStopFacility> there. But that is what we would need, since we have an access walk to that stop facility, a drt interaction activity at the stop facility, and then a drt trip from there.

The problem, evidently, is that

but not

I am also unable to find an alternative; e.g. a signature

leads nowhere.

I can see two alternatives:

(A) a common facility ID space. I have argued for that many times; I want to make my argument again.

The change would be

and fix the fallout.

One issue with that is that facility IDs then would need to be unique across several containers (ActivityFacilities, TransitStopFacilities, ...). This is, however, something that would be necessary anyways if the activity wants to point to, say, a transit stop.

The mechanism to get there is clear, since for Vehicle we have the same thing: There is CarrierVehicle, DrtVehicle, plain Vehicle, TransitVehicle. The mobsim reads all of them, and complains when an ID is repeated.

(B) move Id from generics to inheritance. I think in retrospect that that would have been the better option. There are two reasons:

(I) With that, Id inheritance would have the same properties as object inheritance. E.g. if

then also

Which would mean that the Ids could follow the same inheritance scheme as the object, no longer causing problems every time we switch from Objects to the Ids (which we always do when we reference between containers).

(II) Another advantage of using Id inheritance would be that there is no type erasure: Once the Id is generated with the correct type, that type can always be recovered. That is, we would need to make sure that createPersonId, createVehicleId, etc. generate the correct type in the first place, and everything that follows is less critical.

Quite possibly, given the state of the project, alternative (B) is too much heavy lifting, and the concrete benefits are unclear.

But I am convinced we should do (A). And it would go along with a decision to have "flat" ID spaces in all matsim containers even if they use inheritance. I.e. if at some point we inherit from Person, the id should still be Id<Person>. Or if we want to introduce IDs for Activity, the signature would have to be Id<PlanElement>.

Environment

None

Assignee

Gregor Leich

Reporter

Kai Nagel

Labels

None

Priority

Major
Configure