Subscribe to this thread
Home - General / All posts - GeomOverlayIntersecting and GeomOverlayTopologyIntersect
yves61
248 post(s)
#31-Mar-21 10:30

I am getting time and again confused by the difference in concept between GeomOverlayIntersecting and GeomOverlayTopologyIntersect.

GeomOverlayIntersecting is clear : this is about intersecting only

GeomOverlayTopologyIntersect is confusing : this is about intersecting, but also about containing or contained or 100% identical overlap between overlay and drawing objects.

Why is there a difference between both concepts ?Would it not be better to have both items cover the same concept: just intersecting like in GeomOverlayIntersecting ? or have GeomOverlayTopologyIntersect called differently but not ...Intersect.

adamw


9,588 post(s)
#31-Mar-21 13:39

GeomOverlayTopologyXxx functions change geometry, while GeomOverlayXxx don't (they just select geometry by spatial criteria). The names of GeomOverlayTopologyXxx functions come from ESRI topology overlays. The names of GeomOverlayXxx functions come from Manifold 8 list of spatial relations (which we would like to straighten up one day).

yves61
248 post(s)
#31-Mar-21 15:26

Adam , thank you. I understood the function difference between GeomOverlayXxx and GeomOverlayTopologyXxx , but am confused that although both have "Intersect/Intersecting" in the naming the GeomOverlayTopologyIntersect takes into account much more than mere "intersecting" 'overlay' and 'drawing objects'. It would indeed be great to avoid confusion in terminology within M9 and have the naming straighten up , - or the functions behind them.

adamw


9,588 post(s)
#31-Mar-21 16:30

The different meanings of Intersect / Intersecting here are because the first word comes from ESRI's use for a topology overlay and the second from Manifold 8's use for a spatial overlay. We won't change the use of Intersect for the function that performs an ESRI topology overlay. We cannot not use Intersect in the name of that function, if we invent our own word, nobody will understand what the function does. We will likely change the meaning of Intersecting for the function that performs a spatial relation. However, because ESRI's use of Intersect for a topology overlay is different than the use of Intersecting in any system of spatial relations, even the one cleaner than Manifold 8's, there will remain two words "Intersect" which mean different things, this is unavoidable. Maybe we should replace the word Overlay in one set of functions with something else to emphasize that these are different things.

tjhb

9,700 post(s)
#31-Mar-21 20:33

I don't if this is exactly right, but hopefully it's close.

I think the topology overlay meaning of intersects is close to a common-sense meaning, that is, the A intersects B if A and B share some location. That corresponds to the metaphor of the "cookie cutter" that is used to define the topology overlay functions. The metaphor is taken literally, as if we really were working with dough. So complete containment is included here, as is touching only at an edge (I think).

On the other hand, the Manifold topology tests are designed so that the meanings of Intersects, Adjacent and Contains do not overlap. For any given pair of objects, at most one of these three can be true (although if any is true then Touches will also be true). Intersects is the most interesting case, exactly because it departs the most from common, non-spatial usage (not only in baking), although personally I often have to check whether an area object contains itself. These mutually exclusive functions are more useful than if they were allowed to overlap, since fewer tests are generally required.

(In the latter case, I find it helps to think of Intersects as meaning "merely intersects".)

adamw


9,588 post(s)
#01-Apr-21 09:27

The biggest clash here is different.

Intersect in topology overlays is a set operation. All topology overlays intersect everything with everything between the two object sets. It's what they return after that differs.

Here are two example object sets:

Here's Identity:

Here's Intersect:

Etc.

tjhb

9,700 post(s)
#01-Apr-21 09:59

I think that's what I said? What I tried to say. I didn't cover identity, there was no need.

adamw


9,588 post(s)
#01-Apr-21 16:48

I guess our posts complement each other.

Yes, our Intersecting (Manifold 8 spatial overlay) excludes Contained and Adjacent. This is correct. But ESRI's Intersect also excludes Adjacent. If two areas share a common boundary, their ESRI's Intersect will return nothing. Despite there being some common locations. The common-sense meaning of "intersects" as "shares one or more locations" does not apply, it's more complex.

I find it simpler to think of ESRI's terms for topology overlays as set operations. Ie, we first deal with geometry, always in the same way, by splitting objects into parts which don't degenerate into lower dimensions. Then we take some of the parts and throw away others, according to what the topology overlay is. Then we perhaps join some of the parts back together, also according to what the topology overlay is.

Maybe I think of this as a difference to what Manifold 8 spatial overlays do because our spatial tests work differently than that - we don't "first deal with geometry" and then classify the result, we have separate functions that perform different geometric computations (some shared, some unique to the operation).

When we get to cleaning up the vocabulary for spatial relations, we will likely re-use OGC's table, with Intersecting meaning sharing a common location = not Disjoint. That would be what we are currently calling Touching. (Touching will in turn morph into "common locations with at least one object having all of them on the boundary" - this might be difficult to comprehend without a picture, although the intent is simple - to disallow shared locations between the interiors. Somewhat similar to the current Adjacent. Thankfully, Adjacent will simply cease to exist instead of morphing into something else as well.)

