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

Subject: Re: [geometry] 3D box -> 3D multi_polygon conversion
From: Tomislav Maric (tomislav.maric_at_[hidden])
Date: 2013-06-11 16:17:50

On 06/11/2013 10:12 PM, Adam Wulkiewicz wrote:
> 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.

IMHO this would be quite expensive. Coordinate transform is a Matrix
Vector multiplication, and it costs for nothing, if its only done to
enable 2D calculation on a 3d object. Another point, consider
incremental convex hull in 3D: computing the visible face is not
possible to do this way (mixed product makex only sense for non
co-planar vectors) simply because the hull construction will lie in 3D
and transforming it to 2D projection will not work. I'm sure the
quickhull algorithm is similar.

Regards,
Tomislav
>
> Regards,
> Adam
> _______________________________________________
> Geometry mailing list
> Geometry_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/geometry