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

Subject: [ggl] RE: A few Boost.Geometry questions
From: Bill Zissimopoulos (ggl)
Date: 2010-09-24 14:52:58

Bruno wrote:

> 1/ Documentation => you're right, since the requirements of a
> Boost.Range are not likely to change much, it might make sense to
> summarize them within the Boost.Geometry documentation...
> As you can see in the Boost.Range doc (section "Range Concepts")
> adapting a type to the Range concept is not exactly about adding
> methods to it, but more generally making a precise set of expressions
> valid.

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.

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.

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.

> 2/ About multiple geometries => I don't see any mean to handle that
> out-of-the-box (no compile-time equivalent to GEOMETRYCOLLECTION), but
> you should be able to obtain what you want by using Boost.Variant.

I will consider Boost.Variant as a solution. Thanks for pointing this out to me.

> Just one note about inheritence/wrapping... All we want is to get several
> distinct types out of your unique type, in order to transform your
> runtime world into our compile-time world. As such, simple typedefs
> sound entirely sufficient to me:
> 
> typedef GeometryPath MyLineString;
> typedef GeometryPath MyPolygon;

As Luke mentioned in a different email, typedef's simply define an alias for a type and not a new type. Therefore I do not believe that this would work.

> 3/ Z-value => I'm not sure to understand the issue here. What you seem
> to need is adapting a 3D point (which is actually a 2D point with an
> additional coordinate that you don't want to take into account in the
> algorithms you call) to a 2D point. This is possible, you will simply
> be discarding your Z-value when adapting your point...
> 
> BOOST_GEOMETRY_REGISTER_POINT_2D(Point3D, Float, cs::geographic<degree>, x, y)
> 
> The library "believes" that your point is only a 2D points and just
> ignores the rest. But maybe I've misunderstood your need?

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.
        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.
        I do understand that this a peculiarity of our library and there is probably little that Boost.Geometry can do about it. Perhaps the solution is to register two Point types, Point and Point3D, although I do not think that the same Boost.Geometry algorithm can handle geometries with different point types. It is unclear whether creating a relation between Point and Point3D (e.g. by allowing conversion between the two) would be enough to solve the issue.

> Sorry for such long explanations, hope they're not too unclear.

Bruno, I thank you for the time you have taken to answer my questions.

Bill

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20100924/1577ffed/attachment.html