Re: [mkgmap-dev] Branch is_in ready for a first test

Wed, 05 Feb 2020 09:09:11 -0800

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 < [email protected]> 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 polygon
L2: some of the line is outside and the rest touches or runs along the polygon edge
L3: all of the line runs along the polygon edge
L4: some of the line is inside and the rest touches or runs along.
L5: all of the line is inside the polygon
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.

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 polygon
P2: point is on the edge of a polygon
P3 point is outside
The 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 < [email protected]> im Auftrag von Ticker Berkin < [email protected]>
Gesendet: Mittwoch, 5. Februar 2020 07:58
An: Development list for mkgmap
Betreff: 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 of
the rule polygon is in the target.

- for lines, it was thought better for the 'ALL' case to allow/ignore
the line touching the edge, as long as the rest was IN. This tuning
ability is lost unless keywords are used.

- for points, I agree that returning one of the 3 flags seems to make
sense, but I still maintain it is clearer to have methods that ask
in/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 can
stop as soon an element is found that determines the result. 2/ The
target 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 and
obscure. In the java coding of the function, I expect it to use flags
like IN/ON/OUT, and it is trivial for the Java to convert these, in
conjunction with the 'method', to a boolean result that is easily
handled at the rule level.

- negation of the function is trivial when it returns a boolean.

- method keyword is more readable (and writeable) than bitstring regex
test.

- the method keyword allows extendability, eg 1/ different accuracy
requirements, 2/ magic keywords that could split the rule object into
the 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:
simplified
a) some-in-none-out(all) IN and not OUT
b) all-in-or-on (IN or ON) and not OUT not OUT
c) all-on ON and not (OUT or IN) not (OUT or IN)
d) any-in(any) IN
e) any-in-or-on IN or ON
I was attempting to show precisely the meaningful line cases in terms
of the flags, which I hoped to remain hidden. Without the method
keyword, you'd have to implement the equivalent for the cases you
required with a regexp to test the flags.

Mike Baggaley, on 16th Jan, suggested the following keywords; I've
added a transliteration of his description of how these correspond to
the flags:
all_inside IN and not (ON or OUT)
a) touching IN and not OUT
b) all_touching not OUT
d) some_inside IN
e) some_touching IN or ON
coincident all points of rule object match the target polygon

I think the use of 'touching' here is confusing and it is best to cover
all possibilities with a suitable method in 1 call to the function.

@gerd, if I haven't convinced you that method keywords are better, it
is 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 or
letters; and its implementation of all Tickers 6 cases.
With his explanation I could easily reproduce my simple but
satisfying cemetery results as by 4418.
On Tickers argumentation my idea is limited, as I´m not able to
understand all code internals he might has in mind.
Despite this - and if I got him correctly that it´s this logic we
have now - it sounds adequate as well for what I can overlook.
Regarding the splitting proposed by Arndt I think it´s not always
useful.
To handle improper drawings in OSM I´d prefer such a behaviour to be
definable then.
Don´t know if I could need it.
Jan
_______________________________________________
mkgmap-dev mailing list
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 


_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Reply via email to