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

Wed Feb 5 06:58:08 GMT 2020

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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev