# Geometry :

Subject: Re: [geometry] 3D box -> 3D multi_polygon conversion
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-06-12 17:26:34

Hi Tomislav,

(the policy of Boost lists is to not top-post).

On 12-6-2013 14:28, Tomislav Maric wrote:
> Hi,
>
> I don't think the OGC PolyhedralSurface model will work together with
> a multipolygon concept for a polyhedron (surface mesh), since the
> connectivity between polygons will be severely complicated to compute
> and change during topological operations if the points are repeated
> for each polygon.

Note that it is the Concept which repeat points. The implementation
might be different. I mean: the Concept has methods as NumPatch,
Patch(index), or probably an iterator returning polygons. However, this
can be stored internally as the implementator thinks it is good.

Besides this, I don't understand - if you want to use multipolygons to
store the polyhedron, I always assumed that you wanted to repeat
coordinates...

It is a bit as a collection of polygons, some files (shapefiles) store
all coordinates per polygon, others (ESRI coverages) use topology,
however, retrieving one polygon always returns just that polygon,
regardless how it is stored.

>
> To ensure logical point uniqueness (not involving tolerances to drop
> duplicates), the topology of the surface mesh must be described either
> as a graph, or using indirect addressing like Adam described in his
> previous email/ However, I am 100% certain that ensuring point
> uniqueness with indirect addressing will cause the algorithm
> complexity to literally explode.

I don't exactly understand why the complexity explodes by just using
indirect addressing. It is IMO just a way to access the coordinates. If
the Concept gives certain methods, the implementations (using either
direct or indirect addresses and either unique or duplicated points)
might vary. The algorithms should use the Concept to support different
types of polyhedrons.

>
> I've tried using indrect addressing and subsequently ensuring point
> uniqueness, and that is the reason why I want to switch to a
> multipolygon representation and loose the connection between polygons
> of the surface mesh, for intersecting smaller non-planar polyhedra.
> In the end my goal is to efficiently intersect and compute volume of
> the result between a halfspace and a small polyhedron, two tetrahedral
> decompositions and two polyhedrons. Maybe this is too specific for the
> geometry library.. I don't know.. this is just my experience..

I don't think it is too specific, but we need a generic concept able to
store polyhedrons described either as triangles, or as polygons.

Regards, Barend

Geometry list run by mateusz at loskot.net