
Boost : 
Subject: [boost] [geometry] [impl] Concepts
From: Barend Gehrels (barend_at_[hidden])
Date: 20090313 11:11:39
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 metafunctions they can also share
tag dispatching.
Then take for example the "selected" algorithm. It uses the
"topological_dimension" (TD) metafunction, 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 metafunction 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, multipoint, multilinestring, multipolygon, 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 pointlinestring and linestringpoint 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 multigeometries (multipoint for e.g. a fleet,
multilinestring for e.g. a highway, multipolygon 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 metafunction
"is_multi", returning false for normal geometries, true for
multigeometries, and we can (partly) specialize on them. There will
then only two (one for singlemulti, one for multimulti) 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 multiones are not
yet implemented, they are skipped until all concepts are clear.)
So these are all really different cases, distinguishing on linearity,
multiness, 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 "metafunction finetuning"...
Regards, Barend
https://svn.boost.org/svn/boost/sandbox/ggl
<https://svn.boost.org/svn/boost/sandbox/ggl/>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk