Hi Ticker, regarding the shapes my current approch is to combine them before running insideness tests. So, the two residential areas around w18 are combined to one, but the two shapes near w30 are kept separate.
I think the needed checks for ways are more or less the same as in the code for MultipolygonRelation.contains(WayAndLazyPolygon polygon1, JoinedWay polygon2) Maybe I'll use that code, but up to now I don't understand all of it, esp. the part with the 3x3 matrix starting in line 1546. For a point I can use a variant of the wn_PnPoly() algorithm published here: http://geomalgorithms.com/a03-_inclusion.html For segment-segment intersections we have an algorithm. It finds when a segment crosses or touches another segment. When a segment a-b is touching the boundary in b there are several possible cases. I did not find a standard solution for the question if two line strings a-b-c and x-b-y are crossing in b, or just touching, or if they are overlapping. That's what I am still working on. See w9, w11, w16, and w17 which Note that most standard intersection algorithms assume that a crossing at the end of two line segments is a very special case. In OSM, this is the normal case. If you have an idea how to solve the problem with all the special cases shown in my sample file please try to code it. My current work-in-progress solution doesn't work for w9, w11, w21*, w27*, b5, b6, and b18. (w21 and w27 give different results when I reverse the way points before testing). If you have an idea how to implement the tests I'd be happy to get a patch for this as well. The current code in the branch can be used as sample for "what you should not do" ;) Attached is a patch with my current work-in-progress version, lots of duplicated code. Gerd ________________________________________ Von: mkgmap-dev <[email protected]> im Auftrag von Ticker Berkin <[email protected]> Gesendet: Mittwoch, 8. Januar 2020 12:12 An: [email protected] Betreff: Re: [mkgmap-dev] Allow blanks in function parameters Hi Gerd I'll do patch for the function parameters shortly. Are you trying to trying to check if a way/polygon is in all nearby polygons simultaneously, or just checking one-by-one until you get 'true'? If one-by-one, the moment any line crosses then you can stop, with IN/ON/OUT all being true (unless the line/polygon folds back on itself). If no crossing, then need to take any point that wasn't ON and see if that is IN; presumably using the same logic as for POINT is -in. The problem with the one-by-one is that multi-polygon processing might have split the target polygon and so the this simplistic method can give the wrong answer. Considering all targets simultaneously looks much more complicated, but I guess you need to make a list of all crossing points and cancel out ones at the same position. For POINT is-in, I guess you just cut the polygon(s) through the point and count the cuts on one side, even>OUT, odd>IN. true>ON Ticker On Wed, 2020-01-08 at 10:14 +0000, Gerd Petermann wrote: > Hi Ticker, > > I am still struggling with the insideness tests. > > I noticed that the scanner doesn't accept a blank in the functions > parameters, e.g. these two rules are not accepted: > building=* & building!=no & is_in(landuse,residential, any)=false > [0x13 resolution 24] > building=* & building!=no & is_in(landuse, residential,any)=false > [0x13 resolution 24] > > I'd prefer to allow this as well. Maybe you can have a look at this? > > Gerd _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
in_in_work.patch
Description: in_in_work.patch
_______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
