Subject: Re: [geometry] within(Poly, Poly)
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-09-26 10:22:17
Adam Wulkiewicz wrote:
> I think I now understand turns and am ready to implement within().
> This is what I figured out about it (I'm attaching the SVGs, each
> one's name starts with the corresponding point number):
> 0. Point 0 of the first polygon should lie in the interior or on the
> boundry of the second polygon. This probably will be enough in the
> conection with the points below.
> Or more explicit: no point of the first polygon should lie in the
> exterior of the second polygon.
> Or maybe all points should be tested if they're inside (interior
> or boundry) the second polygon?
> 1. those combinations of methods and operations are ok:
> a) t+iu, m+iu,
> b) t+ii, probably m+ii, ('1 within t,ii.svg')
> c) c+cc, c+iu,
> d) e+cc, e+iu
> 2. those are potentially ok:
> a) t+uu, m+uu (see: '2 within t,uu.svg', '2 not within t,uu.svg',
> '2 within m,uu.svg')
> b) t+cc, m+cc (see: '2 [not] within (t|m),cc.svg')
> So I think that for those I also need to check if points of
> touching segments are inside. But is it sufficient? Probably yes
> assuming the 'no crossing' policy (point 4) is used.
> 3. operation can't be 'x' (block) (see: '3 *.svg'). Btw, for
> covered_by() it would be allowed.
> 4. method can't be 'i' (cross) because otherwise it won't be possible
> to simply distinguish between '4 within si i.svg' and '4 not within si
> i.svg' (number of crossings per segment isn't enough). So for self
> intersecting polygons within() will return false.
> 5. area of the first (both?) polygon must be > 0 (see: '5 *.svg')
> because if area is 0 there is no interior and within() should return
> false. Btw within(Linestring, Polygon) should return true in this case.
> If both areas are = 0 'x' (block) operation is generated (see: '3
> *.svg'), would it be always the case?
> What do you think? Have I missed something?
Of course I missed something! Holes. So the external ring must be
analyzed as above but holes must be analyzed separately for thouch (like
in touches()), so no intersection operation, etc. See attachments.
Geometry list run by mateusz at loskot.net