<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN" 
               "http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd" [
  <!ENTITY mathml "http://www.w3.org/1998/Math/MathML">
]>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<link rel="stylesheet" type="text/css" href="../../../comsci/css/s011.css"/>
<link rel='SHORTCUT ICON' href='../../../comsci/images/FrameHome.ico' />
<style type="text/css">
</style>
<title> Inclusion in a Polygon
</title>
</head>

<body>


<div class="message_right">
  <a href="http://validator.w3.org/check/referer">
    <img src="http://www.w3.org/Icons/valid-xhtml11" alt="Valid
	XHTML 1.1!" height="31" width="88" />
  </a>

  <a href="http://jigsaw.w3.org/css-validator/">
    <img style="width:88px;height:31px"
       src="http://jigsaw.w3.org/css-validator/images/vcss" 
       alt="Valid CSS!" />
  </a>
  <br/>
  Created 2005-07-02 &nbsp; Modified 
<!--UPDATE_DATE_MODIFIED-->
<!--UPDATE_DATE_BEGIN-->
2007-01-01
<br/>
<a href="mailto:chelton.evans@yahoo.com">Chelton Evans</a>
<!--UPDATE_DATE_END-->
</div>

<h1> 
<a href="geom.html"> <img alt="proj" src="../../../comsci/images/compgeom.png" /></a>
Inclusion in a Polygon
<a href="../../../../index.html">
<img alt="home" src="../../../comsci/images/Frame.gif" /> </a>
</h1>

<p>
<a href="#Intro">Intro</a><br/>
<a href="#Algorithm1">Algorithm1</a><br/>
<a href="#Algorithm2">Algorithm2</a><br/>
<a href="#Issues">Issues</a><br/>
<a href="#Inclusion_in_a_Convex_Polygon">
  Inclusion in a Convex Polygon </a><br/>
<a href="#Algorithm3">Algorithm3</a><br/>
<a href="g022.xml"> 
Convexity and Polygon Representation with Algebra</a><br/>
<a href="#Inclusion_in_a_Simplex_Mesh">Inclusion in a Simplex Mesh</a><br/>
  &nbsp; &nbsp;  
  <a href="#Approximation_with_a_Continuous_Surface">
    Approximation with a Continuous Surface</a><br/>
  &nbsp; &nbsp;  
  <a href="#Grids">Grids</a><br/>
  &nbsp; &nbsp;  
  <a href="#Bounding_Boxes_and_Half_Spaces_and_Trees">
  Bounding Boxes and Half Spaces and Trees</a><br/>



<a href="#References">References</a>
</p>




<div class="float25">
<a id="Intro"></a>
<h2>Intro</h2>

<p>
Shamos[1] page 93 describes a simple algorithm for finding a point inside a polygon, 
 and that this can be done in 
<math xmlns="&mathml;">
  <mi>O</mi>
  <mo>(</mo>
  <mi>n</mi>
  <mo>)</mo>
</math>
 time.
</p>

<p>
 This algorithm reminds me of the <a href="g011.html"> Scan Line Algorithm </a> as both
 algorithms have to deal with an intersection point being an endpoint of one of the
 polygons edges. 
</p>

<p>
Shamos[1] page 93 counts the number of intersections on one side of the point, 
 and uses this to determine
 whether a point is inside or outside.  The segment test includes the endpoints
 so a point on the edge is counted twice.
</p>

<p>
If the count is odd the point is inside, else outside.
</p>

<p> The second algorithm is a variation of the first.
 Both use the rectangular coordinate system to test for visibility.
 It is obvious that if we think of the lines as half spaces then
 these algorithms are instances of a more general algorithm with
 half spaces. And that this can be generalized to higher dimensions.
</p>

</div>

<div class="float25">
<a id="Algorithm1"></a>
<h2>
Algorithm1 (Shamos)
</h2>

