Opened 10 years ago

Closed 10 years ago

#2864 closed defect (invalid)

ST_Envelope does not contain all points of invalid geometry

Reported by: dbaston Owned by: pramsey
Priority: low Milestone: PostGIS 2.1.4
Component: postgis Version: 1.5.X
Keywords: Cc:

Description

I'm calling this a "defect" although I understand that is open to debate…

When called on an invalid polygon whose interior rings go outside of an exterior ring, ST_Envelope can return a box that does not contain all points that make up the geometry. Simple example:

SELECT ST_AsText(ST_Envelope('POLYGON ((0 0, 10 0, 10 10, 0 10, 0 0), (1 1, 1 2, 2 2, 2 1, 1 -20, 1 1))'::geometry)) -- returns POLYGON((0 0,0 10,10 10,10 0,0 0))

I can see that the concept of an "envelope" becomes fuzzy for a meaningless polygon, but a downstream effect is that ST_YMin gives a result that is not the minimum y coordinate:

SELECT ST_YMin('POLYGON ((0 0, 10 0, 10 10, 0 10, 0 0), (1 1, 1 2, 2 2, 2 1, 1 -20, 1 1))'::geometry) -- returns 0

I didn't look into how PostGIS is determining an envelope (GEOS?) but the behaviour of PostGIS in this case _is_ consistent with JTS.

(My use case here? Finding all geometries that had coordinates mistakenly altered from 40 to 4, 30 to 3, etc.)

Change History (5)

comment:1 by robe, 10 years ago

Version: 2.1.x1.5.X

comment:2 by robe, 10 years ago

Behaves the same in 1.5. Whether we want to bother fixing for 1.5 is another issue.

I think our ST_Envelope is native and not from GEOS. In fact casting to Box2d yields the same.

SELECT 'POLYGON ((0 0, 10 0, 10 10, 0 10, 0 0), (1 1, 1 2, 2 2, 2 1, 1 -20, 1 1))'::geometry::box2d 

-- outputs 
BOX(0 0,10 10)

Didn't even think we cared about validity as far as box determination is concerned.

comment:3 by robe, 10 years ago

Milestone: PostGIS 2.1.4

comment:4 by robe, 10 years ago

Priority: highlow

Then again I can see why this answer is right and shouldn't be changed. In theory interior rings should never be considered part of the geometry. They are a means to carve a hole in a geometry to say is it not part of the geometry.

So if you carve a hole bigger than the geometry that hole you carved is still not part of the geometry whether or not the geometry is valid. We are simply overstating space that is not part of the geometry.

So I'm tempted to say this is not a bug and certainly not a high priority if we judge it as such.

I'll leave this open for others to judge but tempted to just mark it as won't fix.

comment:5 by robe, 10 years ago

Resolution: invalid
Status: newclosed

Talked with others. The current behavior is right. Interior rings are holes and therefore NEVER considered part of the geometry. So marking this request as invalid.

Note: See TracTickets for help on using tickets.