tjhb

9,700 post(s)
#01-Apr-21 21:27

Thanks, that clears it up better.

It may be just my age, but I half-hope you don't "clean these things up" in the ways you describe. OGC Touching sounds intuitive, in its own way, but I can't immediately think of a use for it. Whereas I use current Manifold Adjacent all the time. I suppose to reproduce that with OGC tests, we would need to use Touching, but first ensure that both objects were lines or points, converting areas to boundaries as necessary (and adding a new index). Well, that would be OK, but is there a good reason to make a new gap to be filled? Is OGC compliance the only attraction?

Also, on this basis, an area object would not touch itself, which would take get some getting used to. (And it would now intersect itself.)

Breaking changes happen, of course, but it's worth noting that wholesale semantic changes like this would mean that anyone wanting to reuse old code would need to maintain knowledge of both sets of definitions, the old and the new, as well as the date and version of the changes. Translation would be tricky at times and a probable source of error.

Especially perhaps between users--think for example of all the existing spatial code on the forum. Changing the semantics would render much of this code useless, or confusing (requiring endless re-explanation) or worse, a source of error, usually obvious but sometimes subtle.

So yes, I half-hope you don't make those changes.

(Now, someone coming fresh to Manifold from, say, PostGIS, might well say the opposite.)

One way around most of this (at least a mitigation) would be to ensure that no function names were retained or reused after the new semantics.

(You could even retain both sets of semantics, replacing the "Geom" prefix for current functions with "OGC" for the new ones. I'm not sure that would be wise, it would need some thought!)

adamw


9,588 post(s)
#02-Apr-21 14:15

Yeah, we kind of dread it as well. We'll surely make it so that function names are different so that queries, for one thing, stop working and you have to go and correct them - which is when you'd hopefully switch to the different nomenclature - but there's also UI where "touching" will suddenly start meaning something different.

On the other hand, these clashes with OGC nomenclature already exist de-facto, they just hit new users coming to Manifold instead of existing users. It'd be very good to remove them, otherwise we will have to keep explaining that (Manifold's) Touching is not the same as (OGC's) ST_Touching forever.

Maybe we will come with some UI solution for existing users - eg, add an option to use Manifold 8 nomenclature for spatial relations in places like Join - by default we'd have a list of "intersects" / "touches" / "overlaps" / etc, and if you turn the option on, it'd be "intersects (M8: touches)" / "touches (M8: adjacent)" (well, it's slightly different than adjacent, but you get the idea) / etc. Or maybe if you turn the option on, the list just gets additional items for "M8: touches" / "M8: adjacent" and so on.

We'll see.

tjhb

9,700 post(s)
#03-Apr-21 09:13

Thanks. Well, we are in good hands.

For what it's worth, given that functions will have new names, I'd vote for a clean break. Move to OGC semantics, without recourse to old functions. Yes transform names will present a residual problem--but these do not (cannot) reuse old code (old workflows--yes, but I think there is a degree less concern there).

I think a manual topic with high visibility would also be worthwhile, showing formal logical relations between old Manifold geometry tests and new OGC tests, followed by a table of translation recipes.

And can Manifold please join OGC? There is little point in complying without belonging and participating, don't you think? In due course it would be great to see Manifold mentioned on the OGC Simple Features wikipedia page, for example.

Dimitri


6,560 post(s)
#01-Apr-21 11:23

There's also this useful comment in the doc:

Two meanings of "intersect"- There are two notions of what "intersect" should mean, both of which are used by Manifold. Topology overlays, as discussed in the Topology Overlaystopic, use the classic set-theoretic meaning of "intersect," in which objects that are entirely containedby other objects are said to intersectas well. A different meaning is used in Select pane templates and spatial joins in Join, where an object that is entirely containedwithin another object does not "intersect" that object but is containedby that object. In the Join dialog and in Select pane templates, an object only intersectsanother object if some part of the object is outside the other object andsome part is within the other object. This allows the use of containedand containingto provide different selection criteria instead of simply duplicating what intersectdoe

yves61
248 post(s)
#02-Apr-21 06:28

With all due respect, to me it seems still a pity to use two different meanings of "intersect" within a single software application.

Dimitri


6,560 post(s)
#02-Apr-21 12:02

The pity is that are different meanings of "intersect" used in GIS. ESRI uses one meaning in their topology overlays nomenclature, and other systems use a different meaning in geometric operations.

If you want Manifold to provide a direct analog to the ESRI overlay tools, and also to support geometry operations as other systems (including Manifold) do it, then inevitably you will have two different meanings of "intersect" in play.

It's hard to learn how to use topology overlays without learning that they use distinctively ESRI nomenclature ("identity"? "update"?), so it seems you can trust people to be aware that with those tools they're in ESRI-land when it comes to nomenclature and functionality.

Manifold User Community Use Agreement Copyright (C) 2007-2019 Manifold Software Limited. All rights reserved.