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

Subject: [ggl] A few Boost.Geometry questions
From: Bill Zissimopoulos (ggl)
Date: 2010-09-21 16:10:25

Luke wrote:
> Your data structure has a certain runtime polymorphic flavor with a little run time type identification mixed in.  Since boost.geometry uses static polymorphism and compile time type indentification you would need to declare a different type for each multipoint, linestring and polygons and copy the size and pointer to array of points into these.  There is no way around declaring these different types at compile time since the c-style array with associated size doesn't satisfy the concept and the GeoemtryPath struct can only be registered to satisfy one of the several concepts it can mutate into at runtime.

I figured as much and have defined compile-time types so that Boost.Geometry can properly act on them. For example:
        struct _GeometryPath : GeometryPath
        {
            typedef GeoKit::impl::Point *iterator;
            typedef const GeoKit::impl::Point *const_iterator;
            iterator begin()
            {
                return points;
            }
            iterator end()
            {
                return points + npoints;
            }
            const_iterator begin() const
            {
                return points;
            }
            const_iterator end() const
            {
                return points + npoints;
            }
        };
        struct _GeometryLinestring : _GeometryPath
        {
        };
        struct _GeometryRing : _GeometryPath
        {
        };

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?

Thank you for your time.

Bill