Geometry Boost List: Re: [geometry] 3D box -> 3D multi_polygon conversion

Subject: Re: [geometry] 3D box -> 3D multi_polygon conversion
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-06-11 16:12:33

Barend Gehrels wrote:
>
> Note that converting a box to e.g. a ring is not that simple. A 3D box
> has two z-coordinates, which cannot be just converted into a ring with
> height, you will loose one coordinate. Unless you define a ring with two
> z-coordinates (ground and height), which is basically possible, but that
> will make the conversion less generic.
>
> What is basically implemented for 3D is, out of my head:
> - the concepts are dimension-agnostic, so for example get/set
> - some dimension-agnostic algorithms (of course) as num_points,
> num_geometries, reverse, unique, for_each
> - distance (3D points or actually N-D points)
> - centroid (idem) for point collections
> - derived from distance: length (3d segments or linestrings, or n-d) /
> perimeter
> - derived from distance: simplify
> - conversion to WKT/DSV
> - some in details are basically N-D but never tested as such, or will
> only work with (probably minor) fixes, such as sectionalize
>
> What we need is a polyhedron, and then operations on it, which will be a
> major work on itself.
>
> Bruno has certainly more ideas about this.
>

Correct me if I'm wrong but shouldn't ring, polygon, multipolygon, etc. 
be always flat? It may be 3D, may have even some orientation and 
position in 3D space, not only height, but should be flat. This way we 
can perform some 2D operations on it by e.g. first projecting it into 
the 2D plane. E.g. we can calculate convex hull (also flat) or 
triangulate. I'm not so sure if using MultiPolygon concept to describe 
3D mesh is a good idea. I'd rather provide additional concept.

Regards,
Adam