Hi,
a path in a forest should be presented thik:
______________
| forest |
| |
=============================
| |
| |
____________
The hole way will be draw thick. If you set a point at the polygoneborder and cut the way there, only the part is_in the forest will be draw thick.
______________
| forest |
| |
------0============0-------
| |
| |
____________
greets
Arndt
Gerd Petermann < gpetermann_muenc...@hotmail.com> hat am 5. Februar 2020 um 09:51 geschrieben:
Hi Ticker,
I am lost in alternatives. I don't like the current solution and I also don't like my "three bit flags" solution.With the current code we can only distinguish 4 cases, your original list contained 6 cases, the newer 5.What should be changed in current code (r4228)? More or other method parameters?
Please ignore the tuning idea. Most of this is only true in theory as rounding problems don't allow stop early unless a a real crossing (in-out or out-in) is detected. In reality the internal rounding of coordinates create something like a halo along the polygon edges. Results are unpredictable when a tested point is inside that halo unless it is exactly at the same position of a polygon node. Same position means it is either the identical node or has identical OSM coordinates.
With polygons we have the special case shown with b13 and b14 in my example file is-in-hook-samples-v4.osm. I forgot to add cases where the target polygon is inside the tested polygon. Typically those would be tagging errors, e.g. landuse=residential inside a building=yes or a closed way with both tags.
If I got you right you suggest to introduce more methods? As a reminder, these are the 6 different cases for a line:L1: all of the line is outside the polygonL2: some of the line is outside and the rest touches or runs along the polygon edgeL3: all of the line runs along the polygon edgeL4: some of the line is inside and the rest touches or runs along.L5: all of the line is inside the polygonL6: some is inside and some outside the polygon. Obviously some point is on the polygon edge but we don't care if runs along the edge.
For case L3 the results of is_in(x,y,any) and is_in(x,y,all) are rather unpredictable, but more likely "false" is returned.
For points we have - in theory - just three states:P1: point is inside polygonP2: point is on the edge of a polygonP3 point is outsideThe current code ignores the method parameter and the halo problem and returns true for P1 and P2 and false for P3.
The current code treats polygons like lines but case L3 may return different results as the code tries to find out if the tested polygon is inside a hole.
Gerd
________________________________________Von: mkgmap-dev < mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin < rwb-mkg...@jagit.co.uk>Gesendet: Mittwoch, 5. Februar 2020 07:58An: Development list for mkgmapBetreff: Re: [mkgmap-dev] Branch is_in ready for a first test
Hi all
I'm still of the opinion that it is better to specify a 'method'parameter rather than return 3 flags for the following reasons:
- for polygons, it is only meaningful to need to know if ANY or ALL ofthe rule polygon is in the target.
- for lines, it was thought better for the 'ALL' case to allow/ignorethe line touching the edge, as long as the rest was IN. This tuningability is lost unless keywords are used.
- for points, I agree that returning one of the 3 flags seems to makesense, but I still maintain it is clearer to have methods that askin/in-or-on/on rather than the equivalent test with a regexp for the on-or-on case.
- for many methods, optimisation is possible, eg. 1/ the processing canstop as soon an element is found that determines the result. 2/ Thetarget polygons can be processed one-by-one instead of joined together.
- to express the line question any-in-or-on with a regexp is messy andobscure. In the java coding of the function, I expect it to use flagslike IN/ON/OUT, and it is trivial for the Java to convert these, inconjunction with the 'method', to a boolean result that is easilyhandled at the rule level.
- negation of the function is trivial when it returns a boolean.
- method keyword is more readable (and writeable) than bitstring regextest.
- the method keyword allows extendability, eg 1/ different accuracyrequirements, 2/ magic keywords that could split the rule object intothe parts that return true and the parts that return false.
- Mike's idea of 'coincident' - see later.
I don't thing we should consider line/polygon splitting at the moment.
@jan, With my table:simplifieda) some-in-none-out(all) IN and not OUTb) all-in-or-on (IN or ON) and not OUT not OUTc) all-on ON and not (OUT or IN) not (OUT or IN)d) any-in(any) INe) any-in-or-on IN or ONI was attempting to show precisely the meaningful line cases in termsof the flags, which I hoped to remain hidden. Without the methodkeyword, you'd have to implement the equivalent for the cases yourequired with a regexp to test the flags.
Mike Baggaley, on 16th Jan, suggested the following keywords; I'veadded a transliteration of his description of how these correspond tothe flags:all_inside IN and not (ON or OUT)a) touching IN and not OUTb) all_touching not OUTd) some_inside INe) some_touching IN or ONcoincident all points of rule object match the target polygon
I think the use of 'touching' here is confusing and it is best to coverall possibilities with a suitable method in 1 call to the function.
@gerd, if I haven't convinced you that method keywords are better, itis probably better to use a single letter Y/N or T/F.
Ticker
On Wed, 2020-02-05 at 00:49 +0100, jan meisters wrote:Hi all,thanks for the ongoing development.I like the abstraction that Gerd has given, be it with digits orletters; and its implementation of all Tickers 6 cases.With his explanation I could easily reproduce my simple butsatisfying cemetery results as by 4418.On Tickers argumentation my idea is limited, as I´m not able tounderstand all code internals he might has in mind.Despite this - and if I got him correctly that it´s this logic wehave now - it sounds adequate as well for what I can overlook.Regarding the splitting proposed by Arndt I think it´s not alwaysuseful.To handle improper drawings in OSM I´d prefer such a behaviour to bedefinable then.Don´t know if I could need it.Jan_______________________________________________mkgmap-dev mailing list_______________________________________________mkgmap-dev mailing list_______________________________________________mkgmap-dev mailing list
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev