Geometry Boost List: [ggl] "touches" in boost.geometry?

Subject: [ggl] "touches" in boost.geometry?
From: Barend Gehrels (barend)
Date: 2011-10-20 17:45:35

Hi,

On 20-10-2011 12:02, Adam Wulkiewicz wrote:
> Mateusz ?oskot wrote:
>> On 19 October 2011 23:15, Adam Wulkiewicz<adam.wulkiewicz_at_[hidden]>  wrote:
>>> Mateusz Loskot wrote:
>>>> It's imprecise, though it may be understood as self-contradicting.
>>>>
>>>> touches(A, B) is true if and only if
>>>> intersect(interior(A), interior(B)) is empty
>>>> and
>>>> intersect(boundary(A), boundary(B)) is non-empty
>>>>
>>>> I think in terms of the DE-9IM and I believe it's a good
>>>> idea to consider or DE-9IM  as basis of all the geometric
>>>> relation predicates. It's a generic technique.
>>> It would definietly increase expressiveness of GGL. I feel lack of some
>>> functions describing relations between geometires. In terms of geometries
>>> which are interiors+boundires there is no touches()/meets() and this
>>> intersects_without_boundry() i mentioned earlier. And in terms of boundries
>>> we have only overlaps().
>>>
>>> It would be nice if default versions of algorithms worked on geometries
>>> (interiors+boundries) and there would be additional wrappers to pass
>>> specific parts of the geometry.
>>>
>>> But is it possible with current design of GGL Barend?
>> Yes, I'd let Barend to answer/decide as it's quite substantial issue
>> for overall library.

The "relate" predicate using DE-9IM is certainly planned as it is an 
OGC-SF requirement.

I don't understand the idea of wrappers exactly. I mean, the predicates 
that there are (intersects, touches, overlaps, within, etc) all have 
specific and exact meanings according to the OGC specifications (are 
they known to all involved here?). So we cannot and should not change them.

Of course we can add additional algorithms as "meets" if we specify 
their meaning, just as is done by "covered_by" which is also used by 
some databases.

It is/will be possible to retrieve a boundary using the planned view_as 
function, so you will get the boundary of a polygon and can do 
algorithms with them. That is then considered as a linestring. But for 
the interior-without-boundary that is a little harder I'm afraid.

>>
>> There could be an utility that calculates the intersection matrix for
>> geometries anyway.
>> And a generic relate(A, B) predicate resulting in the intersection
>> matrix configuration.
> It seems I previously have sent my reply to Mateusz only. Sorry for
> inconvenience.
>
> I've forgotten about one function - disjoint_with_boundry(). Of course
> names I've used are just examples. Ideally we would have one function
> and template/function parameters would describe the relationship. I
> recall that we talked about it earlier and that the first template
> parameter can't be used to achieve this goal:
>
> intersects<without_boundry>(A, B); // impossible
>
> But it probably is possible to pass wrapped geometries. Passing them
> should allow us to express various relationships and it can be
> implemented using existing interface.

Can you give a concrete example?

Regards, Barend