Hi, This still waited an answer.
When you say refinements seem not applicable, do you mean refinements in general, or just in the case of rectangle/polygon? I have been curious about how you might implement refinement in your tag dispatching based API as I understand it, and I couldn't come up with an answer. If refinement used/supported by your API, or do you think it is not needed except for Const/non Const? I'm curious to hear you elaborate on that.
One (the main?) of the related topics here (on concept refinements) was to limit the number of implementations and combinations. As I've mentioned earlier, we try to limit the geometries such that they are as orthogonal as possible. However, some geometries of course have some common properties. A linestring is, like a linear_ring, a sequence of points. Simple calculations, such as the number of points of them, can share their implementations. With help of a few meta-functions they can also share tag dispatching. Then take for example the "selected" algorithm. It uses the "topological_dimension" (TD) meta-function, which is 0 for points, 1 for lines (or segment), 2 for polygons (and in general everything with an area). The "selected" algorithm specializes on this TD meta-function and everywhere where it is 2 it uses "within". Then for example: calculate distance between two geometries. TD does not make sense here. We will have in the end the ortogonal geometries point, linestring, polygon, multi-point, multi-linestring, multi-polygon, that is 6. Plus the supporting ones segment,box,linear_ring. 6 geometries make already 36 combinations. We now also implemented the reverse tag dispatchings, so point-linestring and linestring-point are implemented as one tag dispatching struct. Bruno implemented this, it uses a Reversable boolean template parameter. So this saves 15 combations, 21 left. (This reversability is applicable to all tag dispatching constructs taking two geometries.) As soon as we have multi-geometries (multi-point for e.g. a fleet, multi-linestring for e.g. a highway, multi-polygon for e.g. France and Corsica), and we want to calculate the distance between them, the process is always the same. They are all vectors (containers), walk through the vectors, check the distance between the entries, if it is shorter than any other memorize that one, etc, straightforward. So the implementation can be the same for all of them (of course using spatial index/sections or similar to do it fast). So we add a meta-function "is_multi", returning false for normal geometries, true for multi-geometries, and we can (partly) specialize on them. There will then only two (one for single-multi, one for multi-multi) dispatch structs handling them all. This saves another 12 combinations. So 9 left, which can be overseen easily (and probably there are more combinations which can be harmonized). (Note that all multi-ones are not yet implemented, they are skipped until all concepts are clear.) So these are all really different cases, distinguishing on linearity, multi-ness, topological dimension. This is not concept refinement, or it would be a complex system of tags multiple inherited by other ones. We limit our dispatch cases in a finetuned way, so no "concept refinement" but "meta-function finetuning"... Regards, Barend https://svn.boost.org/svn/boost/sandbox/ggl <https://svn.boost.org/svn/boost/sandbox/ggl/>