Re: [boost] [Review] GGL review starts today, November 5th

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
>
> RGB RGB RGB 
>
> or as separate arrays
>
> RRR GGG BBB
>
> 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 
name

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