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

Subject: Re: [boost] [Review] GGL review starts today, November 5th
From: Pierre Morcello (pmorcell-cppfrance_at_[hidden])
Date: 2009-11-22 08:51:25

Hello Barend,

Here are my answers and remarks :

//=== about homogenous coordinates
>>>>Indeed, points with infinite coordinates (in polygons or any other geometry) are not supported right now.[...]Defining a way to allow users to say whether a point coordinate is infinite. That can be done with a function in a traits class, that the user will have to specialize and define. Some of them will decide to have the information as a separate boolean in their coordinate type, others will decide to rely on a special value, etc... it's really up to the user.

I realize I was not very clear. I was referring to 'homogeneous coordinates'. As consequence I suppose it to be more a : ggl::cs::homogeneous. Homogeneous coordinates exists in 1D,3D, ... 100D etc... It's like a cartesian system + an inverse scaling factor for the previous coordinates. So homogeneous point at (1, 1, 1, 4) is in cartesian system at (0.25, 0.25, 0.25). There are very helpfull in projective geometry (application : shadow maps in rt3D, 3D reconstruction, motion capture, tracking, imaging...). I thought this was quite used in GIS too ?
Anyway, from ggl documentation I read : "Many algorithms such as distance or transform use coordinate systems to select the strategy to use. " This is also described in the strategy rationnale. So there it should be highly possible to 'discards' incompatibles algorithms through strategy + a cs::homogeneous. You can consider it as an alternative proposition to the one you made of an'infinity function' (which could work too). In that case, ggl seems perfectly adequate to support homogeneous coordinates. What do you think of the approach a coordinate system?

//=== about intersection documentation
>> Pierre wrote :
>> from ggl intersection module documentation:
>> "intersection: calculate new geometry containing geometries A and B"
>> I think this definition is dangerous : looks too much like union.
> Barend wrote :
>A and B is the commonly accepted definition. We extended the documentation recently at >the start of our review, as there were more questions on backgrounds, you can look at >the page
>http://geometrylibrary.geodan.nl/formal_review/sets.html
>explaining intersections and unions in more detail.

Yes I had read this pages, but this title is still not really convincing. If I tell you "I got a geometry containing a sphere and two cubes" what is the image that comes to your mind : the set intersection of all three or the sum (union) of them? For me it's the union. Maybe you could write " new geometry containing what is common to A and B "? Or you might use the 'AND'('inversed U') symbol from the set theory. That could make it much more clearer that you are reffering to set theory. What do you think?

//=== about intersection design (not set theory, but traditionnal intersection)

Pierre wrote:
>> For example, if I want to calculate a line-line intersection, I have to provide a template parameter for the output type that seems to me completely unknown when I am requesting the calculation :
>> line-line can be : nothing / a point / a line. So will we need to create a new function intersection (geometric_intersection<>), or does the template specialization of intersection_inserter allow to already write it correctly?

Barend wrote:   
>>Yes, specifying the output parameter means specifying the behaviour. If you've an output iterator of points, it will deliver zero or more points. If you want lines, you get lines. Please not that line-line is not yet supported.

I am not completely convinced by this approach. I will explain first why, and then make a little proposition.

Let's take an example. 
Example A : "I have a line and a plane. I wonder : does the line touch the plane, and if it does what is the nature of the intersection, and what is the value of the intersection?". If I can only 'expect' a return type, I might have to make 2 query (one with a line as output, and another time with a point as output). From my point of view, such approach looks wrong, because it is not performant, and present the problem from a narrower point of view than what is required by the mathematical problem.

There is a solution to that situation, that is to use for example a boost::variant as return type. This would allow the user to get both calculation results, and also result type. One of the difficulties in that case is to determine exactly what are the appropriate variations of the return type, from a mathematical point of view. 

On the other end, it is true that in every applications, people will most of the time care only for one type of intersection (let's say 'point result' for a plane-line intersection). But in that case, I would consider it as a "special case", not really the default behavior. I think a variant (or some custom struct) as an "exact result" would be appropriated in most cases.

It seems to me this is possible to do (I don't say it's easy). Can you confirm this is possible? Do you think of some drawbacks of such variant return ?

//=== About description of the library
Pierre wrote :
>>> 1/it might be interesting to restrain the library goal to it's current usage (let's say templated GIS library), in order to wider it after a while and some extensions? 2/ if not, it looks to me mandatory to make very clear the current state (not complete about geometry, good for GIS, but also waiting for extension on subjects : rt3D, etc). This would allow the 'hypothetical future user' not to be depressed by not finding what he is looking for in a generic geometry library, but also give a clear plan what is the development strategy of the library and its 'versionning' goal.   

Barend wrote:
>We see your points. The current usage is (I think) somewhat broader than GIS, though it is heavily influenced by it. For example, polygon clipping is implemented as polygon/polygon and polygon/box, and you see that in many domains, in GIS but also in gaming.
>As is on the example on the main page, small pieces of the library can help in GUI applications (such as Qt).

Yes, this is already in the introduction :
"The GGL might be used in all domains where geometry plays a role: mapping and GIS, gaming, computer graphics and widgets, robotics, astronomy... The core is designed to be as generic as possible and support those domains. However, for now the development has been mostly GIS-oriented."
But in that case, you need to provide some roadmap / todo list (done / not done) / priorities for the developments : current features and future features. Some kind of 'future versionning' for example would be appreciated.

Best regards,

Pierre