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

Subject: Re: [geometry] relate() interface
From: Andrew Hundt (athundt_at_[hidden])
Date: 2015-04-28 12:08:32

Is there an explanation of what DE9IM is somewhere?

Cheers!
Andrew Hundt

On Tue, Apr 28, 2015 at 12:07 PM, Mats Taraldsvik <mats.taraldsvik_at_[hidden]
> wrote:

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