<p class="alg0">
Testing if a point 
<math xmlns="&mathml;">
  <mi>P</mi>
  <mo>=</mo>
  <mo>(</mo>
  <mi>p</mi>
  <msub>
    <mi></mi>
    <mrow><mi>x</mi></mrow>
  </msub>
  <mo>,</mo>
  <mi>p</mi>
  <msub>
    <mi></mi>
    <mrow><mi>y</mi></mrow>
  </msub>
  <mo>)</mo> 
</math>
is within a 2D polygon. 
</p>

<p class="alg0">
<math xmlns="&mathml;">
  <mi>count</mi>  
  <mo>=</mo>
  <mi>0</mi>
</math>

</p>

<p class="alg0">
Let the polygon be a list of directed line segments. <br/>
Iterate over the line segments.
</p>

<p class="alg1">
If the line segment 

<math xmlns="&mathml;">
  <mi>L</mi>  
  <msub>
    <mi></mi>
    <mrow><mi>i</mi></mrow>
  </msub>
</math>

 intersects line 

<math xmlns="&mathml;">
  <mi>y</mi>
  <mo>=</mo>
  <mi>p</mi>
  <msub>
    <mi></mi>
    <mrow><mi>y</mi></mrow>
  </msub>
</math>
</p>

<p class="alg2">
Let 

<math xmlns="&mathml;">
  <mo>W</mo>
  <mo>=</mo>
  <mo>(</mo>
  <mi>w</mi>
  <msub>
    <mi></mi>
    <mrow><mi>x</mi></mrow>
  </msub>
  <mo>,</mo>
  <mi>w</mi>
  <msub>
    <mi></mi>
    <mrow><mi>y</mi></mrow>
  </msub>
  <mo>)</mo> 
</math>
 be the intersection point. <br/>
If 
<math xmlns="&mathml;">
  <mi>W</mi>
  <mo>&lt;</mo>
  <mi>P</mi>
</math>
</p>


<p class="alg3">
<math xmlns="&mathml;">
  <mi>count</mi>
  <mo>=</mo>
  <mi>count</mi>
  <mo>+</mo>
  <mi>1</mi>
</math>
</p>

<p class="alg0">
if 
<math xmlns="&mathml;">
  <mo>Even</mo>
  <mo>(</mo>
  <mi>count</mi>
  <mo>)</mo>
  <mo>==</mo>
  <mi>true</mi>
</math>
 the point is outside the polygon.
<br/>
else the point is inside the polygon.
</p>

</div>

<div class="spacer" />

<div class="float25">
<a id="Algorithm2"></a>
<h2>Algorithm2</h2>

<p class="alg0">
Testing if a point 
<math xmlns="&mathml;">
  <mi>P</mi>
  <mo>=</mo>
  <mo>(</mo>
  <mi>p</mi>
  <msub>
    <mi></mi>
    <mrow><mi>x</mi></mrow>
  </msub>
  <mo>,</mo>
  <mi>p</mi>
  <msub>
    <mi></mi>
    <mrow><mi>y</mi></mrow>
  </msub>
  <mo>)</mo> 
</math>
is within a 2D polygon. 
</p>

<p class="alg0">
Let comparisons on points be comparisons in the x dimension of the associated points.
</p>

<p class="alg0">
Let 
<math xmlns="&mathml;">
  <mi>Left</mi>
</math>
 and 
<math xmlns="&mathml;">
  <mi>Right</mi>
</math>
 be line segments left and right of 

<math xmlns="&mathml;">
  <mi>P</mi>
</math>
.
</p>

<p class="alg0">
Let the polygon be a list of directed line segments. <br/>
Iterate over the line segments.
</p>

<p class="alg1">
If the line segment 

<math xmlns="&mathml;">
  <mi>L</mi>  
  <msub>
    <mi></mi>
    <mrow><mi>i</mi></mrow>
  </msub>
</math>

 intersects line 

<math xmlns="&mathml;">
  <mi>y</mi>
  <mo>=</mo>
  <mi>p</mi>
  <msub>
    <mi></mi>
    <mrow><mi>y</mi></mrow>
  </msub>
</math>
</p>

<p class="alg2">
Let 

