Re: [boost] [GGL] Initial thoughts; how to register point types

Subject: Re: [boost] [GGL] Initial thoughts; how to register point types
From: Barend Gehrels (barend_at_[hidden])
Date: 2009-11-14 14:14:33

Hi Phil,

Thanks for your interest in our library, now and in the past.

>
> The documentation seems very much focused on "how it works", which is 
> of course useful for reviewing the design, but more "what it does" and 
> "how to use it" content would help me to actually try it with some 
> examples.  

There were more remarks about the documentation, its structure and its 
content, and we hope to enhance this in the near future. If our library 
is accepted we might migrate to Boost Books because it seems that most 
libraries do have that format.

> For example, I have a Point<T> class and I would like to "teach" the 
> library about it.  From the "Design rationale" page I can see that a 
> number of traits have to be defined, but I don't see a concise 
> reference to what I need to do.  Looking at the example 
> "c01_custom_point_example.cpp" I see that there are some macros e.g. 
> GEOMETRY_REGISTER_POINT_2D (not a Boost-style macro name by the way) 
> but I don't see any documentation for what these do.  I guess that it 
> defines some traits specialisations, right?
Right. The custom examples now all make use of the macro's but I think 
for teaching purposes we could have left one traits class. However, 
there is one left in the tests,
file libs\ggl\test\test_common\test_point.hpp , so that might give you 
more background.

>
> Does anyone know how to get Doxygen to create next/prev buttons for 
> navigating between the pages in the e.g. "related pages" section?
>
> Is it possible to note which versions of the Boost library 
> dependencies are needed?

That is somewhere there on the page "Relation to Boost and std 
libraries". Or probably you don't mean that, it all runs fine using 
Boost 1.40.0. Does this answer your question?

>
> I'm not convinced that overloading e.g. distance() so that it works 
> with all combinations of geometries is a good idea.  If I wanted to 
> know the distance from a point to a polygon I'd be happy to write 
> distance_pt_to_poly(a,b).  

The whole library is designed like this and I think it is good and 
generic. You're now able to use all functions in template environments, 
where you don't know if you're handling a point or a line. If you write 
distance_pt_to_poly, you have to know the context...

> Having the overload makes it possible for me to accidentally pass the 
> wrong things and get no error.  And there is the question of what is 
> meant by distance "to" a polygon - is it to the nearest point, or the 
> centroid, etc?
Sure, that is a good question. We'll mean the OGC distance because it is 
an OGC function. To be more clear, this is the distance to the border. 
There were earlier questions about this, because sometimes you even want 
to know the distance from a point inside a polygon to the border. I 
believe it was you who asked that once. This is currently an open point 
(it is not defined by OGC, but we can deviate sometimes - even give a 
negative value back would be possible).

>
> I believe that heterogeneous co-ordinate types (e.g. latitude and 
> longitude of one type and altitude of another) are not supported, right?
No, if you write that in this way, it is not supported. You can define a 
point (lat, long) with altitude as an attribute. Then it is your choice, 
so it is possible then. But if you make a 3D point using lat long 
coordinates, and it makes sense of course, then the altitude should be 
the same coordinate type as lat and long...

Regards, Barend