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

Subject: Re: [geometry] 3D box -> 3D multi_polygon conversion
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2013-06-16 18:09:53

Hi,

What I said (
http://boost-geometry.203548.n3.nabble.com/vtk-output-beta-ready-for-polygon-ring-and-multi-polygon-td4025296.html)
might have been a bit simplified here so I'd like to clarify.

In short : there's not one polyhedron concept, there are many of them.

The reason I said Tomislav could start with a multi_polygon is because it
is indeed one of those many valid ways to represent a polyhedron, though
not the most interesting in many situations. It's better known as "polygon
soup". Basically, one can represent a polyhedron as:
- a polygon soup
- a graph
- the representation proposed by OGC
- and much more....

And a graph has itself many possible representations. That's why
Boost.Graph doesn't have just one concept but several, described here :
http://www.boost.org/doc/libs/1_53_0/libs/graph/doc/graph_concepts.html.
And when GCAL took those concepts as valid representations for their own
polyhedron models, they still had to add an extra graph concept that
doesn't exist in Boost.Graph. That gives an idea of the versatility of what
we're talking about.

So my point in my correspondence with Tomislav was: the *particular* use
case he was showing was using the notion of polygon soup to represent a
polyhedron. And the MultiPolygon concept is pretty much all you need to
express that. What I didn't make clear enough though, is that I don't want
to directly "steal" MultiPolygon. I expect an actual PolygonSoup concept to
be created, and its documentation will basically say that the requirements
are those of MultiPolygon except that the tag must be polygon_soup.

About the fact that a polygon soup is inefficient when it comes to
retrieving common edges : that's absolutely true. Just like a std::vector
is not good at removals and a std::list is not good at random access,
there's no silver bullet as well for representing a polyhedron. We are not
going to have a Polyhedron concept. We're going to have a PolygonSoup
concept, a VertexAndEdgePolyhedron concept, an IncidencePolydron concept, a
<WhateverBestDescribesOGC'sRepresentation>Polyhedron concept, etc...

That's why I can see nothing wrong with Tomislav starting to work on
PolygonSoup and implementing some algorithms for it. Barend, does that make
sense to you or you were seeing this in a completely different way?

Regards
Bruno