Geometry Boost List: [ggl] small design change wrt distance strategy

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