[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgis-users
Subject:    Re: [postgis-users] is ST_ConvexHull supposed to work like this?
From:       Frans Knibbe <frans.knibbe () geodan ! nl>
Date:       2017-03-15 16:44:00
Message-ID: CAFVDz40Pv2pMWERmJqEK5tPNKxsYbE2eE=qr=BUSm09nj2mvPg () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Martijn's interpretation of the way it works could be correct. In that
case, the documentation is misleading because the computed convex hull
certainly does not enclose all geometries in the set.

By the way, the output of the test when point (2 2 1) is included is
interesting: the resulting polygon does not lie in a single plane. The
polygon is considered valid (ST_IsValid returns true) and it can be
serialised as WKT, X3D and GML. I really wonder if that does not go against
a standard here or there. Interestingly enough, ST_Area gives a wrong area
of 2 for the resulting polygon and ST_3DArea throws an error: "ERROR:
Polygon is invalid : points don't lie in the same plane".

Regards,
Frans


On 15 March 2017 at 12:17, Martijn Meijers <b.m.meijers@tudelft.nl> wrote:

> Does 'supports 3d' not mean in this context in the documentation: the
> function does not forget about each z coordinate of the input in the end
> result, but does not take it into account inside the calculation/analysis?
>
> It seems to me that the convex hull resulting is around the x-y
> coordinates, but for the extreme points the z-coordinate will be present in
> the result (so convex hull while looking from above ;-)
>
> select st_astext(st_convexhull(st_geomfromtext(
> 'MULTIPOINTZ(
> 0 0 0
> ,1 0 0
> ,1 1 0
> ,0 1 0
> ,0 1 1
> ,2 2 1
> ,1 0 1
> ,0 0 1
> )'
> )));
>
>
>                   st_astext
> ---------------------------------------------
>  POLYGON Z ((0 0 0,0 1 0,2 2 1,1 0 0,0 0 0))
>
> The z=1 for point 2,2,1 is preserved however...
>
>
> Martijn
>
>
> On 15-03-17 12:09, Frans Knibbe wrote:
>
>> Hello,
>>
>> I am looking for a way to describe a 3D feature that has only partial
>> geometric coverage with a contiguous geometry. It seemed to me that
>> ST_ConvexHull could be helpful there. But the results are not as expected.
>> So I tried a simple test query to get the convex hull of the eight corners
>> of a cube. The expected result would be a geometry describing the faces of
>> the cube but instead I get only the bottom face:
>>
>> _query:_
>>
>> select st_astext(st_convexhull(st_geomfromtext(
>> 'MULTIPOINTZ(
>> 0 0 0
>> ,1 0 0
>> ,1 1 0
>> ,0 1 0
>> ,0 1 1
>> ,1 1 1
>> ,1 0 1
>> ,0 0 1
>> )'
>> )));
>>
>> _result:_
>> _
>> _
>> POLYGON Z ((0 0 0,0 1 0,1 1 0,1 0 0,0 0 0))
>>
>> This is with PostGIS 2.2.1.
>>
>> The current description of ST_ConvexHull reads "The convex hull of a
>> geometry represents the minimum convex geometry that encloses all
>> geometries within the set". It also says "This function supports 3d". The
>> test result seems to contradict those statements.
>>
>> So is ST_ConvexHull operating as expected? If it is, could there be
>> another way to get the desired result in PostGIS?
>>
>> Regards,
>> Frans
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-users
>>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-users

[Attachment #5 (text/html)]

<div dir="ltr"><div>Martijn&#39;s interpretation of the way it works could be \
correct. In that case, the documentation is misleading because the computed convex \
hull certainly does not enclose all geometries in the set.  \
<br></div><div><br></div><div>By the way, the output of the test when point (2 2 1) \
is included is interesting: the resulting polygon does not lie in a single plane. The \
polygon is considered valid (ST_IsValid returns true) and it can be serialised as \
WKT, X3D and GML. I really wonder if that does not go against a standard here or \
there. Interestingly enough, ST_Area gives a wrong area of 2 for the resulting \
polygon and ST_3DArea throws an error: &quot;ERROR: Polygon is invalid : points \
don&#39;t lie in the same plane&quot;.  \
</div><div><br></div><div>Regards,</div><div>Frans</div><div><br></div><div \
class="gmail_extra"><br><div class="gmail_quote">On 15 March 2017 at 12:17, Martijn \
Meijers <span dir="ltr">&lt;<a href="mailto:b.m.meijers@tudelft.nl" \
target="_blank">b.m.meijers@tudelft.nl</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Does &#39;supports 3d&#39; not mean in this context in the \
documentation: the function does not forget about each z coordinate of the input in \
the end result, but does not take it into account inside the \
calculation/analysis?<br> <br>
It seems to me that the convex hull resulting is around the x-y coordinates, but for \
the extreme points the z-coordinate will be present in the result (so convex hull \
while looking from above ;-)<span class=""><br> <br>
select st_astext(st_convexhull(st_geo<wbr>mfromtext(<br>
&#39;MULTIPOINTZ(<br>
0 0 0<br>
,1 0 0<br>
,1 1 0<br>
,0 1 0<br>
,0 1 1<br></span>
,2 2 1<span class=""><br>
,1 0 1<br>
,0 0 1<br>
)&#39;<br>
)));<br>
<br>
<br></span>
                           st_astext<br>
------------------------------<wbr>---------------<br>
  POLYGON Z ((0 0 0,0 1 0,2 2 1,1 0 0,0 0 0))<br>
<br>
The z=1 for point 2,2,1 is preserved however...<br>
<br>
<br>
Martijn<span class=""><br>
<br>
<br>
On 15-03-17 12:09, Frans Knibbe wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class=""> Hello,<br>
<br>
I am looking for a way to describe a 3D feature that has only partial geometric \
coverage with a contiguous geometry. It seemed to me that ST_ConvexHull could be \
helpful there. But the results are not as expected. So I tried a simple test query to \
get the convex hull of the eight corners of a cube. The expected result would be a \
geometry describing the faces of the cube but instead I get only the bottom face:<br> \
<br></span> _query:_<span class=""><br>
<br>
select st_astext(st_convexhull(st_geo<wbr>mfromtext(<br>
&#39;MULTIPOINTZ(<br>
0 0 0<br>
,1 0 0<br>
,1 1 0<br>
,0 1 0<br>
,0 1 1<br>
,1 1 1<br>
,1 0 1<br>
,0 0 1<br>
)&#39;<br>
)));<br>
<br></span>
_result:_<br>
_<br>
_<span class=""><br>
POLYGON Z ((0 0 0,0 1 0,1 1 0,1 0 0,0 0 0))<br>
<br>
This is with PostGIS 2.2.1.<br>
<br>
The current description of ST_ConvexHull reads &quot;The convex hull of a geometry \
represents the minimum convex geometry that encloses all geometries within the \
set&quot;. It also says &quot;This function supports 3d&quot;. The test result seems \
to contradict those statements.<br> <br>
So is ST_ConvexHull operating as expected? If it is, could there be another way to \
get the desired result in PostGIS?<br> <br>
Regards,<br>
Frans<br>
<br>
<br></span>
______________________________<wbr>_________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" \
target="_blank">postgis-users@lists.osgeo.org</a><br> <a \
href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" \
target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/postgis-users</a><br> \
</blockquote> <br>
______________________________<wbr>_________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" \
target="_blank">postgis-users@lists.osgeo.org</a><br> <a \
href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" \
target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/postgis-users</a></blockquote></div><br></div></div>



[Attachment #6 (text/plain)]

_______________________________________________
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