Opened 11 years ago

Closed 3 years ago

#240 closed defect (wontfix)

ST_SimplifyPreserveTopology documentation unclear on intersections within a MultiPolygon

Reported by: perchrh Owned by: robe
Priority: medium Milestone: PostGIS Fund Me
Component: postgis Version:
Keywords: Cc:


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.


Change History (10)

comment:1 Changed 11 years ago by 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.

comment:2 Changed 11 years ago by 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.


comment:3 Changed 11 years ago by 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.

comment:4 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by pramsey

How do you feel about r4857?

comment:6 Changed 11 years ago by 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.

comment:7 Changed 11 years ago by 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?

comment:8 Changed 11 years ago by robe

Milestone: PostGIS 1.5.0PostGIS Future

Hmm why is this mine?

comment:9 Changed 3 years ago by robe

Milestone: PostGIS FuturePostGIS Fund Me

Milestone renamed

comment:10 Changed 3 years ago by robe

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.