Confusing results from ST_3DDistance

[strk]

If we adopt the semantic of "missing dimensions are filling" (#3045) then ST_3DDistance(3d,2d) should always compute the 2d distance, rather than arbitrarily set the Z value of the 2d operand to 0.

See ​http://lists.osgeo.org/pipermail/postgis-devel/2015-February/024775.html

[strk]

See also #2034

[strk]

actually, as the &&& semantic changed in 2.1(6), so should ST_3DDistance too ?

[pramsey]

OK, so *both* the arguments must have Z to get a 3D distance, otherwise a 2D distance is returned

[pramsey]

trunk at r13358, 2.1 at r13357

[strk]

sfcgal tests are failing:

--- sfcgal/measures_expected	2015-01-21 14:11:41.220795343 +0100
+++ /tmp/pgis_reg/test_1_out	2015-03-20 15:32:27.583928175 +0100
@@ -31,10 +31,13 @@
 distancepoly6|0|32.5269119345812|LINESTRING(2 2,2 2)|LINESTRING(2 2,2 2)|LINESTRING(2 2,25 25)|LINESTRING(25 25,2 2)
 3dDistancetest1|6.40312423743285|6.40312423743285|f|f|LINESTRING(1 1 1,3 2 7)|POINT(1 1 1)|LINESTRING(1 1 1,3 2 7)
 3dDistancetest2|0|1.73205080756888|t|t|LINESTRING(1 1 1,1 1 1)|POINT(1 1 1)|LINESTRING(1 1 1,0 0 0)
-3dDistancetest3|4.09994192757944|6.48074069840786|t|f|LINESTRING(1 1 1,0.61904761904762 -0.19047619047619 4.90476190476191)|POINT(1 1 1)|LINESTRING(1 1 1,5 2 6)
-3dDistancetest4|2|10.0498756211209|t|f|LINESTRING(1 1 3,1 1 1)|POINT(1 1 3)|LINESTRING(5 7 8,1 1 1)
-3dDistancetest5|2|10|t|f|LINESTRING(5 0 5,5 2 5)|POINT(5 0 5)|LINESTRING(11 0 5,5 0 13)
-3dDistancetest6|0
+3dDistancetest3|0.894427190999916|6.48074069840786|t|f|LINESTRING(1 1 1,0.61904761904762 -0.19047619047619 4.90476190476191)|POINT(1 1 1)|LINESTRING(1 1 1,5 2 6)
+3dDistancetest4|0|10.0498756211209|t|f|LINESTRING(1 1 3,1 1 1)|POINT(1 1 3)|LINESTRING(5 7 8,1 1 1)
+3dDistancetest5|0|10|t|f|LINESTRING(5 0 5,5 2 5)|POINT(5 0 5)|LINESTRING(11 0 5,5 0 13)
+NOTICE:  During distance(A,B) :
+NOTICE:    with A: LINESTRING(1/1 1/1 1/1,2/1 2/1 2/1)
+NOTICE:     and B: POLYGON((0/1 0/1 0/1,2/1 2/1 2/1,3/1 3/1 0/1,0/1 0/1 0/1))
+ERROR:  Polygon is invalid : ring 0 self intersects : POLYGON((0/1 0/1,2/1 2/1,3/1 3/1,0/1 0/1))
 emptyPolyArea|0
 emptyLineArea|0
 emptyPointArea|0
--- sfcgal/tickets_expected	2015-03-06 09:55:39.138987646 +0100
+++ /tmp/pgis_reg/test_9_out	2015-03-20 15:33:31.992180051 +0100
@@ -233,7 +233,7 @@
 #2048|2|t|t
 #2048|3|f|f
 #2112a|0|LINESTRING(2.5 2.5 1,2.5 2.5 1)
-#2112b|1|LINESTRING(1 1 1,1 0 1)
+#2112b|0|LINESTRING(1 1 1,1 0 1)
 #2108|SRID=3395;POINTM EMPTY
 #2117|SRID=3395;POINTM EMPTY
 #2110.1|f

[pramsey]

Reverted trunk and 2.1, handing this to @colivier, since figuring out why such a small change caused problems in unrelated tests is for experts.

[strk]

For the record, the fix was reverted with r13371 in 2.1 branch (2.1.6 was released w/out, milestone of this should be moved to 2.1.7, still to be created at time of writing) and r13376 in trunk.