<math xmlns="&mathml;">
  <mo>W</mo>
  <mo>=</mo>
  <mo>(</mo>
  <mi>w</mi>
  <msub>
    <mi></mi>
    <mrow><mi>x</mi></mrow>
  </msub>
  <mo>,</mo>
  <mi>w</mi>
  <msub>
    <mi></mi>
    <mrow><mi>y</mi></mrow>
  </msub>
  <mo>)</mo> 
</math>
 be the intersection point. <br/>
If 
<math xmlns="&mathml;">
  <mi>W</mi>
  <mo>&lt;</mo>
  <mi>P</mi>
</math>
</p>

<p class="alg3">
If
<math xmlns="&mathml;">
  <mi>W</mi>
  <mo>&GreaterEqual;</mo>
  <mi>Left</mi>
</math>
</p>

<p class="alg4">
<math xmlns="&mathml;">
  <mi>Left</mi>
  <mo>=</mo>
  <mi>L</mi>  
  <msub>
    <mi></mi>
    <mrow><mi>i</mi></mrow>
  </msub>
</math>



</p>

<p class="alg2">
else</p>



<p class="alg3">
If
<math xmlns="&mathml;">
  <mi>W</mi>
  <mo>&leq;</mo>
  <mi>Right</mi>
</math>
</p>

<p class="alg4">
<math xmlns="&mathml;">
  <mi>Right</mi>
  <mo>=</mo>
  <mi>L</mi>  
  <msub>
    <mi></mi>
    <mrow><mi>i</mi></mrow>
  </msub>
</math>

</p>

<p class="alg0">
If no intersections then 
<math xmlns="&mathml;">
  <mi>P</mi>
</math>
 is outside the polygon.
</p>

<p class="alg0">
If 
<math xmlns="&mathml;">
  <mi>Left</mi>
  <mo>==</mo>
  <mi>Right</mi>
</math>
 then 

<math xmlns="&mathml;">
  <mi>P</mi>
</math>
 is on an endpoint.
</p>

<p class="alg0">
if 
<math xmlns="&mathml;">
  <mi>P</mi>
</math>
 is viewable from

<math xmlns="&mathml;">
  <mi>Left</mi>
</math>
 and 

<math xmlns="&mathml;">
  <mi>Right</mi>
</math>
 then 

<math xmlns="&mathml;">
  <mi>P</mi>
</math>
 is inside the polygon.
</p>



</div>


<div class="float25">
<a id="Issues"></a>
<h2>Issues</h2>

<p>
The shortfalls of algorithms 1 and 2 should be obvious - they are slow.
 (Algorithm 1 is probably some factor faster than Algorithm 2 because its got more primitive and minimal testing).
 In more or less formal terms, given
<math xmlns="&mathml;">
  <mi>M</mi>
</math>
 points and 

<math xmlns="&mathml;">
  <mi>N</mi>
</math>
 lines its going to take

<math xmlns="&mathml;">
  <mi>O</mi>
  <mo>(</mo>
  <mi>M</mi>
  <mi>N</mi>
  <mo>)</mo>
</math>
 time. Which loosely put is quadratic time.
</p>


</div>


<div class="float25">
<a id="Inclusion_in_a_Convex_Polygon"></a>
<h2>Inclusion in a Convex Polygon</h2>
<p>
With pre-processing the test can be speed up considerably.
 Shamos[1] pages 93-95 gives a 
<math xmlns="&mathml;">
  <mi>O</mi>
  <mo>(</mo>
  <mi>log</mi>
  <mo>(</mo>
  <mi>N</mi>
  <mo>)</mo>
  <mo>)</mo>
</math>
 algorithm. 
 See <a href="#Algorithm3">Algorithm3</a>.
 This is the best solution so far in that it is 
 easy to implement.
</p>

<p>
It is possible to go further.
 If a non-linear function can be constructed to return 
 which wedge
 the point lies in. Each interval is associated with an integer
 and it is the job of the function to compute the integer in
 constant time.
</p>

<p class="equ">
<math xmlns="&mathml;">
  <mi>f</mi>
  <mo>(</mo>
  <mi>&theta;</mi>
  <mo>)</mo>
</math>
 is defined in the following way.<br/>


for points 
<math xmlns="&mathml;">
  <mi>O</mi>
  <mo>..</mo>
  <mi>N</mi>
  <mo>-</mo>
  <mi>1</mi>
</math><br/>
 &nbsp; &nbsp; &nbsp; 

<math xmlns="&mathml;">
  <mo>[</mo>
  <mi>&theta;</mi>
  <msub>
    <mi></mi>
    <mrow><mi>i</mi></mrow>
  </msub>
  <mo>,</mo>
  <mi>&theta;</mi>
  <msub>
    <mi></mi>
    <mrow><mi>i</mi><mo>+</mo><mi>1</mi></mrow>
  </msub>
  <mo>)</mo>
  <mo>=</mo>
  <mi>i</mi>
</math>
</p>

<p>With such a function the search is in constant time. So the algorithm is

<math xmlns="&mathml;">
  <mi>O</mi>
  <mo>(</mo>
  <mi>1</mi>
  <mo>)</mo>
</math>.
 With the same test in <a href="#Issues">Issues</a> the complexity is linear. 
<math xmlns="&mathml;">
  <mi>O</mi>
  <mo>(</mo>
  <mi>M</mi>
  <mo>)</mo>
</math>.
</p>

<p>
If the function is slightly inaccurate use a linear
 search to correct it.  This will not change the
 complexity.
</p>

<p>
Here is an example of such a function which will
 use some known interpolation technique.
First reform the problem.
</p>

<p class="equ">
<math xmlns="&mathml;">
  <mi>&varphi;</mi>
  <msub>
    <mi></mi>
    <mrow><mi>i</mi></mrow>
  </msub>
  <mo>=</mo>
  <mfrac>
    <mrow>

  <mi>&theta;</mi>
  <msub>
    <mi></mi>
    <mrow><mi>i</mi></mrow>
  </msub>
  <mo>+</mo>
  <mi>&theta;</mi>
  <msub>
    <mi></mi>
    <mrow><mi>i</mi><mo>+</mo><mi>1</mi></mrow>
  </msub>

    </mrow>
    <mrow><mi>2</mi></mrow>
  </mfrac>
  
</math>

</p>

<p class="equ">
Let &nbsp; 

<math xmlns="&mathml;">
  <mi>g</mi>
  <mo>(</mo>
  <mi>&varphi;</mi>
  <mo>)</mo>
</math>
 &nbsp; interpolate &nbsp;

<math xmlns="&mathml;">
  <mo>{</mo>
  <mi>&varphi;</mi>
  <msub>
    <mi></mi>
    <mrow><mi>i</mi></mrow>
  </msub>
  <mo>,</mo>
  <mi>i</mi>
  <mo>}</mo>
</math>

<br/>

<math xmlns="&mathml;">
  <mi>f</mi>
  <mo>(</mo>
  <mi>&theta;</mi>
  <mo>)</mo>
  <mo>&approx;</mo>
  <mo>&lfloor;</mo>
  <mi>g</mi>
  <mo>(</mo>
  <mi>&theta;</mi>
  <mo>)</mo>
  <mo>&rfloor;</mo>
</math>

</p>


</div>

<div class="float25">

<a id="Algorithm3"></a>
<h2>Algorithm3</h2>

<p class="alg0">
Pre process: Order the points around a convex polygon into a
 vector array.  The vector supports indexing.
Iterate around the polygon constructing half-spaces
 from the boundary to the inside point generating a vector.
</p>

<p class="alg0">
To search which wedge a point lies in,
 apply a <a href="../number/n032.xml">Binary Search</a> to the array by comparing
 the point with the associated wedges half space.
 
</p>


</div>

<div class="spacer" />

<div class="float25">
<a id="Inclusion_in_a_Simplex_Mesh"></a>
<h2>Inclusion in a Simplex Mesh</h2>

<p>
Consider a simplex mesh with every simplex occupying a unique space
 except where they intersect at their boundaries. Given a point
 in the mesh which simplex does it belong too?
</p>

