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

[murdos]

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

[murdos]

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

[nicklas]

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.

[murdos]

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