[prev in list] [next in list] [prev in thread] [next in thread]
List: postgis-users
Subject: Re: [postgis-users] st_intersection of 3D objects
From: Alexandre Neto <senhor.neto () gmail ! com>
Date: 2023-04-28 14:26:26
Message-ID: 9fbb37cf-35c4-4e2b-9efb-1740fbd58770 () mail ! shortwave ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Ok, so, It seems that it works differently depending of the input geometries. With \
two linestrings it works.
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) 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:
So I wonder why the different results if I use points. Even in a easier case:
SELECT st_intersection('POINTZ(0 0 0)'::geometry, 'POINTZ(0 0 10)'::geometry); POINT \
Z(0 0 0) SELECT st_intersection('POINTZ(0 0 10)'::geometry, 'POINTZ(0 0 \
0)'::geometry); POINT Z(0 0 10) 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.
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) Alexandre Neto
On Fri Apr 28, 2023, 03:54 AM GMT, Mike Taves <mailto:mwtoews@gmail.com> wrote:
> On Fri, 28 Apr 2023 at 08:54, Regina Obe <lr@pcorp.us> wrote:
> > When you say – it used to return ‘POINT Z(0 0 2.5)' which version of GEOS and \
> > PostGIS were you running?
>
> I also see this with an older version:
> POSTGIS="2.4.0 r15853" PGSQL="96" GEOS="3.5.0-CAPI-1.9.0 r4084"
> PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.11.4, released
> 2016/01/25" LIBXML="2.9.1" LIBJSON="0.11" RASTER
>
> But the expected answer really is not certain, since they don't intersect in 3D.
>
> Another answer, using linear interpolation via ST_LineInterpolatePoint:
>
> db=> SELECT ST_LineLocatePoint(A, B),
> ST_AsText(ST_LineInterpolatePoint(A, ST_LineLocatePoint(A, B)))
> db-> FROM (
> db(> SELECT 'LINESTRINGZ ( 0 0 5, 0 2 5)'::geometry A, 'POINTZ(0 0
> 0)'::geometry B
> db(> ) d;
> -[ RECORD 1 ]------+----------------
> st_linelocatepoint | 0
> st_astext | POINT Z (0 0 5)
>
> So the expected Z value is either 0 for the input point, 5 for the
> input line, or 2.5 for "mid-way".
> _______________________________________________
> postgis-users mailing list
> postgis-users@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-users
[Attachment #5 (text/html)]
<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>
_______________________________________________
postgis-users mailing list
postgis-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic