Context Navigation

← Previous Ticket
Next Ticket →

#5605 closed defect (fixed)

regress/core/regress_buffer_params failed with latest geos e4a6e1af65f7d60fa63d7666f6cb000

Reported by:	ImreSamu	Owned by:	pramsey
Priority:	medium	Milestone:	PostGIS 3.3.5
Component:	postgis	Version:	3.4.x
Keywords:	geos, regress, regress_buffer_params	Cc:	ImreSamu

Description (last modified by ImreSamu)

With the last Geos changes the regress_buffer_params failing;

regress/core/regress_buffer_params .. failed (diff expected obtained: /tmp/pgis_reg/test_51_diff)

IMHO: the root cause is this GEOS commit:

ARG PGIS1_GEOS_CHECKOUT_SHA1=e4a6e1af65f7d60fa63d7666f6cb000e365bb50f

https://github.com/libgeos/geos/commit/e4a6e1af65f7d60fa63d7666f6cb000e365bb50f

With this GEOS commit, it is OK:

ARG PGIS1_GEOS_CHECKOUT_SHA1=bb2db233eb2d51ba1f44cfaaf5dbd39f0cb1af87

context ( first detection )

updating the new(development) '16-master-bookworm'
CI: https://github.com/ImreSamu/docker-postgis/actions/runs/6803399664/job/18498652762
original commit, first detection: https://github.com/ImreSamu/docker-postgis/commit/32eeb6f20e999857fbc806834c28fd111052a7bd
test Dockerfile: https://github.com/ImreSamu/docker-postgis/blob/32eeb6f/16-master/bookworm/Dockerfile

Change History (11)

comment:1 by ImreSamu, 12 months ago

Description:	modified (diff)

comment:2 by robe, 12 months ago

Similar failure on debbie, berrie, and berrie64

18:03:56  regress/core/regress_buffer_params .. failed (diff expected obtained: /var/lib/jenkins/workspace/postgis/tmp/3_5_pg15w64/test_51_diff)
18:03:56 -----------------------------------------------------------------------------
18:03:56 --- ./regress/core/regress_buffer_params_expected	2023-09-12 16:48:00.430733987 +0000
18:03:56 +++ /var/lib/jenkins/workspace/postgis/tmp/3_5_pg15w64/test_51_out	2023-11-09 23:03:56.664214090 +0000
18:03:56 @@ -1,5 +1,5 @@
18:03:56  point quadsegs=2|POLYGON((1 0,0.7071 -0.7071,0 -1,-0.7071 -0.7071,-1 0,-0.7071 0.7071,0 1,0.7071 0.7071,1 0))
18:03:56 -line quadsegs=2|POLYGON((10 2,11.414 1.414,12 0,11.414 -1.414,10 -2,0 -2,-1.414 -1.414,-2 2.449e-16,-1.414 1.414,0 2,10 2))
18:03:56 +line quadsegs=2|POLYGON((10 2,11.414 1.414,12 0,11.414 -1.414,10 -2,0 -2,-1.414 -1.414,-2 0,-1.414 1.414,0 2,10 2))
18:03:56  line quadsegs=2 endcap=flat|POLYGON((10 2,10 -2,0 -2,0 2,10 2))
18:03:56  line quadsegs=2 endcap=butt|POLYGON((10 2,10 -2,0 -2,0 2,10 2))
18:03:56  line quadsegs=2 endcap=square|POLYGON((10 2,12 2,12 -2,0 -2,-2 -2,-2 2,10 2))
18:03:56 -----------------------------------------------------------------------------

Though the difference seems to be fairly harmless a 0 vs. a 2.449e-16. Maybe we should just change this test

follow-up: 4 comment:3 by mdavis, 12 months ago

Yes, change the test. This is due to an improvement in buffer vertex generation to avoid tiny numbers near zero.

Version 0, edited 12 months ago by mdavis (next)

in reply to: 3 ; follow-up: 6 comment:4 by robe, 12 months ago

Replying to mdavis:

Yes, change the test. This is due to an improvement in buffer vertex generation to avoid tiny numbers near zero.

Can you simply add a small tolerance to check vertex equality?

vertex equality? Wouldn't that make it still fail. Was going to round and normalize

comment:5 by robe, 12 months ago

Doing this now, looks like others on this test have been snapped or normalized in the past. I'm tempted to do that for all of them on this test to future proof this.