<!doctype html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<div>
Hi,
</div>
<div>
<br>
</div>
<div>
a path in a forest should be presented thik:
<br>
</div>
<div>
<pre class="tw-data-text tw-text-large tw-ta" dir="ltr" data-placeholder="Übersetzung"> ______________<br> | forest |<br> | |<br>=============================<br> | |</pre>
</div>
<div>
| |
</div>
<div>
____________
</div>
<div>
<br>
</div>
<div>
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.
</div>
<div>
<br>
</div>
<div>
<pre class="tw-data-text tw-text-large tw-ta" dir="ltr" data-placeholder="Übersetzung"> ______________<br> | forest |<br> | |<br>------0============0-------<br> | |</pre>
<div>
| |
</div>
<div>
____________
</div>
<div>
<br>
</div>
<div>
greets
</div>
<div>
Arndt
</div>
<div>
<br>
</div>
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<blockquote type="cite">
<div>
Gerd Petermann <
<a href="mailto:gpetermann_muenchen@hotmail.com">gpetermann_muenchen@hotmail.com</a>> hat am 5. Februar 2020 um 09:51 geschrieben:
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div>
Hi Ticker,
</div>
<div>
<br>
</div>
<div>
I am lost in alternatives. I don't like the current solution and I also don't like my "three bit flags" solution.
</div>
<div>
With the current code we can only distinguish 4 cases, your original list contained 6 cases, the newer 5.
</div>
<div>
What should be changed in current code (r4228)? More or other method parameters?
</div>
<div>
<br>
</div>
<div>
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.
</div>
<div>
<br>
</div>
<div>
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.
</div>
<div>
<br>
</div>
<div>
If I got you right you suggest to introduce more methods? As a reminder, these are the 6 different cases for a line:
</div>
<div>
L1: all of the line is outside the polygon
</div>
<div>
L2: some of the line is outside and the rest touches or runs along the polygon edge
</div>
<div>
L3: all of the line runs along the polygon edge
</div>
<div>
L4: some of the line is inside and the rest touches or runs along.
</div>
<div>
L5: all of the line is inside the polygon
</div>
<div>
L6: 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.
</div>
<div>
<br>
</div>
<div>
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.
</div>
<div>
<br>
</div>
<div>
For points we have - in theory - just three states:
</div>
<div>
P1: point is inside polygon
</div>
<div>
P2: point is on the edge of a polygon
</div>
<div>
P3 point is outside
</div>
<div>
The current code ignores the method parameter and the halo problem and returns true for P1 and P2 and false for P3.
</div>
<div>
<br>
</div>
<div>
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.
</div>
<div>
<br>
</div>
<div>
Gerd
</div>
<div>
<br>
</div>
<div>
________________________________________
</div>
<div>
Von: mkgmap-dev <
<a href="mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk">mkgmap-dev-bounces@lists.mkgmap.org.uk</a>> im Auftrag von Ticker Berkin <
<a href="mailto:rwb-mkgmap@jagit.co.uk">rwb-mkgmap@jagit.co.uk</a>>
</div>
<div>
Gesendet: Mittwoch, 5. Februar 2020 07:58
</div>
<div>
An: Development list for mkgmap
</div>
<div>
Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
</div>
<div>
<br>
</div>
<div>
Hi all
</div>
<div>
<br>
</div>
<div>
I'm still of the opinion that it is better to specify a 'method'
</div>
<div>
parameter rather than return 3 flags for the following reasons:
</div>
<div>
<br>
</div>
<div>
- for polygons, it is only meaningful to need to know if ANY or ALL of
</div>
<div>
the rule polygon is in the target.
</div>
<div>
<br>
</div>
<div>
- for lines, it was thought better for the 'ALL' case to allow/ignore
</div>
<div>
the line touching the edge, as long as the rest was IN. This tuning
</div>
<div>
ability is lost unless keywords are used.
</div>
<div>
<br>
</div>
<div>
- for points, I agree that returning one of the 3 flags seems to make
</div>
<div>
sense, but I still maintain it is clearer to have methods that ask
</div>
<div>
in/in-or-on/on rather than the equivalent test with a regexp for the on
</div>
<div>
-or-on case.
</div>
<div>
<br>
</div>
<div>
- for many methods, optimisation is possible, eg. 1/ the processing can
</div>
<div>
stop as soon an element is found that determines the result. 2/ The
</div>
<div>
target polygons can be processed one-by-one instead of joined together.
</div>
<div>
<br>
</div>
<div>
- to express the line question any-in-or-on with a regexp is messy and
</div>
<div>
obscure. In the java coding of the function, I expect it to use flags
</div>
<div>
like IN/ON/OUT, and it is trivial for the Java to convert these, in
</div>
<div>
conjunction with the 'method', to a boolean result that is easily
</div>
<div>
handled at the rule level.
</div>
<div>
<br>
</div>
<div>
- negation of the function is trivial when it returns a boolean.
</div>
<div>
<br>
</div>
<div>
- method keyword is more readable (and writeable) than bitstring regex
</div>
<div>
test.
</div>
<div>
<br>
</div>
<div>
- the method keyword allows extendability, eg 1/ different accuracy
</div>
<div>
requirements, 2/ magic keywords that could split the rule object into
</div>
<div>
the parts that return true and the parts that return false.
</div>
<div>
<br>
</div>
<div>
- Mike's idea of 'coincident' - see later.
</div>
<div>
<br>
</div>
<div>
I don't thing we should consider line/polygon splitting at the moment.
</div>
<div>
<br>
</div>
<div>
@jan, With my table:
</div>
<div>
simplified
</div>
<div>
a) some-in-none-out(all) IN and not OUT
</div>
<div>
b) all-in-or-on (IN or ON) and not OUT not OUT
</div>
<div>
c) all-on ON and not (OUT or IN) not (OUT or IN)
</div>
<div>
d) any-in(any) IN
</div>
<div>
e) any-in-or-on IN or ON
</div>
<div>
I was attempting to show precisely the meaningful line cases in terms
</div>
<div>
of the flags, which I hoped to remain hidden. Without the method
</div>
<div>
keyword, you'd have to implement the equivalent for the cases you
</div>
<div>
required with a regexp to test the flags.
</div>
<div>
<br>
</div>
<div>
Mike Baggaley, on 16th Jan, suggested the following keywords; I've
</div>
<div>
added a transliteration of his description of how these correspond to
</div>
<div>
the flags:
</div>
<div>
all_inside IN and not (ON or OUT)
</div>
<div>
a) touching IN and not OUT
</div>
<div>
b) all_touching not OUT
</div>
<div>
d) some_inside IN
</div>
<div>
e) some_touching IN or ON
</div>
<div>
coincident all points of rule object match the target polygon
</div>
<div>
<br>
</div>
<div>
I think the use of 'touching' here is confusing and it is best to cover
</div>
<div>
all possibilities with a suitable method in 1 call to the function.
</div>
<div>
<br>
</div>
<div>
@gerd, if I haven't convinced you that method keywords are better, it
</div>
<div>
is probably better to use a single letter Y/N or T/F.
</div>
<div>
<br>
</div>
<div>
Ticker
</div>
<div>
<br>
</div>
<div>
On Wed, 2020-02-05 at 00:49 +0100, jan meisters wrote:
</div>
<blockquote type="cite">
<div>
Hi all,
</div>
</blockquote>
<blockquote type="cite">
<div>
thanks for the ongoing development.
</div>
</blockquote>
<blockquote type="cite">
<div>
I like the abstraction that Gerd has given, be it with digits or
</div>
<div>
letters; and its implementation of all Tickers 6 cases.
</div>
<div>
With his explanation I could easily reproduce my simple but
</div>
<div>
satisfying cemetery results as by 4418.
</div>
</blockquote>
<blockquote type="cite">
<div>
On Tickers argumentation my idea is limited, as I´m not able to
</div>
<div>
understand all code internals he might has in mind.
</div>
<div>
Despite this - and if I got him correctly that it´s this logic we
</div>
<div>
have now - it sounds adequate as well for what I can overlook.
</div>
</blockquote>
<blockquote type="cite">
<div>
Regarding the splitting proposed by Arndt I think it´s not always
</div>
<div>
useful.
</div>
<div>
To handle improper drawings in OSM I´d prefer such a behaviour to be
</div>
<div>
definable then.
</div>
<div>
Don´t know if I could need it.
</div>
</blockquote>
<blockquote type="cite">
<div>
Jan
</div>
</blockquote>
<blockquote type="cite">
<div>
_______________________________________________
</div>
<div>
mkgmap-dev mailing list
</div>
<div>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a>
</div>
<div>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noopener" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a>
</div>
</blockquote>
<div>
_______________________________________________
</div>
<div>
mkgmap-dev mailing list
</div>
<div>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a>
</div>
<div>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noopener" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a>
</div>
<div>
_______________________________________________
</div>
<div>
mkgmap-dev mailing list
</div>
<div>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a>
</div>
<div>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noopener" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a>
</div>
</blockquote>
</body>
</html>