
Geometry : 
Subject: [ggl] small design change wrt distance strategy
From: barend (barend.gehrels)
Date: 20100627 10:27:11
hi list,
A month ago I announced a designchange 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 streamoperator
was necessary to enable std::cout << geometry::distance(...)
 for integer coordinates the result can be double; this was possible; but
pointline distance using integer coordinates, intermediary results should
be stored in FP, so another pointtype, which could not be handled with the
specified strategy.
 not only distances of pointpairs are compared but sometimes also a
distance of a pointpair 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
distancestrategy. 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 strategyinstance 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 pointpairs 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 metafunction), sometimes with the apply method
because doing things. All these should be specialized per distancestrategy.
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 integerpoints to FPpoints
6) there is a new metafunction 'get_similar' defining an instance of that
similarstrategy in its method 'apply' (also copying member variables such
as earthradius)
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 distancestrategies.
Question though:
 distancestrategies 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 metafunctions, it sounds
logical to define also return_type as a separate metafunction and not
within the strategyclass (or in addition to the one within the
strategyclass). The distance function would then be changed (
http://codepad.org/syTxJpVj ) which results in actually longer code, but
more consistent (and flexible). For pointtypes this was important
(legacypointtypes), 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
Geometry list run by mateusz at loskot.net