Geometry Boost List: Re: [geometry] relate() interface

Subject: Re: [geometry] relate() interface
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2015-05-01 13:19:28

Hi,

2015-04-28 18:07 GMT+02:00 Mats Taraldsvik <mats.taraldsvik_at_[hidden]>:

> On Apr 28, 2015 1:41 PM, "Adam Wulkiewicz" <adam.wulkiewicz_at_[hidden]>
> wrote:
> >
> >
> > Mats Taraldsvik wrote:
> >>
> >> Hi,
> >>
> >> On Tue, Apr 28, 2015 at 1:47 AM, Adam Wulkiewicz <
> adam.wulkiewicz_at_[hidden]> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Recently a user requested to add a user-defined spatial predicate:
> >>> https://svn.boost.org/trac/boost/ticket/11232
> >>> relate() is there in the details from quite some time so I thought
> it's a good time to make it official. But before that we should think about
> the interface.
> >>>
> >>> First, the requirements. I think it should be possible to:
> >>> - return a DE9IM matrix
> >>> - check DE9IM run-time mask
> >>> - check DE9IM compile-time mask
> >>> - pass ORed masks and use them directly in the check
> >>> - possible addition of other IMs though I doubt that anything else
> than DE9IM will be supported
> >>>
> >>> FYI, all of the above is supported in the details. But the interface
> need to be polished. I'm thinking about something like this:
> >>>
>
I've prepared a PR:
https://github.com/boostorg/geometry/pull/288

> >>> // basic, return DE9IM matrix
> >>> std::string matrix = relate(g1, g2);
> >>
> >>
> >> What about using std::bitset? It has a constexpr constructor and can
> convert to/from a std::string (with custom characters indicating true /
> false). No dynamic allocations necessary :)
> >>
> >> http://en.cppreference.com/w/cpp/utility/bitset
> >>
> >> Binary logic is also supported out of the box.
> >
> >
> > Unfortunately a matrix or a mask should be able to contain at least 5
> different "digits" (*, T, F, 1, 2). See:
> http://en.wikipedia.org/wiki/DE-9IM
> > Other dimensions could be there too so effectively there could be 12 or
> 13 "digits". They're not in the standard but this way we'd support
> n-dimensional non-standard geometries like Point, Box or N-sphere.
> >
> > But AFAIU your point is that you'd prefer to store the matrix or mask in
> a static memory. The most simple thing would be to have char[9]. And this
> is how it's done internally. Of course we could think about compressing it
> somehow in the future.
> > Those two the most basic variants was proposed only for users
> convenience. But maybe indeed more clear would be to force the users to
> always use the matrix representation from de9im namespace:
> >
> > de9im::matrix m = relate(g1, g2);
> >
> >
> > ?
> >
>
> Ok, I understand. Yes, I think that exposing the de9im type directly is
> better.
>

I decided to implement it as a separate function:

de9im::matrix m = relation(g1, g2);

This way it's more clear that the purpose of the function is different. Two
use-cases aren't mixed. Furthermore this way it should be simpler to add
more parameters, e.g. Strategy in the future.

If there were other matrices added in the future the use case could look
like this:

de4im::matrix m = relation<de4im>(g1, g2);

It's probable that the above call would be faster since less matrix
elements would be calculated.

> >>
> >>>
> >>>
> >>> // basic, check DE9IM run-time mask
> >>> bool res = relate(g1, g2, "T********");
> >
>

I haven't implement this yet. It could be added if needed.

> >
> > this one could look the same or we could always require the creation of
> the de9im::mask explicitly so:
> >
> > bool res = relate(g1, g2, de9im::mask("T********"));
> >
>

So this is required now.

> >
> >>>
> >>> We need a way to pass ORed masks. We have a few options but I'm
> thinking about this:
> >>>
> >>> bool res = relate(g1, g2, de9im::mask("FT*******") ||
> >>>                           de9im::mask("F**T*****") ||
> >>>                           de9im::mask("F***T****"));
> >>>
> >>> Compile-time masks:
> >>>
> >>> typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
> >>> bool res = relate<II>(g1, g2);
> >>>
> >>> or just
> >>>
> >>> bool res = relate(g1, g2, II());
> >>>
> >>> In the second case the same technique for ORing masks could be used.
> Otherwise we'd be forced to gather them in some type like, de9im::or<M1,
> M2, M3, M4, ...>, mpl::vector<> or boost::tuple<>. Either way the compiler
> should be able to optimize I think. Besides it's implemented like this
> anyway in the details. The third parameter is just created by default using
> the default ctor. This of course can be changed. So again, we have two
> options:
> >>>
> >>> typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
> >>> typedef de9im::static_mask<'*','*','*','*','T','*','*','*','*'> BB;
> >>> bool res = relate<de9im::or<II, BB>>(g1, g2);
> >>>
> >>> or
> >>>
> >>> de9im::static_mask<'T','*','*','*','*','*','*','*','*'> ii;
> >>> de9im::static_mask<'*','*','*','*','T','*','*','*','*'> bb;
> >>>
> >>> bool res = relate(g1, g2, ii || bb);
>

This is unchanged.
Actually using the operator|| for static_masks is required. The compiler
should optimize the code as if ORed masks type was created explicitly.

Regards,
Adam