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-20 20:00:43

Bill wrote:
>...
>struct GeometryPath
>{
>    char tag;
>    size_t npoints;
>    Point *points;
>    Float *zvalues;
>};
>GeometryPath.tag can take one of the following values: 
>'P': multi-point
>'3': multi-point w/ associated z-values (e.g. altitudes, depths)
>'L': linestring
>'A': area (exterior polygon ring)
>'H': hole (interior polygon ring)
>... For example, how do I (minimally) translate a pair of arguments
>GeometryPath *p, size_t n
>into a bunch of constructs that Boost can act upon? I think I understand the idea of concepts, but Boost does not seem to have a concept for a >geometry that can simultaneously contain multiple points, multiple line strings and multiple polygons.

std::make_pair<size_t, Point*>(npoints, points);

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.

There is a way around it at link time, however.  You could register your GeometryPath as a different concept in each compilation unit such that in one file it is always treated as a polygon by boost.geometry but in another file it is already treated as a linestring, for example.  You can then build your own interface on top of functions defined in terms of Boost.Geometry, but defined in separate files and brought together only at link time.  Since you already have a legacy interface all you have to do to implement it in terms of Boost.Geometry is factor out usage of Boost.Geometry to a new file for each concept you want GeometryPath to model, include boost geometry in each and register GeometryPath as each concept in each file.

Regards,
Luke