Debbie tickets regress on geography intersects failing on all PostgreSQL branches for postgis 3.0

[robe]

Even after the postgrsql 12 fix, debbie is still failing. But it seems this change is affecting all postgres branches, not just the 12. The 12 install issues were fixed.

The test triggering the difference is

SELECT '#723',
 encode(ST_AsEWKB(ST_SnapToGrid( ST_Intersection(a.geog, b.geog)::geometry, 0.00001),'ndr'),'hex')
FROM (VALUES (ST_GeogFromText('SRID=4326;POINT(-11.1111111 40)') ), (ST_GeogFromText('SRID=4326;POINT(-11.1111111 55)') ) ) As  a(geog) CROSS JOIN ( VALUES (ST_GeogFromText('SRID=4326;POINT(-11.1111111 40)') ), (ST_GeogFromText('SRID=4326;POINT(-11.1111111 55)') )) As b(geog);

Loading PostGIS into 'postgis_reg' 
  /var/lib/jenkins/workspace/postgis/branches/3.0/regress/00-regress-install/share/contrib/postgis/postgis.sql
  /var/lib/jenkins/workspace/postgis/branches/3.0/regress/00-regress-install/share/contrib/postgis/postgis_comments.sql
  /var/lib/jenkins/workspace/postgis/branches/3.0/regress/00-regress-install/share/contrib/postgis/postgis_proc_set_search_path.sql
PostgreSQL 11.1 on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.2.0-9) 8.2.0, 64-bit
  Postgis 3.0.0dev - r17032 - 2018-11-19 01:43:53
  scripts 3.0.0dev r17032
  GEOS: 3.8.0dev-CAPI-1.12.0 70a9773c
  PROJ: Rel. 5.2.0, September 15th, 2018


 tickets .. failed (diff expected obtained: /var/lib/jenkins/workspace/postgis/tmp/3_0_pg12w64/test_95_diff)
-----------------------------------------------------------------------------
--- tickets_expected	2018-11-08 12:15:17.205801173 +0000
+++ /var/lib/jenkins/workspace/postgis/tmp/3_0_pg12w64/test_95_out	2018-11-19 16:33:01.165535816 +0000
@@ -125,8 +125,8 @@
 #696|010f000080060000000103000080010000000500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f03f0000000000000000000000000000f03f000000000000f03f0000000000000000000000000000f03f0000000000000000000000000000000000000000000000000000000000000000010300008001000000050000000000000000000000000000000000000000000000000000000000000000000000000000000000f03f0000000000000000000000000000f03f000000000000f03f0000000000000000000000000000f03f0000000000000000000000000000000000000000000000000000000000000000000000000000000001030000800100000005000000000000000000000000000000000000000000000000000000000000000000f03f00000000000000000000000000000000000000000000f03f0000000000000000000000000000f03f00000000000000000000000000000000000000000000f03f00000000000000000000000000000000000000000000000001030000800100000005000000000000000000f03f000000000000f03f0000000000000000000000000000f03f000000000000f03f000000000000f03f000000000000f03f0000000000000000000000000000f03f000000000000f03f00000000000000000000000000000000000000000000f03f000000000000f03f0000000000000000010300008001000000050000000000000000000000000000000000f03f00000000000000000000000000000000000000000000f03f000000000000f03f000000000000f03f000000000000f03f000000000000f03f000000000000f03f000000000000f03f00000000000000000000000000000000000000000000f03f00000000000000000103000080010000000500000000000000000000000000000000000000000000000000f03f000000000000f03f0000000000000000000000000000f03f000000000000f03f000000000000f03f000000000000f03f0000000000000000000000000000f03f000000000000f03f00000000000000000000000000000000000000000000f03f
 #720|MULTIPOINT(-1113194.91 4838471.4,-1113194.91 7326837.72,-1113194.91 11028513.63,556597.45 4838471.4,556597.45 7326837.72,556597.45 11028513.63,2226389.82 4838471.4,2226389.82 7326837.72,2226389.82 11028513.63,3896182.18 4838471.4,3896182.18 7326837.72,3896182.18 11028513.63,5565974.54 4838471.4,5565974.54 7326837.72,5565974.54 11028513.63)
 #723|0101000020e61000006284f068e33826c00000000000004440
-#723|0107000020e610000000000000
-#723|0107000020e610000000000000
+#723|0101000020e6100000000000000000f87f000000000000f87f
+#723|0101000020e6100000000000000000f87f000000000000f87f
 #723|0101000020e61000006284f068e33826c00100000000804b40
 #804|<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"><gml:pos srsDimension="2">0 0</gml:pos></gml:Point>
 #845|t
-----------------------------------------------------------------------------

I'm not sure how my fix for #4231 or if its just some other chagnes going on.

I haven't patched 2.5 yet with 12 fix, will see if that blows up too when Ido. That one is passing at the moment.

[robe]

I just tested on my 12 head which should be pretty close to what debbie is running with and I get the expected answer

#723	0101000020e61000006284f068e33826c00000000000004440
#723	0107000020e610000000000000
#723	0107000020e610000000000000
#723	0101000020e61000006284f068e33826c00100000000804b40

What on earth could be causing her to give these answers and why isn't it happening on her 2.5 runs.

For reference I am running:

PostgreSQL 12devel on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0, 64-bit POSTGIS="3.0.0dev r17031" [EXTENSION] PGSQL="120" GEOS="3.7.0-CAPI-1.11.0 673b9939" PROJ="Rel. 5.2.0, September 15th, 2018" GDAL="GDAL 2.3.1, released 2018/06/22" LIBXML="2.7.8" LIBPROTOBUF="1.2.1" (core procs from "3.0.0dev r17022" need upgrade) RASTER (raster procs from "3.0.0dev r17029" need upgrade)

[Algunenano]

I'm seeing this too.

It appears to be related to GEOS:

• geos-git-3.7.0rc1.r61.g23c6c3ec-1-x86_64.pkg.tar (from a week ago) is "fine".
• geos-git-3.7.0rc1.r76.g81ff4c03 (from today's master) has the different output.

I'm going to try to bisect it.

[Algunenano]

Commit responsible: ​https://github.com/libgeos/geos/commit/6ef28f282e6a336302267b249fcac6cc59c54cae

Summoning @pramsey

If the commit itself in Geos is correct we'd need to change the test to output St_AsText instead of the binary form.

[robe]

Alguenano thanks for ironing that out. That explains it. I forgot debbie follows head of geos too. I think @pramsey is in Aussie perhaps dancing with the kangaroos.

[robe]

Until the GEOS issue is fixed, I've changed the version of GEOS debbie is using to 3.7 branch instead of 3.8 head

[pramsey]

Yes, the change is "correct", at least it is unless we plan to peg GEOS to the old behaviour and not track the JTS newer more "explicit" empty behaviour. I prefer the latter since it matches up to our own more explicit empty handling since 2.0.

[pramsey]

In 17078:

Change test conditions to look for empty.
References #4245

[pramsey]

In 17079:

Change test conditions to explicit empty test
References #4245

[pramsey]

In 17080:

Change test conditions to explicit empty test
References #4245

[pramsey]

In 17081:

Change test condition to isempty
Closes #4245