<p>Let each simplex be uniquely identified by an integer. Consider
 the 2D case where the mesh is a mesh of triangles.  Then the problem
 becomes one of how to construct a function that given a point in the
 mesh return the integer of the associated simplex. 
</p>

<p class="equ">
Let &nbsp; 
<math xmlns="&mathml;">
  <mi>X</mi>
</math>
 &nbsp; be a point in n dimension space.
<br/>

<math xmlns="&mathml;">
  <mi>f</mi>
  <mo>(</mo>
  <mi>X</mi>
  <mo>)</mo>
  <mo>&RightArrow;</mo>
  <mi>k</mi>
</math>
</p>



<p>
Further consider the problem where the points remain static and we
 can use pre processing to build a data structure where the points are
 accessed.  This pre processing is not limited in complexity (except that
 it must produce in reasonable time ) a data structure.
 However the aim of this new data structure is to have constant 
 lookup or O(1) complexity when finding a point associated with
 a simplex.
</p>

</div>

<div class="float25">

<a id="Approximation_with_a_Continuous_Surface"></a>
<h3>Approximation with a Continuous Surface</h3>

<p>Consider a 2D surface tessellation. Construct a continuous function
 through points from the tessellation that are integer values at these
 points.
</p>

<p>For example the continuous surface could pass through the indexed integer 
 point k of p<sub>k</sub> at that point. The vertex could be used to find
 further information.
</p>

<p>Another example is to generate a surface that when it passes through 
 the centroid of a simplex the integer index of the simplex is a point through
 the surface.
</p>

<p>Then some variation of the floor function is used to get the integer
 index back given a point on the surface. 
</p>

<p>
Here is one solution that I have considered, but do not have the
 mathematical machinery to implement.  Arrange and relable the simplexes
 such that jumps between neighboring simplexes in integer indexes 
 are minimized.
</p>

<p>
The a surface is to pass through all the integer points 
  f(x<sub>i</sub>,y<sub>i</sub>) where (x<sub>i</sub>,y<sub>i</sub>) are
  integer indexes in the mesh.
</p>

<p>
Next construct some approximating function which approximates the
 true curve. Call this function g(x,y).  Have the function have
 an additional property that f(x,y) = floor(g(x,y)) indexes a simplex which
 is no more than e steps away from the simplex which actually contains
 the point (x,y).
</p>

<p>This ensures that the approximation function g can be used to find
 the simplex associated with (x,y). If evaluation of g has O(1) complexity
 then so does finding k. ie <br/>
 O(f) = O(g) + O(1) = O(g)
</p>

<p>The advantage of this approach is that it is completely general.
 For example a mesh with completely different sized simplexes
 can be built.  So adaptive meshes can be handled.  
</p>

<p>However it is still a very hard problem that has only been separated
 and not solved.  Finding g could possibly be done by many different
 mathematical techniques and varies on the point distribution.
</p>

<p>The function to convert from a continuous function to a discrete integer
 is problematic.  For example what if two points had largly varying integer
 values. For example the integers between 6 and 100 are useless so the 
 approximation function should give only 6 or 100.
</p>

<p>Relabeling or mapping of the integer indexes so that between any boundary the
 difference is at most 1 is possible.  ie given a point set of integer values,
 find an integer function f(k) -&gt; w where k is the point integer value and
 w is the new integer value.  The catch is that in the mesh any neighboring w
 have at most 1 difference in their value.
</p>
 
<p>To calculate the function sum polynomials are probably very expensive and
 difficult to compute.  As more points are added the sum grows.  While this
 is interesting I like grids because they are simple and do the job much 
 more easily.
</p>

<p>A heirachy of grids could be the best approach.  Restrict the heirachy
 depth to be finite (and meaningful, eg 5) the the grid tile can be located
 in a fixed time.  Further such a grid is adaptable over time.
</p>


</div>

<div class="float25">
<a id="Grids"></a>
<h3>Grids</h3>

<p>
Grid are a lattice of points which are a function that they
 point to the nearest simplex in the mesh. It has the property
 that its index is computed in constant time. 
</p>

