CityScope / CS_Cooper-Hewitt

meta repo/sandbox repo for keeping everything related to the Cooper Hewitt exhibition
5 stars 2 forks source link

Simulation has function for agent mobility choice #41

Closed aberke closed 5 years ago

aberke commented 5 years ago

(previously discussed in meeting with Ronan, Alex, Yasushi, Arnauld)

One of the outputs of the https://github.com/CityScope/CS_activityBased script is a function representing a mobility choice decision tree for an agent. It is here: https://github.com/CityScope/CS_activityBased/blob/master/results/mode_choice.py

Ronan produced this with the idea that the mode choice for the agent is determined by the array of probabilities returned by this function.

0 1 2 3
driving cycling walking public transit

This function is produced by fitting a model to the NHTS real world data. A different function with lower numbers for driving and higher numbers for cycling and walking would need to be used for the 'good/shared' world.

The idea was that this function would be copied into the simulation code.

@yasushisakai @agrignard are we still on board with this plan? If so, the function needs to be modified for the simulated world that has only driving, cycling, and walking, and not public transit. I can modify is so that it only returns probabilities for the simulation's 3 transit modes: driving, cycling, walking

One way to do this is to modify the decision tree classifier code so that it only uses data from people who use driving, cycling, or walking.

doorleyr commented 5 years ago

If public transit is not going to be included in the simulation, we can just remove these trips from the NHTS data before fitting the decision tree model as suggested by Alex. Then the mode choice predictions will be given as a vector of probabilities: [driving, cycling, walking].

As for the alternative scenario, this depends on what exactly the scenario is supposed to represent (design team needs to contribute to this decision).

But if, for example, we decide that in the future scenario there are 4 modes [driving, cycling, walking PEV] and

Then, we can get the new vector of probabilities as A * b

where b is the column vector of length 3 returned by the decision tree and A is a matrix with 4 rows, 3 columns:

A = [[0.5, 0, 0], [0, 0.5, 0], [0, 0, 1], [0.5, 0.5, 0]]

Thoughts?

aberke commented 5 years ago

Alternative proposal:

In the story, the main difference between the 2 worlds is that AVs are private or shared. In terms of what this visually looks like in the simulation, this can mean:

Idea for technical implementation:

The probabilities vector returned by the decision tree function is [driving, cycling, walking, shared*]

Where

If an agent chooses shared* when it is time for them to travel, then their travel is not visually simulated. This visually results in less congestion in the "good world".

Like Ronan and I discussed, the decision tree can then be fitted to data that contains data for [driving, cycling, walking] in order to have the "bad world" modeled on current mobility choices, and then the shared entry is added.

yasushisakai commented 5 years ago
  • Bad world: driving chosen more often, much congestion, no agents use shared transit
  • Good world: driving chosen less often, less congestion because agents often share transit

the above message is true for the simulation. To be comprehensive, Good world thus gives us more surface area(less parking), which we feel that will lead to more diversity(???) and density among land/building usage. I don't know if the two worlds has different population. Diversity is an speculative design portion mainly expressed by the top projection.

so,

If an agent chooses shared* when it is time for them to travel, then their travel is not visually simulated.

we don't know if want to hide too much agents. give a new icon?


different perspective. is it weird if we mentally interchange transit to shared ? .. am I understanding well enough ?

yasushisakai commented 5 years ago

Not fully implemented, yet we have a dummy function to decide between different mobilities in Agents.pde chooseMobilityType()

I suggest we leave it as is for this deployment.