= MAS-Preprocessing - Visibility graph =

[[TracNav(doc/tec/mastoc|nocollapse)]]

[[NoteBox(note,This page is part of the **Multi Agent System** (MAS) documentation. \\ It contains a documentation about the preprocessing tool for Multi Agent System. \\ For an overview of all MAS-related pages\, see the **[wiki:doc/tec/mas MAS main page]**.)]]

Prior to a simulation using the MAS navigation information for the agents **MUST** be preprocessed.\\
The result is a visibility graph that agents can use to find their way around obstacles toward their target.\\

== Creating the visibility graph == 
A tool separate from PALM (Agent Preprocessing Tool for PALM - APT-P) has been developed to calculate the visibility graph.\\
It is a standalone Fortran program (find it [browser:palm/trunk/UTIL/agent_preprocessing/agent_preprocessing.f90 here] or at {{{trunk/UTIL/agent_preprocessing/agent_preprocessing.f90}}} in your local PALM installation). \\
To use it,\\\\
1) navigate to the {{{INPUT}}}-folder of your JOB.\\
2) Make sure your Input folder contains the relevant topography information in either an ASCII- or NetCDF-file ([wiki:doc/app/iofiles/pids#topo see here]).\\
3) Make sure your Input folder contains the {{{_p3d}}}-file. In it, if necessary, specify the namelist {{{&prepro_par}}} with the parameters [#flag_2d flag_2d], [#internal_buildings internal_buildings] and [#tolerance_dp tolerance_dp].\\
4) Execute the APT-P by typing
{{{
agent_preprocessing
}}}
This will create a file {{{<job_identifier>_nav}}}. This is a Fortran binary file that contains the polygon and visibility graph data and will be read by PALM during the simulation. As long as the area and resulution of the model domain do not change this file can be reused. \\


== Concept ==
For agents to be able to find a path through an area containing obstacles (such as a city) some sort of graph is needed on which pathfinding can be performed. Such a graph consists of nodes that indicate physical locations and connections between these nodes annotated with a cost to travel between the two nodes.\\
The concept used here is called "visibility graph". It hinges on the idea that pedestrians use '''outer corners''' of obstacles to navigate. All spaces that pedestrians will not or cannot cross, such as buildings, trees, certain types of streets, etc are considered obstacles. The agent will walk toward the next visible corner on their way to their final target, make a turn, and walk toward the next corner. Thus, the nodes are the obstacle corners and a connection is established between two nodes if they are in view of each other and given the cost of the direct distance between the two. \\\\
To produce this data,\\
1) the PALM building topographhy is '''converted to polygons''' (one per obstacle) containing all convex and cocave corners as vertices.\\
2) The polygon data is '''simplified''' using the Douglas-Peucker algorithm ([#hershberger1994 Hershberger and Snoeyink, 1994]). To adjust the rate of simplification, see [#tolerance_dp tolerance_dp]. \\

||='''Douglas-Peucker algorithm '''  =||
|----------------
{{{#!td style="vertical-align:top; text-align:left;width: 250px"
For polygon P = {p,,0,,,p,,1,,,...,p,,n,,}:
* Approximate P by the line segment p,,0,,p,,n,,
* Determine furthest vertex p,,f,, from p,,0,,p,,n,,
* If distance d(p,,f,,,p,,0,,p,,n,,) < ε, accept p,,0,,p,,n,, as approximation.\\
	Else, break P at p,,f,, and recursively approximate {p,,0,,,p,,1,,,...,p,,f,,} and {p,,f,,,...,p,,n,,}
}}}
{{{#!td style="vertical-align:top; text-align:left;width: 250px"
[[Image(poiker.gif,400px)]]
}}}

3) All remaining convex polygon vertices are '''added to the graph''' as nodes.\\
4) '''Connections''' are established between each pair of nodes that are visible by each other. The associated cost is set to the direct distance.\\
5) The polygon and graph data is '''output''' to a [wiki:doc/app/iofiles#NAVIGATION_DATA Fortran binary file] that can be read by PALM.\\

== NAMELIST group name: {{{prepro_par}}}==

||='''Parameter Name'''  =||='''[wiki:/doc/app/fortrantypes FORTRAN Type]'''  =||='''Default Value'''  =||='''Explanation'''  =||
|----------------
{{{#!td style="vertical-align:top; text-align:left;width: 150px"
[=#flag_2d '''flag_2d'']
}}}
{{{#!td style="vertical-align:top; text-align:left;style="width: 50px"
L
}}}
{{{#!td style="vertical-align:top; text-align:left;style="width: 75px"
.F.
}}}
{{{#!td
Flag to force usage of 2d-buildings.\\\\
If set to .T., this flag forces the usage of buildings_2d even if buildings_3d is available. See [wiki:doc/app/iofiles/pids#topo here] for information on topography and building input.
}}}
|----------------
{{{#!td style="vertical-align:top; text-align:left;width: 150px"
[=#internal_buildings '''internal_buildings'']
}}}
{{{#!td style="vertical-align:top; text-align:left;style="width: 50px"
L
}}}
{{{#!td style="vertical-align:top; text-align:left;style="width: 75px"
.F.
}}}
{{{#!td
Flag to control usage of buildings within courtyards.\\\\
By default, buildings completely surrounded by another building are excluded from the visibility graph as pedestrians can neither reach nor leave enclosed areas such as courtyards. If '''internal_buildings = .T.''', buildings within courtyards are allowed. The resulting navigation nodes can, however, never be connected to nodes outside of the courtyard. In such cases, be sure to set the target of a agent group originating inside a courtyard also within that same courtyard.
}}}
|----------------
{{{#!td style="vertical-align:top; text-align:left;width: 150px"
[=#tolerance_dp '''tolerance_dp'']
}}}
{{{#!td style="vertical-align:top; text-align:left;style="width: 50px"
R * 3
}}}
{{{#!td style="vertical-align:top; text-align:left;style="width: 75px"
1.41, \\0.7, \\0.35
}}}
{{{#!td
Tolerance for simplification of building polygons during preprocessing.\\\\
Each building is stored as a counter-clockwise sorted polygon. Initially each building polygon consists of all inner and outer corners of the PALM topography as vertices. Due to the rastered nature of this grid this may be a very large number of vertices. The Douglas-Peucker-Algorithm ([#hershberger1994 Hershberger and Snoeyink, 1994]) is used to reduce the number of vertices.\\
This algorithm recursively approximates a polygon section as a straight line connecting the end points of that section. If the greatest distance between this line and any vertex between the end points is smaller than '''tolerance_dp''', the approximation is accepted and all vertices in between are deleted. Otherwise, the segment is split into two segments at the vertex of greatest distance and the process is repeated.\\\\
'''tolerance_dp''' is internally multiplied with {{{SQRT( dx*dy )}}}. If a building is left with less than 4 vertices after simplification using '''tolerance_dp(0)''', it is reset and the process is repeated with '''tolerance_dp(1)''', then '''tolerance_dp(2)''', if necessary.\\\\
'''NOTE:''' The APT-P produces an ASCII output-file {{{topo.txt}}}. The polygon data is stored in this file. After execution of the tool, please check the polygon representation. If you are not satisfied, adjust '''tolerance_dp''' and rerun the tool.
}}}

== References ==
* [=#hershberger1994] '''Hershberger, J., Snoeyink, J.''' 1994. An O(''n''log''n'') implementation of the Douglas-Peucker algorithm for line simplification. SCG '94 Proceedings of the tenth annual symposium on Computational geometry. 383-384. [https://doi.org/10.1145/177424.178097 doi]