Add support for Vehicle Fleet Composition in routeSampler.py?

[mschrader15]

Hey All,

Another feature suggestion... Could we add variable "fleet composition" to routeSampler.py? I am envisioning the input file to look something like this:

   <interval id="interval_5400.0" begin="5400.0" end="6000.0">
      <fleetComposition vehTypeDist1="0.7" bigTruckDist="0.1" smallCarDist="0.2">  
      <edgeRelation from="660891910#1.19" to="638636924#1" count="3.0"/>
      <edgeRelation from="-638636924#1.9" to="-660891910#1" count="3.0"/>
      <edgeRelation from="660891910#1.19" to="834845345#6" count="4.0"/>
      <edgeRelation from="-638636924#1.9" to="115872656#11" count="5.0"/>
      ....

Then the resultant routes in specified period will have the "types" assigned with the specified probabilities.

Like #8835 , I'll be happy to add the functionality if SUMO team thinks it will be useful!

Best, Max

[mschrader15]

I suppose that it will only work for --write-route-ids in https://sumo.dlr.de/docs/Tools/Turns.html#output_styles

[behrisch]

I don't quite get it. What is the advantage over defining a single vtype distribution?

[mschrader15]

We have information that the fleet composition changes throughout the day

[behrisch]

I don't think it is useful. The vType should be part of the vehicle definition and therefore be part of the (input) route file. I would not mix it with (turn) counts but I am leaving this open for discussion.

[mschrader15]

Our workflow with routeSampler is such:

1. Pull detection events from a central database where traffic light "events" are logged
2. Turn detection events into turn counts with custom scripts
   • Equate simulation time with real world time
   • Aggregate in X time intervals (~10 minutes).
3. Feed turn counts and random routes into routeSampler

In my opinion, each turn count interval could point to a specific "vehDist" file, each with different fleet compositions.

Is there a different tool that allows users to change the vType over "time" in a route file?

[namdre]

I agree with @behrisch that this isn't useful enough in light of the alternatives.

Simply change the 'type' attribute for the written vehicles. Presumably you are setting the type via option --attributes so you can just vary this argument in your calls to routeSampler over the course of the day instead of setting it via new file attributes.

Does that capture your use case?

[mschrader15]

I only make one routeSampler call (by passing in a turn count .xml with more than one time interval), so using --attributes wouldn't work for the time-varying distribution.

I will just make a script to parse the routeSampler generated route file and change the type based on time.

[namdre]

Might it be easier to call routeSampler multiple times? At the moment the intervals do not interact and you can easily load multiple route files into sumo.

Once #7427 is in, time varying vehicle attributes might actually be needed though. Instead of inventing custom attributes that are named like vehicle types (which would go against all our current xml conventions) I would propose the following:

<interval id="interval_5400.0" begin="5400.0" end="6000.0" type="morningDist">
   ...

You could then load a single type distribution that is composed as needed.
Right now nested vTypeDistributions aren't supported directly but this would actually be a nice feature: #8902

@behrisch

The vType should be part of the vehicle definition and therefore be part of the (input) route file. I would not mix it with (turn) counts but I am leaving this open for discussion.

Only the routes are parsed from the route file at the moment (standalone routes are permitted) and it might not be feasible to generate an input route file that contains vehicles with the proper time-varing type distribution and the correct routes (candidate routes are typically coming from randomTrips).

[behrisch]

I would rather separate this completely and invent time dependent vehicle type distributions which might be useful on their own and separation of concerns is a nice thing to do ;-).

[namdre]

This hypothetical new element would have distributions as it's child elements and might also be used to solve #8902

<vTypeDistribution id="morning">
   <vType id="car" probability="0.8"/>
   <vType id="truck" vClass="truck" probability="0.2"/>
</vTypeDistribution>
<vTypeDistribution id="evening">
   <vType id="car" probability="0.6"/>
   <vType id="truck" vClass="truck" probability="0.4"/>
</vTypeDistribution>
<vTypeDistribution id="buses">
   <vType id="bus" probability="0.5"/>
   <vType id="bus2" probability="0.5"/>
</vTypeDistribution>

<vTypeTiming id="dailyTypes">
  <interval begin="0" end="12:0:0">
     <vType refId="morning" probability="0.9"/>
     <vType refId="busses" probability="0.1"/>
  </interval>
  <interval begin="12:0:0" end="24:0:0">    
     <vType refId="evening" probability="0.9"/>
     <vType refId="busses" probability="0.1"/>
  </interval>
</vTypeTiming>

In contrast to a vTypeDistribution which has a RandomDistributor for SUMOVTypeParameter, the vTypeTiming would be a list of intervals and each interval is a RandomDistributor of type ids. Lookup would be a 3-step procedure:

1. retrieve interval
2. sample type id
3. MSNet::getInstance()->getVehicleControl().getVType(vtypeID, &myParsingRNG)

Instead of of using <vType refId="..." .../> (similar to routeDistributions) we may wish to add a new element <vTypeRef id="..." ../> to simplify the schema and parsers.

[mschrader15]

I personally like the "nested" <vTypeRef id="..." ../> quite a bit from the user's side @namdre .

Thanks for taking my rough suggestion and polishing it into something useful!

[namdre]

reclassifying milestone based on perceived urgency (including invitation for disagreement).