Method D : Voronoi cells for people leaning over obstacles

[chraibi]

In Gitlab by @JuleAdrian on May 3, 2018, 17:46 [origin]

In my case, some persons are leaning over the obstacles (PIDs 6, 23, 56). The corners of the corresponding Voronoi Cells are marked by green dots.

• Case 1: For PID 23 and 56, the corresponding Voronoi Cells are lying on the other side of the obstacle. However, the Voronoi cells of the neighboring PIDs (e.g. 37, 34, 28, ..) are cut and not elongated towards the obstacle. That means that the presence of PID 23, 56 affects the density of the neighbors.

• Case 2: The Coordinate of PID 6 seems to be just within the obstacle. Therefore, no Voronoi cell is created at all. And the Cell of PID 49 is not cut. That means the density of the neighbors is not affected by PID 49.

Question: How can we proceed with this? Is this an issue that needs to be fixed?

[chraibi]

In Gitlab by @chraibi on May 7, 2018, 17:26

changed the description

[chraibi]

In Gitlab by @chraibi on May 7, 2018, 17:27

Jule,​ please upload a zip-file with your ini-, traj- and geo-file.

[chraibi]

In Gitlab by @JuleAdrian on May 8, 2018, 09:27

030_files.zip

[chraibi]

In Gitlab by @chraibi on May 8, 2018, 20:07

This is a problem that Gregor faced before. The boost-function used by jpsreport for calculating the overlap of two polygons does not work properly when one polygon is very thin. This might be the case in your geometry.

Most of the problems mentioned above can be solved with the following geometry (small modification of yours)

geo_56_obstacle_01.xml

Pedestrians that pass the exist (e.g number 21),show a not so nicely sliced polygon. However, here I think the abovementioned function does not deliver erroneous results:

jpsreport

debugging the result from boost

What do you think?

Here is the result of a bend exit

@gjaeger

[chraibi]

In Gitlab by @gjaeger on May 9, 2018, 08:45

@chraibi

This is a problem that Gregor faced before. The boost-function used by jpsreport for calculating the overlap of two polygons does not work properly when one polygon is very thin. This might be the case in your geometry.

Which polygon do you mean? The barrier or the polygon of an agent/ a person?

[chraibi]

In Gitlab by @chraibi on May 9, 2018, 08:47

The first polygon is the Voronoi diagram of a pedestrian. The second polygon is the obstacle.

[chraibi]

In Gitlab by @JuleAdrian on May 9, 2018, 10:35

@chraibi

Most of the problems mentioned above can be solved with the following geometry (small modification of yours)

In your example video person 13 vanishes in the obstacle. So the problem still exists. Would you recommend to edit the trajectories so that all trajectories stay inside the geometry? Even if this means that the marker is located on the back instead of the head..

[chraibi]

In Gitlab by @JuleAdrian on May 9, 2018, 10:41

@chraibi

Here's a plot of the same frame as my first example plot. Now all persons leaning over the barrier vanish inside the obstacle and are not assigned with a voronoi cell. Therefore, they do not contribute to the density measure of the neighboring persons.

[chraibi]

In Gitlab by @chraibi on May 9, 2018, 11:51

I see the problem. I would not edit the trajectories and would keep the originals.

Here the only "parameter" is the geometry. If it does not fit the trajectories, jpsreport will chock on it.

[chraibi]

In Gitlab by @chraibi on May 9, 2018, 15:47

I just remembered. @gjaeger and me had once a lousy discussion about how to automatically find the geometry that fits best the trajectories.

The bad news is I did not manage to finish. The blue points need to be connected. But how? :thinking_face:

Here my solution so far as notebook

make_geometry.zip

[chraibi]

In Gitlab by @gjaeger on May 9, 2018, 16:11

@chraibi That's not the solution for this problem.

The question is: How can we track/analyze agents who leaning over the barrier?

[chraibi]

In Gitlab by @chraibi on May 22, 2018, 14:53

mentioned in commit 0e31449697d0fb41b472220a072e523df588ed37

[gjaeger]

solved with pull request #142.