Boost logo

Geometry :

Subject: Re: [geometry] relate() interface
From: Mats Taraldsvik (mats.taraldsvik_at_[hidden])
Date: 2015-04-28 12:07:00


Hi Adam,

On Apr 28, 2015 1:41 PM, "Adam Wulkiewicz" <adam.wulkiewicz_at_[hidden]>
wrote:
>
> Hi Mats,
>
> 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:
>>>
>>> // 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.

>>
>>>
>>>
>>> // 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 mailing list
> Geometry_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/geometry
>



Geometry list run by mateusz at loskot.net