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
> [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
