Thomas Klimpel wrote:
Mateusz Loskot wrote:
The layout of GGL source tree follows Boost convention. In spite of that, you are right, users will likely have to update their GGL-based source code
What I mean is that a file like cartesian2d.hpp which currently reads more or less [...]
Yes. I've agreed on that exactly, above.
GGL on the other hand provides just one point, linestring, linear_ring, polygon, box and segment class template, because the representation isn't really the challenge in the context of geometry. Not really. GGL proposes some definitions of types for basic fundamental geometries. However, user does not have too stick to them. Moreover, it is expected that users may want to not to touch these (pre-)defined types but define their own types.
Are you sure? Even so I was vaguely aware that you haven't fully understood what I meant by representation, I still took a look at "linestring_concept.hpp" to check whether you enforce a certain representation to the user. Now I'm totally confused, because "geometries/adapted/std_as_linestring.hpp" registers std::line<P> as a linestring, but the following concept requirement for linestring seem to rule out std::list<p>:
BOOST_CONCEPT_ASSERT( (boost::RandomAccessRangeConcept<Geometry>) );
Yes, you are right. Thanks for spotting this issue. There has been changes applied recently that I apparently overlooked. As Barend knows best what's the current status of this, I will let Barend to clarify. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org