README.md 7.13 KB
Newer Older
Sebastian Hörl's avatar
Sebastian Hörl committed
1
2
3
4
5
# How to run a simulaton with private AVs

Private AVs can be activated via the `private_av` config group:

```xml
Sebastian Hörl's avatar
Sebastian Hörl committed
6
<module name="private_avs">
Sebastian Hörl's avatar
Sebastian Hörl committed
7
8
9
10
11
12
13
14
15
16
  <param name="usePrivateAVs" value="true" />
</module>
```

Likewise, this option can be set via the command line:

```
java [...] --config:private_av.usePrivateAVs true
```

Sebastian Hörl's avatar
Sebastian Hörl committed
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
# How to run a simulation with shared AVs

Shared AVs can be activated via the `shared_av` config group:

```xml
<module name="shared_avs">
  <!-- Defines whather shared AVs are active or not -->
  <param name="useSharedAVs" value="true" />
  
  <!-- Defines the fleet sizes of both services -->
  <param name="taxiFleetSize" value="100" />
  <param name="pooledFleetSize" value="100" />
  
  <!-- Define a shape file for the operating area and zones for waiting time measurement therein -->
  <param name="serviceAreaShapefile" value="path/to/service_areas.shp" />
  <param name="waitingTimeZoneShapefile" value="path/to/waiting_time_zones.shp" />
  
  <!-- Defines the relevant attribute names of the shapes in these shape files -->
  <param name="serviceAreaAttribute" value="SAREA" />
  <param name="waitingTimeZoneAttribute" value="WZONE" />
  
  <!-- Defines which operating area is active -->
  <param name="activeServiceArea" value="true" />
</module>
```

To run such a simulation, two shape files must be provided. The first is a file containing all the service areas for the scenarios (probably there will be exactly one per scenario). The path to that file must be given as the `serviceAreaShapefile` option. The shapes for these service areas must contain an attribute that can be configured via the `serviceAreaAttribute`. Finally, via config one can choose which of these areas is used in the next run by setting `activeServiceArea` to one of the possible values of that attribute, i.e. one selects one service area from this service area file.

Second, a file containing a segmentation of space for waiting time calculation must be given as `waitingTimeZoneShapefile`. Waiting times for the AV services are measured and predicted, for instance, in a grid. If the whole service area is one of these "waiting time zones", all waiting times in the service area will be averaged when predicting waiting times. The format of the shape file is again that each shape should contain an attribute that corresponds to `serviceAreaAttribute`. Only those shapes that correspond to the `selectedServiceArea` will be considered for estimation. The number of shapes for each service area is arbitrary. In any case, each of these waiting time zones gets a unique identifier. The attribute for that identifier is specified in the `waitingTimeZoneAttribute` option.

For the waiting time zones we usually just want some grid-like structure that is covering the service area. For that there is a script in `gis/create_hexagon_grid.py`. It takes a number of command line arguments:

- A path to the shape file containing the actual service areas
- An output path for the new shape file with the waiting time zones
- The name of the attribute that distinguishes between service areas
- The new name of the attribute that distinguishes between waiting time zones
- The horizontal width of the hexagon grid

Example:

```sh
python3 create_hexagon_grid.py path/to/service_areas.shp path/to/waiting_time_zones.shp SAREA WZONE 1000
```

61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
# How to create the partial scenarios

This repository only contains code to run the requested scenarios in the ASTRA 2018/002 project. For the sake of avoiding code duplication, the scenario cutting code is still located in the [baseline_scenario](https://github.com/matsim-eth/baseline_scenario) repository, specifically in the (synpop)[https://github.com/matsim-eth/baseline_scenario/tree/synpop] branch. 

The repository can be transformed into a "fat jar" by calling:

```sh
mvn -Pstandalone package
```

The basis for creating a partial scenario is the full Switzerland scenario in arbitrary sample size. How to create such a full Switzerland scenario is explained in the corresponding (Synthetic populaton of Switzerland)[https://gitlab.ethz.ch/ivt-vpl/populations/ch-zh-synpop] repository. This will create a scenario including `switzerland_population.xml.gz`, `switzerland_network.xml.gz` and so forth.

The `baseline_scenario` code can then be used to cut this population and network to a specific diameter. The relevant run script is `ch.ethz.matsim.baseline_scenario.CutScenario`. It has the following parameters:

- *input-config-path*: Path to `switzerland_config.xml`
- *shapefile-path*: Path to a shape file that contains the scenario boundary
- *shapefile-attribute*: Attribute of the shapes contained in the shape file that defines the scenario id
- *shapefile-value*: Defines which value the given attribute should have (see further below)
- *prefix*: Prefix in the filenames of the generated scenario, e.g. `prefix_population.xml.gz`
- *output-path*: Output path (directory) of the new scenario. The directoy must exist.

The concept is therefore as follows: One has to provide a shape file to the script. The shapes (polygons) in that file all have a specific attribute (e.g. `scenario_id`). Then the script will look up the one specific polygon in that file that has the given `shapefile-value` for that attribute, e.g. `zurich_30km` or similar. This way one shape file can contain multiple scenario diameters, which avoids having a shape file for each of the scenarios.

For ASTRA 2018/002, there is already a shape file in `gis/scenarios/scenarios.shp`. It is created from the initial `Gemeinden_fuer_Raumtypen.shp` using the script `gis/create_scenario_shapes.py`. To create a "ländlich ungerichtet" (lu) scenario, one can call, for instance:

```
java -Xmx100G -cp baseline_scenario/baseline_scenario-0.0.1-synpop-SNAPSHOT.jar ch.ethz.matsim.baseline_scenario.CutScenario --input-config-path switzerland_config.xml --shapefile-path /path/to/gis/scenarios/scenarios.shp --shapefile-attribute scenario --shapefile-value lu --prefix lu_ --output-path lu_scenario
```

# How to create a long-distance scenario

To create the long-distance scenario, the script `ch.ethz.matsim.projects.astra_2018_002.long_distance.MakeLongDistanceScenario` is used. It receives a number of parameters:

- *network-path*: Path to the MATSim network file (e.g. `switzerland_network.xml.gz`)
- *population-path*: Path to the MATSim populaton file (e.g. `switzerland_population.xml.gz`)
- *output-path*: Output path of the long-distance population (e.g. `long_distance_population.xml.gz`)
- *osm-types*: `osm:highway` types that are considered as "long distance roads* (optional, default: "motorway,trunk")
- *threads*: Number of threads to use (optional, by default maximum is used)
- *batch-size*: Batch size in parallel processing (optional, default is 100)

The script will do the following:

1. Route every trip of every person using freespeed travel times
2. Find all persons that touch a link with the given `osm-types` at any point during their daily plan
3. Remove all remaining persons (those not interacting with "long distance roads")
4. Write out the reduced population

For a 0.1% sample that script removed around 1/3 of the agents. Remaining steps to verify the process are: https://gitlab.ethz.ch/ivt-vpl/astra_2018_002/milestones/3


Sebastian Hörl's avatar
update  
Sebastian Hörl committed
111