logo separator

[mkgmap-dev] More method options for is_in function

From Ticker Berkin rwb-mkgmap at jagit.co.uk on Tue Feb 11 10:07:10 GMT 2020

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&rev
> > > > =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


More information about the mkgmap-dev mailing list