<html><body><div><div><span>Ok, so, It seems that it works differently depending of the input geometries. With two linestrings it works. </span></div><br><pre style="max-height:264px;margin:8px 0;padding:8px;background-color:#F5F5F5;border-radius:4px;font-weight:500;overflow:auto">SELECT st_intersection('LINESTRINGZ(0 0 5, 10 10 5)'::geometry, 'LINESTRINGZ(0 10 0, 10 0 0)'::geometry);

POINT Z(5 5 2.5)</pre><div><span>The 2 lines intersect in 2D, but not in 3D. Hence, the resulting point has the correct X and Y and the Z is an average of both lines on that point. And probably that was what I remember:</span></div><br><div><span>So I wonder why the different results if I use points. Even in a easier case:</span></div><br><pre style="max-height:264px;margin:8px 0;padding:8px;background-color:#F5F5F5;border-radius:4px;font-weight:500;overflow:auto">SELECT st_intersection('POINTZ(0 0 0)'::geometry, 'POINTZ(0 0 10)'::geometry);

POINT Z(0 0 0)</pre><br><pre style="max-height:264px;margin:8px 0;padding:8px;background-color:#F5F5F5;border-radius:4px;font-weight:500;overflow:auto">SELECT st_intersection('POINTZ(0 0 10)'::geometry, 'POINTZ(0 0 0)'::geometry);

POINT Z(0 0 10)</pre><br><div><span>Meanwhile, it seems that, it the two linestrings intersection have share a vertice in 2D, the average is also not calculated and the first geometry Z values prevails.</span></div><br><pre style="max-height:264px;margin:8px 0;padding:8px;background-color:#F5F5F5;border-radius:4px;font-weight:500;overflow:auto">SELECT st_intersection('LINESTRINGZ(0 0 5, 5 5 5, 10 10 5)'::geometry, 'LINESTRINGZ(0 10 0, 5 5 0, 10 0 0)'::geometry)

POINT Z(5 5 5)</pre><br><div><span>Alexandre Neto</span></div></div><br><div><div>On Fri Apr 28, 2023, 03:54 AM GMT, <a href="mailto:mwtoews@gmail.com">Mike Taves</a> wrote:<br></div><blockquote style="margin:0 0 0 4pt;padding-left:4pt;border-left:1px solid #CCC"><div style="color:#212121;font-size:14px;font-weight:normal;line-height:20px">On Fri, 28 Apr 2023 at 08:54, Regina Obe <lr@pcorp.us> wrote:<blockquote>When you say – it used to return ‘POINT Z(0 0 2.5)’  which version of GEOS and PostGIS were you running?</blockquote><br>I also see this with an older version:<br>POSTGIS="2.4.0 r15853" PGSQL="96" GEOS="3.5.0-CAPI-1.9.0 r4084"<br>PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.11.4, released<br>2016/01/25" LIBXML="2.9.1" LIBJSON="0.11" RASTER<br><br>But the expected answer really is not certain, since they don't intersect in 3D.<br><br>Another answer, using linear interpolation via ST_LineInterpolatePoint:<br><br>db=> SELECT ST_LineLocatePoint(A, B),<br>ST_AsText(ST_LineInterpolatePoint(A, ST_LineLocatePoint(A, B)))<br>db-> FROM (<br>db(>   SELECT 'LINESTRINGZ ( 0 0 5, 0 2 5)'::geometry A, 'POINTZ(0 0<br>0)'::geometry B<br>db(> ) d;<br>-[ RECORD 1 ]------+----------------<br>st_linelocatepoint | 0<br>st_astext          | POINT Z (0 0 5)<br><br>So the expected Z value is either 0 for the input point, 5 for the<br>input line, or 2.5 for "mid-way".<br>_______________________________________________<br>postgis-users mailing list<br>postgis-users@lists.osgeo.org<br>https://lists.osgeo.org/mailman/listinfo/postgis-users<br></div></blockquote></div></body></html>