[mkgmap-dev] More method options for is_in function

Tue Feb 11 11:36:13 GMT 2020

Hi Gerd

OK - If we merge so that, for a node on a shared edge, is_in(...,on) is
false, then is_in(...,in) should be true, so must merge for this as
well.

Ticker

PS: please can you commit my previous patch so that I can do the next
stages

On Tue, 2020-02-11 at 10:16 +0000, Gerd Petermann wrote:
> Hi Ticker,
> 
> "but this isn't necessary for the IN/IN_OR_ON"
> Why not for IN?
> 
> Gerd
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Dienstag, 11. Februar 2020 11:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] More method options for is_in function
> 
> Hi Gerd
> 
> Case 1 looks like 2 independent polygons that happen to be touching.
> Before Wood2 is planted, Tree1 is on the edge of Wood1. Should
> mapping
> Wood2 change this state? - I don't know. If these get merged anyway
> to
> handle mp-cutting then we have forced the answer - it will no longer
> be
> ON.
> 
> Yes to the rest. POINT ON test should invoke merging, but this isn't
> necessary for the IN/IN_OR_ON
> 
> Ticker
> 
> 
> On Tue, 2020-02-11 at 09:43 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > I've attached a sample file. Assume point rule
> > natural=tree & isin(landuse,forest,ON)=true {...}
> > 
> > For me, tree1 is not ON, but IN, so result should be false
> > ON would be okay for tree2 and tree4
> > The node tree3 is obbiously IN but if multipolygon cutting devides
> > the mp exactly on the line it would be on two boundaries unless we
> > merge them again for the test.
> > 
> > Reg. performance it probably doesn't matter much, these cases are
> > rare and the point-in-polygon test is rather fast compared to the
> > line-in-polygon test.
> > 
> > Gerd
> > 
> > 
> > ________________________________________
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > Gesendet: Dienstag, 11. Februar 2020 10:05
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] More method options for is_in function
> > 
> > Hi Gerd
> > 
> > It's important to handle the polygons as merged for the LINE and
> > POLYGON processing, so that internal splitting by multi-polygon
> > processing doesn't affect the answer relating to ON queries. For
> > overlapping polygons, however, the ON query is ambiguous and I'm
> > not
> > sure how much effort it is worth taking to resolve it with respect
> > to
> > the edges of one polygon that are within the other.
> > 
> > I've just seen your next posting.
> > 
> > For POINTs: I agree, much the same as above applies to the ON
> > query.
> > 
> > So, we need to decide on the policy for ON queries relating to the
> > OSM
> > defined edges of one polygon within another polygon, or just ignore
> > the
> > issue on the grounds that the situation is unlikely and it is an
> > arbitr
> > ary decision anyway.
> > 
> > Ticker
> > 
> > On Tue, 2020-02-11 at 08:31 +0000, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > my understanding is that is_in(.., 'on') returns true if the
> > > point
> > > is
> > > on the boundary, not in or out.
> > > With line and polygon rules we merge overlapping polygons before
> > > we
> > > test, so I tried to do something similar with points.
> > > 
> > > Gerd
> > > 
> > > ________________________________________
> > > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im
> > > Auftrag
> > > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > > Gesendet: Dienstag, 11. Februar 2020 09:24
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] More method options for is_in function
> > > 
> > > Hi Gerd
> > > 
> > > Yes, overlapping polygons was the case I was thinking about. I'd
> > > say
> > > that is_in(.., 'on') should be true if ON the edge of one,
> > > regardless
> > > of being IN the other.
> > > 
> > > Can you commit my last change and then, if you are not changing
> > > IsInUtil at the moment, I'd like to move some of the code around.
> > > I'll
> > > also start some documentation for the Style Manual.
> > > 
> > > Ticker
> > > 
> > > On Mon, 2020-02-10 at 18:48 +0000, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > > 
> > > > reg. POINT is_in(..., 'on') : You think about the case that a
> > > > point
> > > > is inside one polygon and on boundary of another? Should not
> > > > happen
> > > > with correct OSM data but the question is also what result you
> > > > want
> > > > to get.
> > > > reg. isComplete():
> > > > This is about input data where not all coords are known and
> > > > thus
> > > > the
> > > > geometry of the way is undefined. Should never happen with
> > > > normal
> > > > input.
> > > > I am not sure but I think splitting at tile borders did not yet
> > > > happen with the polygons, only the preparation is done by
> > > > adding
> > > > nodes at the tile border.
> > > > 
> > > > Gerd
> > > > 
> > > > ________________________________________
> > > > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im
> > > > Auftrag
> > > > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > > > Gesendet: Montag, 10. Februar 2020 18:09
> > > > An: Development list for mkgmap
> > > > Betreff: Re: [mkgmap-dev] More method options for is_in
> > > > function
> > > > 
> > > > Hi Gerd
> > > > 
> > > > I've re-implemented the POINT test within IsInFunction, using
> > > > the
> > > > stopping methods etc, which are now coded, but only relevant
> > > > for
> > > > this
> > > > context at the moment. This implementation has other advantage
> > > > in
> > > > that
> > > > the method can control the onBoundary condition. Also the logic
> > > > in
> > > > calcInsideness can give the wrong answer for POINT is_in(...,
> > > > 'on').
> > > > 
> > > > I didn't want to change IsInUtil while you are working on it
> > > > and
> > > > I'm
> > > > not sure yet of the best way to handle the LINE/POLYGON
> > > > versions.
> > > > 
> > > > There are a couple of aspects of these that occur to me:
> > > > 
> > > > It would be clearer to test for kind=POINT/LINE/POLYGON etc
> > > > rather
> > > > than
> > > > el instanceof.
> > > > 
> > > > w.isComplete():
> > > > - Will this will cause different answers depending on tile
> > > > splitting,
> > > > or is the complete polygon represented; even the bits outside
> > > > the
> > > > tile?
> > > > - The ANY methods should be processed and will be correct.
> > > > 
> > > > Thanks for spotting my error with tstMethod.
> > > > 
> > > > This patch also improves the method error message; listing the
> > > > possible
> > > > methods for the context.
> > > > 
> > > > Ticker
> > > > 
> > > > On Mon, 2020-02-10 at 13:14 +0000, Gerd Petermann wrote:
> > > > > Hi all,
> > > > > 
> > > > > see
> > > > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&r
> > > > > ev
> > > > > =4
> > > > > 44
> > > > > 2
> > > > > 
> > > > > @Ticker:
> > > > > I assume you are working on an alternative implementation of
> > > > > the
> > > > > methods in IsInUtil?
> > > > > If not I'd like to remove all the code duplication introduced
> > > > > with
> > > > > the last patch.
> > > > > 
> > > > > Gerd
> > > > > _______________________________________________
> > > > > mkgmap-dev mailing list
> > > > > mkgmap-dev at lists.mkgmap.org.uk
> > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > _______________________________________________
> > > mkgmap-dev mailing list
> > > mkgmap-dev at lists.mkgmap.org.uk
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev