ST_SimplifyPreserveTopology documentation unclear on intersections within a MultiPolygon

[perchrh]

Reading the manual on ST_SimplifyPreserveTopology (1) I cannot say if it will avoid introducing intersections between polygons in a MultiPolygon, or if it only avoids self-intersections in each polygon.

This uncertainty can be cleared up by specifying which object type(s) are referred to in the phrase "..simplification occurs on a object-by-object basis".

mleslie suggested Kevin or Regina will know, and that I assign robe.

(1) ​http://postgis.refractions.net/documentation/manual-svn/ST_SimplifyPreserveTopology.html

[robe]

Haven't given that much thought, but I always seem to end up with valid multipolygons at the end. Kevin you know? Maybe Martin,Paul, Sandro, or Mateusz can chime in. I see Sandro and Mateusz name in the GEOS log of porting that function simplify/TopologyPreservingSimplifier.

I had always assumed it works with each polygon individually and does a check at the end to ensure the multipolygon is still valid.

[kneufeld]

The JTS docs say "The result rings touch at no more than the number of touching point in the input (although they may touch at fewer points)". So this too is unclear if the preservation occurs at just the polygon level or also at the multipolygon level.

​http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/simplify/TopologyPreservingSimplifier.html

Martin?

[kneufeld]

a forward from Martin Davis...

The JTS doc for TPS is:

* Simplifies a geometry, ensuring that
* the result is a *valid *geometry having the
* same dimension and number of components as the input.
* The simplification uses a maximum distance difference algorithm
* similar to the one used in the Douglas-Peucker algorithm.
* <p>
* In particular, if the input is an areal geometry
* ( {@link Polygon} or {@link *MultiPolygon*} ):
* <ul>
* <li>The result has the same number of shells and holes (rings) as the input,
* in the same order
* <li>The result rings touch at <b>no more</b> than the number of touching point in the input
* (although they may touch at fewer points). * *(The key implication of this constraint is that the
* output will be topologically valid if the input was.) *
* </ul>

Note the bolded text - this answers the question. If you can think of a way to make this clearer, let me know.

[perchrh]

I'm used to 'rings touching' meaning they share an edge or a vertex, not that an edge of one ring intersects an edge of another ring. That makes me uncertain to if Davis is saying yes or no.

To make this clearer I suggest simply stating if any new intersections between rings are introduced or not in the documentation.

[pramsey]

How do you feel about r4857?

[perchrh]

r4857 doesn't add any new information, the behavior regarding self-intersections has always been clear. I'll think about how to phrase the right question and get back to you.

[perchrh]

In the ESRI shapefile standard, a Record with shapetype Polygon is a collection of zero or more Rings (in other terms: a MultiPolygon containing multiple Polygons). The rings may intersect each other and cannot self-intersect.

It is clear that ST_SimplifyPreserveTopology doesn't introduce self-intersections and doesn't introduce intersections between Polygons if there were none in the input.

My question, that I didn't manage to get answered by a quick look at the code is, is the processing of these valid MultiPolygons with intersecting Polygons guaranteed to result in a MultiPolygon with no new intersections? Or does it just guarantee that the intersection count will not be higher than in the input? To put it another way, if I have a MultiPolygon with three polygons, two of them intersecting each other (A and B), is it possible that B and C will intersect after ST_SimplifyPreserveTopology?

[robe]

Hmm why is this mine?

[robe]

Milestone renamed