Boost logo

Geometry :

Subject: Re: [geometry] relate() interface
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2015-04-28 07:41:16


Hi Mats,

Mats Taraldsvik wrote:
> Hi,
>
> On Tue, Apr 28, 2015 at 1:47 AM, Adam Wulkiewicz
> <adam.wulkiewicz_at_[hidden] <mailto: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:
>
> // 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);

?

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

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********"));

>
> 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);
>
> What do you think?
> Do you like the names?
> Any ideas are welcome.
>
> E.g. maybe the names should be:
> - de9im::dynamic_mask and de9im::mask (instead of static_mask)
> - de9im::dmask and de9im::smask
> - de9im::mask_d and de9im::mask_s
> - ?
>
> Regards,
> Adam
>



Geometry list run by mateusz at loskot.net