Mode share handling by activity about elara HOT 9 CLOSED

Option 1:
We add a new mode share plan handler that considers the destination (and origin?) activity type as a filter.

Option 2:
We add the above functionality to the existing mode share plan handler.

Option 3:
Similar to option 1 but using a post process handler. the post processor could use the trips log output.

I am strongly in favour of option 1. Suggest we call it ActivityModeShare and that the config will be as follows:

activity_mode_share = {activities = ["work"]}

from elara.

I think Option 1 looks really good! Would it be ok if I had a crack at implementing this?

from elara.

great! - I will have a go at 118

from elara.

... so I discovered the existing modeshare handler already provides a breakdown ("groupby") by destination activity here.

I would still like to see a dedicated handler that does a filter rather than groupby. Both for clarity and speed. But the code is somewhat reusable.

from elara.

review of the current status of handler configurations:

• unique handlers are generally associated with unique types of aggregation
• all handlers are passed a unique mode. The modes are passed as a list in the config, eg:
  link_vehicle_counts = ["car", "bus"]
  or link_vehicle_counts = {mode=["car", "bus"]}
• although in some cases (typical for plan handlers) mode is irrelivant so passed as "all", the intention is to factor this out as a None default.
• there is now the option to pass more options to handlers via a toml dict
• this has been implemented for the duration and distance bms, which use benchmark_data_path to load bm data from beyond the project, eg:
  duration_comparison = {modes = ["all"], benchmark_data_path = "./tests/test_outputs/trip_duration_breakdown_all.csv"}

from elara.

Thinking about avoiding future confusion, in the current setup:

handler = {modes = ["car, bus"], optional_arg = "./tests/test_outputs/trip_duration_breakdown_all.csv"}

modes is special because it is a list that causes elara to spin up unique handlers, eg a link_counter for both cars and buses.

modes also has a handy shortcut syntax: handler = ["car, bus"]

If we allow any other options as lists the assumption should be that these do not (i) cause unique handlers for each value and (ii) have no shortcut syntax in config.

For example:
activity_mode_share = {activities = ["work", "business"]}

...would run a single handler that would filter for both "work" and "business" activities (not two seperate handlers doing each).

This would also not be possible: activity_mode_share = ["work", "business"] because it would be interpretted as modes.

We might be able to fix the latter case in future.

Also to be pedantic i think this will not be possible:

activity_mode_share = {activities = ["work", "business"]}
activity_mode_share = {activities = ["home"]}

...the latter will overwrite the former.

from elara.

Would it make sense with the current structure of Elara to create a wrapper / parent function which essentially loops through each activity provided to the activity_mode_share handler, filters the activity based on that and apply the mode share handling to it?

from elara.

my preference is the new handler be stand-alone. There will be duplication of code - but also clearer structure. Commonly used methods (such as identify trip mode) could be moved to the parent PlanHandlerTool parent.

But ultimately I'd be pleased to see someone elses take on how it can fit in.

from elara.

This is now addressed by the new mode_share_comparison benchmark.

from elara.