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

Subject: [ggl] A few Boost.Geometry questions
From: Simonson, Lucanus J (lucanus.j.simonson)
Date: 2010-09-21 16:23:26

Bill Zissimopoulos wrote:
...
> However I have three issues:
> 	1. Documentation: the documentation is not very clear on what
> methods/etc one needs to define when one's geometries are not based
> on std::vector. Some documentation for example has statements such
> as: "it must behave like a Boost.Range" which is a rather vague
> statement for someone not intimately familiar with Boost.Range. It
> would be much better if the documentation listed the exact
> requirements (e.g. you need these methods with these signatures and
> semantics, etc). Even better if the requirements of individual
> Boost.Geometry algorithms were listed.        
> 	2. Mixed geometries: does Boost.Geometry handle mixed geometries
> 	(e.g. a geometry that contains both line strings and polygons)? My
> understanding is that it does not. This would mean that one has to
> manually break one's geometries into multi-points, multi-linestrings
> and multi-polygons and feed those into the Boost.Geometry algorithms
> individually. [For example, GEOS has a GEOMETRYCOLLECTION geometry
> which solves this problem nicely.]     
> 	3. Z-values: in GIS applications points often carry an additional
> z-value that may represent an altitude or depth value. This value is
> simply attached to the point and is not considered in any geometry
> calculations (except that if the point is clipped, then its z-value
> is also clipped). Does Boost.Geometry have any similar feature?    

I'm not the best person to answer these questions, perhaps some one else can help?

The documentation is currently under development and the semantics of the concepts are themselves changing or recently changed.  I don't know what the current state is.  I doubt there is support for mixed geometry, but you shouldn't need to make copies into new data structures.  You can create a wrapper type that holds a reference to your class and provides the interface required for a given concept.  This is better than inheriting as your code snippet proposes.  I have what I call the view_as() concept cast implemented in Boost.Polygon that allows you to view a data structure of one concept type as a model of an ordinarily incompatible concept.  Such a concept cast is intended to be used when you have runtime evidence that the data stored in the object is compatible with the concept you are casting it to.  Such wrapper classes should be easy to write once the requirements of the concepts you are mapping to are clear to you.  Using the boost.geometry API would then be a two step process of checking your type
 at runtime and then making the appropriate concept cast when passing the object into an interface.

Sorry I can't be of more help.

Luke