Facilities or coordinates (or both)

[wese-da]

This came to my mind in the process of scenario generation and calibration. It's an issue about the design of our scenarios, so I'm making this open for discussion.

There are two possible ways of locating activities: Giving them an x-y coordinate or assigning them to a facility.

The biggest advantage of the coordinate method is the simplicity. You don't need additional data or any kind of overhead. On the scenario generation side, however, there is more work to do:

1. Read and store the buildings polygons from OSM data
2. Search for building geometries of type T inside the activity district / municipality of the currently created person / household and randomly choose one
3. Shoot a random coordinate inside the geometry

Steps 1 to 3 are repeated for every activity location (in the best case twice, e.g. home-work-home).

If working with facilities, we could stop after step 2 and just take the coordinate of the facility. Also, we didn't have to store comparatively large polygons but only points. On the data side, we wouldn't have any loss of data despite the exact geometry because you can also store activity options, opening times etc. in facilities.

In my opinion, the only disadvantages of facilities are that they make the graphical output look less "fancy" (if one considers it fancy by now) and of course, that you generate an additional input file for the scenario. Since MATSim offers this data type and it enables cool stuff like "location innovation" (switching of work / shop / ... locations) we should try it and look where we it gets us.

Any opinions?

[00Bock]

I think that's a reasonable option. Losing fanciness is a pity but gaining calculation speed is positive :+1: I would go for the option with the building centroids.

[wese-da]

Okay, I just realized this extension comes with a little more work than I expected. There are two major sub-tasks that need to be done in order to make this work:

1. There has to be some kind of expandable framework for processing different data types Until now, we could process osm landuse data and osm buildings. Both end up to be polygons which is perfectly easy to code. Now that we introduce a different data type, some more effort has to be invested in order to make this work in the first place and to make it expendable if we should find yet another data type that fits in here.
2. OSM data is (again) not as self-consistent as I thought First, OSM buildings are mostly valid polygons, yes. The problem is the definition of the building polygons because one polygon can contain one or more house numbers. This is problematic in the case of building blocks when we eventually get one point for a whole block of buildings that actually need to be separated.

[00Bock]

Suggestion for point 2: can we use some kind of grid (eg. 200m) to cut the polygons and then get the centroids? But that could also enlarge the data (eg. five points for a large bullding with only four corners)

[wese-da]

Yes, this was the method we spoke about. Maybe there is some "magic" number(s) that approximates the real-world situation good enough without blowing things up too much.

It may also be meaningful to have a set of "magic" numbers for different activities as a second step (e.g. analogous to the FGSV-Regelwerk "Hinweise zur Schätzung des Verkehrsaufkommens für Gebietstypen").

Probably, we will need to do some good old-fashioned trial and error here...

[00Bock]

what's the status here?

[wese-da]

Work in progress I would say... There hasn't been much work on this issue due to other, more time-sensitive problems / projects.

BUT:

The demand generation works with both buildings and facilities ("buildings" as standard) :smile:

[00Bock]

now both included in an either or process