ST_3DDwithin Errors on memcmp with pt_in_ring_3d

[tilt]

The following query:

SELECT 
ST_3DDwithin(ST_GeometryFromText('POLYGON Z ((
238122.872000001 576633.508999999 5.98677038142003,
238122.872 576633.509 5.98677038052055,
238121.623809392 576634.389879555 4.95792405791038,
238120.252000002 576635.357999998 3.82718245716979,
238120.252 576635.358 3.82718245541562,
238121.873 576637.738 3.8333125996467,
238121.873000001 576637.737999999 3.83331260027449,
238124.460390651 576635.62447975 6.0745417745131,
238122.991788134 576633.427399075 6.08439985368325,
238122.872000001 576633.508999999 5.98677038142796))
')
ST_GeometryFromText('POINT Z (238123 576634 0)')
,0.1)

results in:

ERROR:  pt_in_ring_3d: V[n] != V[0] (238123 576634 5.98677!= 238123 576634 5.98677)

Likely this is due to a rounding error and happening in:

https://github.com/postgis/postgis/blob/svn-trunk/liblwgeom/measures3d.c#L1249

The polygon obviously is not a very nice one (with vertices almost on top of each other) but it is valid. I tried the folowing workarounds:

ST_RemoveRepeatedPoints 0.1
ST_SnapToGrid 0.1
manually cleaning the polygon

Only the last option worked so I suspect the problem is in the precision of the Z-value, since the other two only deal with 2D coordinates.

Running on:

POSTGIS="2.5.0rc1dev r16693" [EXTENSION] PGSQL="100" GEOS="3.7.0beta2-CAPI-1.11.0 e7d54545" SFCGAL="1.3.5" PROJ="Rel. 5.1.0, June 1st, 2018" GDAL="GDAL 2.4.0dev-3ea4d4ed14-dirty, released 2018/07/09" LIBXML="2.9.4" LIBJSON="0.12.1" LIBPROTOBUF="1.2.1" (core procs from "2.5.0beta2dev r16638" need upgrade) RASTER (raster procs from "2.5.0beta2dev r16638" need upgrade) (sfcgal procs from "2.5.0beta1dev r16609" need upgrade)

[tilt]

For completeness: in the meantime I also ran the ALTER EXTENSION postgis UPDATE; (to fix the warning in the version message) but the issue remains the same.

[Algunenano]

The first polygon you are using is invalid; the first and last point of the polygon should be the same:

• First: 238122.872000001 576633.508999999 5.98677038142003
• Last: 238122.872000001 576633.508999999 5.98677038142796

The z coordinate is 5.98677038142003 vs 5.98677038142796.

If you change it to the same value it outputs:

SELECT 
ST_3DDwithin(ST_GeometryFromText('POLYGON Z ((
238122.872000001 576633.508999999 5.98677038142003,
238122.872 576633.509 5.98677038052055,
238121.623809392 576634.389879555 4.95792405791038,
238120.252000002 576635.357999998 3.82718245716979,
238120.252 576635.358 3.82718245541562,
238121.873 576637.738 3.8333125996467,
238121.873000001 576637.737999999 3.83331260027449,
238124.460390651 576635.62447975 6.0745417745131,
238122.991788134 576633.427399075 6.08439985368325,
238122.872000001 576633.508999999 5.98677038142003))'),
ST_GeometryFromText('POINT Z (238123 576634 0)')
,0.1)
 st_3ddwithin 
--------------
 f
(1 row)

[tilt]

Ouch, well spotted. I only focused on the x,y coordinates, took me 2 hours And ofcourse the ST_Isvalid doesn't involve the Z. Luckily, the ST_IsClosed function also does the job of checking.

I'm going to dig to the source of this problem, since in theory this one should be closed.