Boost logo

Boost :

Subject: Re: [boost] [Review] GGL review starts today, November 5th
From: Barend Gehrels (barend_at_[hidden])
Date: 2009-11-11 17:03:26

Hi Thomas,

Thanks for your pre-review. I try to answer the pieces not yet handled.

I've no problem with Boost.Geometry if it is accepted, and users have
indeed to change some things anyway after acceptance.

> [...] 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>) );
You are right. A list is not supported, it used to be in the past but
now, it is not anymore. We're using Boost.Range now everywhere,
including boost::size, not supported by lists.
So like Mateusz said. We will remove it from the adaption file.

> Now I should try to explain what I mean by a representation. GIL gives the example that the RGB values might be saved interleaved as
> or as separate arrays
> and that both representations might have advantages and disadvantages for different use cases. One of the goals of GIL is to allow writing algorithms that will work on both (and most other sensible) representations.
I think this has some analogy to what GGL does: it works on rings and
polygons having both orientations, clockwise and counter clockwise. Both
occur. The OGC convention is clockwise. We first only supported that.
But in the end the difference is not that large, in implementation.

We call it generic because it should support different point-types,
different line-types, etc, even in one algorithm. We're also agnostic in
coordinate system and number of dimensions. Not that all is supported in
3D, in fact that support is still limited, but it is support is provided
by the kernel.

Finally people can add coordinate systems or even geometries (like
triangle, ellipse), all is dispatched the same way.

But we don't support "everything" indeed. For example, linestrings with
non-linear interpretations between its vertices were discussed, but not
more than that.

> What does "ggl::assign_inverse" and "make_envelope" do? These are apparently OGC names, but I spend quite some time trying to verify that this is indeed the case
About OGC names:
- you are right about that it can be confusing now and that it should be
more clear
- assign and assign inverse are not OGC names; combine is also not an
OGC name
- envelope is the OGC name. But as we also use std:: and boost::
conventions, we decided to let functions returning a geometry being
preceded by make_. So make_envelope, make_centroid. The user has to
specify the type then.
- read_wkt is not the exact OGC name. This has a little history again.
We first had "as_text", the OGC convention. But that was too general, we
also have svg and dsv, and VE-shapes, all is text. So we decided to
deviate here and call the streaming "wkt". Reading wkt is not in the SF
spec (Mateusz gave the link), databases call it "from text", also too
general. So we call input now "read_", output is just streaming with the

I'll come with a clarification of the exact OGC
names/support/deviations. They were there in earlier documentation but
there are many people not interested in GIS or OGC, so we don't want to
pay it too much attention everywhere in the documentation.

Regards, Barend

Boost list run by bdawes at, gregod at, cpdaniel at, john at