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:

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

Regards

Bruno