Subject: [ggl] small design change wrt distance strategy
From: barend (barend.gehrels)
Date: 2010-06-27 10:27:11
hi list,
A month ago I announced a design-change with respect to distance and
'comparable_distance'.
I now worked on that change. I'm satisfied about it because it is more
clear, and also that more things are possible now, and that things are more
logical.
The old design was:
- a strategy returned into a 'return_type' which was (in case of Pythagoras)
a structure ('cartesian_distance' ) convertible to a double
Problems were:
- a 'return type' convertible into something seemed a good idea but was
actually not so good, and hard to get right. For example, a stream-operator
was necessary to enable std::cout << geometry::distance(...)
- for integer coordinates the result can be double; this was possible; but
point-line distance using integer coordinates, intermediary results should
be stored in FP, so another point-type, which could not be handled with the
specified strategy.
- not only distances of point-pairs are compared but sometimes also a
distance of a point-pair with a known distance (e.g. in simplify). This
resulted in a helper structure 'distance_result_maker'
- and there we more small issues and inconveniencies
With those things in mind I changed the design. The structs
'cartesian_distance' and 'distance_result_maker' are gone now.
Design is:
1) if a strategy has a more efficient comparable variant (e.g. pythagoras
with avoided sqrt), that variant should also be implemented as a
distance-strategy. Of course they can share (very much) of their
implementations
2) there is a new metafunction 'comparable_type' defining that variant. If
there is no efficient comparable variant, it of course can define itself
3) there is a new (meta)function 'get_comparable' which, in its method
'apply', returns that variant (or itself). The strategy-instance is an
argument so it can copy member variables (if applicable)
4) there is a new (meta)function 'result_from_distance' which, in its method
'apply', returns a value equal to the distance. So called with pythagoras
and 5, it gives 5. But called with comparable::pythagoras and 5, it gives 25
because all distances of point-pairs being compared to that distance are
squared. This is instead of the old 'distance_result_maker'
So this are all small metafunctions, as we have many more, sometimes
defining things (real meta-function), sometimes with the apply method
because doing things. All these should be specialized per distance-strategy.
For the integer issue also:
5) there is a new metafunction 'similar_type' defining the same strategy but
with other template parameters (other point types). This enables 'promotion'
of a strategy from integer-points to FP-points
6) there is a new metafunction 'get_similar' defining an instance of that
similar-strategy in its method 'apply' (also copying member variables such
as earth-radius)
It is not yet commited and I will probably do so today, but the essentials
are pasted into codepad:
Definitions of metafunctions: http://codepad.org/PPccpYxW
New pythagoras including efficient variant: http://codepad.org/1gg6yMno
Specializations for pythagoras/metafunctions: http://codepad.org/rehcOxYR
And for its comparable variant: http://codepad.org/rQd5oeoV
Sample usage: http://codepad.org/4ZWAhihD
This system will work for Haversine (= spherical distance calculation) as
well and being more efficient (in previous implementation that was not
implemented), and also for other distance-strategies.
Question though:
- distance-strategies are still expected to define some types (return_type,
first_point_type, second_point_type). Of these first/second point type are
never used. In the light of the new design with meta-functions, it sounds
logical to define also return_type as a separate meta-function and not
within the strategy-class (or in addition to the one within the
strategy-class). The distance function would then be changed (
http://codepad.org/syTxJpVj ) which results in actually longer code, but
more consistent (and flexible). For point-types this was important
(legacy-point-types), for strategies it is probably less important (the
change that they happen to define a method apply is low anyway)
Regards, Barend
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20100627/d7202dad/attachment.html