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 [hidden email] https://lists.osgeo.org/mailman/listinfo/postgis-users |
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 > [hidden email] > https://lists.osgeo.org/mailman/listinfo/postgis-users _______________________________________________ postgis-users mailing list [hidden email] https://lists.osgeo.org/mailman/listinfo/postgis-users |
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 <[hidden email]> 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? _______________________________________________ postgis-users mailing list [hidden email] https://lists.osgeo.org/mailman/listinfo/postgis-users |
Free forum by Nabble | Edit this page |