<p>The grid itself is simply a matrix of integers.  Floor functions
 convert the continuous variable into an integer index into the grid.
</p>

<p>The size of the grid cells needs to be such that given
 any point (x,y) which is inside the mesh the simplex associated
 with that point can be found with an initial approximation and
 a greedy search within a bounded number of steps iterating
 from one simplex to the next.
</p>

<p>So the grid needs a fine granularity which is dependent on
 the distribution of the mesh.  If the mesh has simplexes many
 magnitudes less in size then the grid will have a simplexes
 indexed many magnitues more times than the smaller ones.
</p>

</div>

<div class="float25">

<p>Since this consumes vast resources then meshes that have
 simplexes with the same size need to be used.  This is contradictory
 to meshes which are of interest ie adaptive meshes which are much
 more accurate where they need to be.
</p>

<p>The question of what is a balances mesh is also raised as this property
 is required plus that the sizes of the simplexes be comparable/similar.
</p>

<p>
If we assume that we have the resources to use relatively large amounts
 of memory (so that computation is fast) then a mesh with a bad
 distribution of points could be re tessellated to be more balanced.
</p>

<p>Alternatively leave the tessellation alone and have a finer grid,
 but approximate the tessellation with higher order curves so that the
 tessellation does not fragment the approximation.
</p>

</div>

<div class="spacer" />

<div class="float25">

<p>A problem with linear interpolation is that it is inaccurate.
 If we re tessellate on a linear boundary it is always linear.
 If we re tessellate on a boundary that is a spline then the accuracy
 is much better (unless the boundary was originally flat).
</p>

<p>What I am trying to say is that re tessellation should not loose
 information but realize it in a different form.  
 <b>So a mesh is composed of simplexes but the boundary
 of the mesh is a continuous surface.</b>
</p>

<p>With this philosophy a mesh can be transformed through retessellation
 into another mesh with a much smoother boundary and more equally sized
 simplexes (but not necessarily balanced).  This second mesh would
 have a grid built for it so that a simplex could be identified
 from any point in constant time. 
</p>



</div>

<div class="spacer" />


<div class="float25">
<a id="Bounding_Boxes_and_Half_Spaces_and_Trees"></a>
<h3>Bounding Boxes and Half Spaces and Trees</h3>

<p>Meshes are generally non convex. And the general case
 of a mesh is where the granuality (size of the simplexes)
 varies.
</p>

<p> Assume that the mesh is balanced because
 the following algorithm partions the mesh and builds a tree.
 If the mesh is not balanced then there may be problems finding
 half space partitions that divide that part of the mesh in two. 
</p>

<p class="alg1">
Have a data structure that points to a mesh
 and has a bounding box of some sort. Let the mesh be
 inside the bounding box.  Generally a point is determined
 to be within the bounding box in constant time.
</p>

<p class="alg1">
Construct a tree of this data structures by having the mesh
 in the root node. 
Find a partition that divides the mesh roughly equally in two.
 Create a pair of children under the node where one contains
 all the simplexes within the found partition and the other
 has all the other simplexes. Find bounding boxes for both
 these sub meshes.
</p>

<p class="alg1">Repeat this subdivision until the meshes are of a certain
 size which is easily managed.
</p>

</div>

<div class="float25">

<p>For dynamic algorithms this data structure will need to be routinely
 updated to ensure that the mesh is balanced. Rather than using
 this tree balancing in this case the red/black trees or another
 tree which is guaranteed to have log(n) complexity should be used.
</p>

<p>To find the simplex a point is in can now be done in log(n) time.
</p>

<p>The memory requirements of having links to all the simplexes is quite large.
 The standard way of dealing with this is to have the nodes as bounding boxes
 and the leafs contain the pointers to the simplexes.
</p>

<p>If the mesh has n simplexes then O(n) in memory is required.
</p>


</div>




<div class="float25">
<a id="References"></a>
<h2>References</h2>





<ol>
<li>
Shamos M I (1978). Computational Geometry.  Dissertation for PhD.
</li>


</ol>


</div>


</body>
</html>



