Opened 6 months ago

Closed 6 months ago

#5070 closed defect (invalid)

TWKB: last point of the linearing hole of a polygon is lost when xyprecision < 0

Reported by: Aurélien Mino Owned by: pramsey
Priority: medium Milestone: PostGIS 3.3.0
Component: postgis Version: 2.5.x
Keywords: Cc:

Description

Might be related to https://trac.osgeo.org/postgis/ticket/4461

"POLYGON((0 0,0 10,10 10,0 0),(1 1,1 2,2 2,2 1,1 1))" becomes "POLYGON((0 0,0 0,0 0,0 0),(0 0,0 0,0 0,0 0))" (note the missing 5th point of the hole of the polygon) when you apply ST_AsTWKB then ST_GeomFromTWKB.

It works as expected in version 2.5.2, and the defects is present in 2.5.5, 3.0.3, 3.1.4 and 3.2.0.

It can be reproduced with:

select 
	inputwkt,
	ST_AsText(ST_GeomFromTWKB(ST_AsTWKB(inputwkt::geometry, xyprecision, 5, 5, false, false))) as reverted_wkt_from_twkb,
	xyprecision
from (select 'POLYGON((0 0,0 10,10 10,0 0),(1 1,1 2,2 2,2 1,1 1))'::text as inputwkt) xx
cross join generate_series(0, 7) as xyprecision

Change History (4)

comment:1 by Aurélien Mino, 6 months ago

Summary: TWKB: last point of the linearing hole of a polygon is lost when xyprecision > 0TWKB: last point of the linearing hole of a polygon is lost when xyprecision < 0

Provided sql query above has a mistake: generate_series(0, 7) should be generate_series(-7, 0) :

select 
	inputwkt,
	ST_AsText(ST_GeomFromTWKB(ST_AsTWKB(inputwkt::geometry, xyprecision, 5, 5, false, false))) as reverted_wkt_from_twkb,
	xyprecision
from (select 'POLYGON((0 0,0 10,10 10,0 0),(1 1,1 2,2 2,2 1,1 1))'::text as inputwkt) xx
cross join generate_series(-7, 0) as xyprecision

comment:2 by nicklas, 6 months ago

That the point disapears comes from the optimization of removing identical points. From the discussion in the github thread, do you agree this is correct?

But I do not remember why we don't remove the hole when all the points are the same. I might recall we had some discussion about it, but I am not sure. The alternative would be to:

"If we don't have at least 3 different points in a hola after reducing precision we remove the hole".

What talks against that solution is that it would put an overhead for all holes. I see ST_Makevalid can do that job as a postprocessing. I guess that is what we thought.

comment:3 by Aurélien Mino, 6 months ago

Yes, I now agree that this is the expected behavior: the original number of points is not encoded and can't be retrieved, and there's no point in keeping duplicated consecutive coordinates.

Ticket can be closed ;-)

comment:4 by pramsey, 6 months ago

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