Geometry Boost List: [ggl] RE: A few Boost.Geometry questions

Subject: [ggl] RE: A few Boost.Geometry questions
From: Bruno Lalande (bruno.lalande)
Date: 2010-09-26 06:02:41

Hi all,

> An important work item for a user of Boost.Geometry is to build a good
> mental model of the library and its concepts, so that proper decisions can
> be made on how to adapt one's own concepts to those of
> Boost.Geometry.?Centralizing the requirements and listing them per algorithm
> will help a lot in this regard.

Making a library which is built upon such advanced technique usable by
average users is indeed the major challenge for this documentation. So
your feedback is very valuable, and your suggestions make sense.

> I feel that the "per algorithm" requirement is quite important. For example,
> if you only want area(), which Boost.range should you implement? The
> documentation states that "it must behave like a Boost.Range", but it does
> not specify which one. Only trial and error can show.

Yep that was my point in my previous mail, we need to specify which
specific refinement of each concept is used for each algorithm.

> BTW, when I tried to implement union() it appeared that some of the required
> expressions went beyond those of Boost.Range and push_back(), clear() that
> are stated in the documentation. As I have not looked into this in the last
> couple of days I cannot reliably report on the error messages, but will do
> so as soon as I can.

OK, please give a few examples (not necessarily with the error
messages) just to see if we forgot to mention a concept or if we
really missed a requirement.

> Clearly I do not understand Boost.Geometry enough to know whether this would
> work or not. However I see two potential issues:
> 1. Consider a clipping operation of a multipoint with "hidden" z-values
> against a polygon. If intersection() constructs the new clipped multipoint
> by carefully *copying* unclipped points from the input into the output, this
> could work. If intersection() however constructs *new* output points using
> the coordinates from the old input point, it will not work.

Interesting, and tricky indeed... We need to think about how this
could be solved, for the time being I unfortunately don't have any
definitive solution to propose. I feel that the key would be to
improve the way in which user expresses how he wants points to be
constructed, maybe with new functions/metafunctions, but I need to
elaborate that further.

I'm mostly interested in game programming, and this situation occurs
quite often in this area as well (although it mostly appears at
rasterization time, which developers often delegate to the hardware).
So you're problem is a bit mine, actually :-)

> 2. GeometryPath's actually hold the z-values in a separate array:
> struct?GeometryPath
>
> {
>
> ?? ?char?tag;
>
> ?? ?size_t?npoints;
>
> ?? ?Point?*points; // has x,y (but not z) information
>
> ?? ?Float?*zvalues;
> };
> This is because most of our geometries are 2-dimensional, but there is the
> occasional geometry that requires 3-dimensional information (e.g. a list of
> depth soundings). This saves space and allows for tighter packing of Point's
> in the on-disk databases.

Not sure what your question is here. If it's how to adapt that to the
3P point concept in the library in order to perform 3D operations, you
will need to adapt your point by defining metafunctions directly
rather than relying on the macros you used so far. Basically those
macros are there to make it easy to adapt the most straight-forward
situations (when all the coordinates are accessed in the same, obvious
way). They define a set of metafunctions for you that say the library
how to use your point.

When it comes to adapt something less obvious, you have to do by
yourself what those macros usually do. You can see an example of such
an adaptation here:

http://geometrylibrary.geodan.nl/c05__custom__point__pointer__example_8cpp-example.html

Althought the situation is not exactly the same, it basically shows
you all the operations needed to explain the library how your point
should be used. Basically, you have to do all what you can see before
the main() function in that example. So, to summarize:
- specializing the tag class template for your point - this basically
says the library that your type is a point, by associating the tag
point_tag to it (if you were adapting a polygon, you'd say polygon_tag
instead, etc)
- specializing the coordinate_type class template for your point, to
specify the type of coordinates it uses
- specializing the coordinate_system class template for your point, to
specify which coordinate system (cartesian, spherical, etc...) you
want it to be associated to
- specializing the dimension class template for your point, to specify
how many coordinates it has
- specializing the access class template for each coordinate of your
point to explain the library how to access them, both for read and
write

Please tell me if this helps you to do what you want.

Regards
Bruno