Trips in "demandsimulationResult.csv" are only a few meters long

[paul019]

I cloned this git repository and – without changing anything – ran ./gradlew runPopulationSynthesis runSimulation in the project directory.

After going through the output and results folders I quickly identified results/simulation/demandsimulationResult.csv to be the output file of my interest. This file contains approximately 40.000 rows with each row describing one trip of one person including start time, end time, start geopoint and end geopoint.

However, after going through the first couple of rows of this file I quickly identified a problem: The start geopoint and the end geopoint always only lie a few meters apart from each other. To confirm this problem on a larger scale (I could not go through 40.000 rows manually), I imported demandsimulationResult.csv into Apple Numbers. Next, I added conditional formatting to the column distanceInKm to determine whether any trip has a distance of more than 1 km. As it turned out, no trip has.

If I understand mobitopp and its outputs right, this result is not intended: One trip should represent the way of one person from one place to another. Thus, trip distances of a few meters don't make any sense.

In conclusion, there are several possibilities why I experienced this issue:

1. I did something wrong using mobitopp. In this case, I would love to get some feedback.
2. mobitopp does not run out of the box and needs some more input files to work correctly. In this case, I would love to know what input files it needs.
3. This is an issue on the part of mobitopp.

In general, I am missing documentation for mobitopp. As stated in README.md, the outputs of mobitopp are quite self-explanatory. However, what is not self-explanatory are the inputs that mobitopp needs.

I am looking forward to an answer and attached my demandsimulationResult.csv file.
demandsimulationResult.csv

Regards,
Paul

[maocatherine]

I visualise the coordinate pairs from demandsimulationResult.csv file in a map and measure their actual distance. Most of them are more than 1km and they make sense (given the purview is around 4.5km * 4km). The number of distanceInKm seems to be converted to km twice.

The distance matrix looks like in km. And when writing the result they are divided by 1000 again, see edu.kit.ifv.mobitopp.simulation.TripfileWriter line 131.

I also urge some proper documentation of the input. Especially the matrix file!!!!!!

Cheers,
Cath

[JelleKuebler-IfV]

Hello Cath and Paul,

The distanceInKm is a known Issue and is supposed to be fixed with the next release.
If I remember correctly, the input matrices used to be in meters. So when they are provided in km, the labeling distanceInKm is incorrect and the written results are shifted by an order of magnitude. However, this should only affect the representation in the output file.

Running ./gradlew runPopulationSynthesis runSimulation starts the synthesis and simulation of a small example model of Leopoldshafen. Due to the rather samll dimensions of the model, the geo-coordinates might seem closer than expected.

Addressing the matrix (.mtx) input format:
The matrices imported by mobiTopp are distance-, traveltime- or cost matrices exported from a PTV VISUM model/network which is currently required to run mobiTopp as it holds the traffic zones and road network.

The files in example/data/leopoldshafen are example files that are used for synthesis and simulation. I will put together a short summary of the required files and post it here.

If there are any other questions, feel free to contact me.

Best,
Jelle

[JelleKuebler-IfV]

Here is a rough summary of the required files:

1. Long-term module
   MobiTopps long-term module generates a synthetic population for each zone, consisting of households, persons and cars.
   These are drawn from a population pool provided by a survey or panel (e.g. MiD or MOP in Germany).
   Demography constraints can be specified to indicate the distribution of e.g. household size, age X sex, employment etc. throughout the modeled zones.

   Therefore the following data is required:

   • A PTV VISUM net file holding the zones and road network
   • A population pool
   • Demography constraints (e.g. household size, age x sex, number of cars, employment) on zone level (district, community or county level are also possible)
   • Attractivities of the zones for different activity types like 'work', 'shopping', etc.
   • Travletime-, distance- and cost matrices for different modes of transportation
   • Properties of bike/car sharing providers in the survey area (if needed)

   Additionally, other synthesis steps can be added e.g. to include membership models for mobility providers, or a commuter ticket model which may require model parameter files depending on the concrete model.

2. Short-term module
   The short term module simulates each persons activity schedule (generated in long-term module) simultaneously.
   Before each activity, a destination and a mode of transportation are chosen.
   For both choices, mobiTopp provides interfaces so that a custom choice mocels can be used. However, mobiTopp also provides several predefined basic choice models.

   The simulation requires:

   • The files required by the long-term module
   • The files generaterd by the long-term module
   • Choice model parameter files depending on the used models

[maocatherine]

Hi Jelle,

Thanks for the elaboration. I've got one more question. What is data in distribution.work.mtx? From papers they are used to match with poledistance in the panel data so fixed location is allocated based on the pole distance. But the number in matrix file looks very confusing. Could you please explain?

Cheers,
Cath

[JelleKuebler-IfV]

Hi Cath,

The rows in distribution.work.mtx describe the distribution of commuting persons from on zone to the other zones.
The reported pole distances in the panel data are matched with the (rounded) distances in the distance.car.mtx file.
The values given in distribution.work.mtx are scaled to the population size of the respective zone.

Best,
Jelle