Hi Rutger,
The whole library is designed like this and I think it is good and generic. You're now able to use all functions in template environments, where you don't know if you're handling a point or a line. If you write distance_pt_to_poly, you have to know the context...
I guess I have been referring to this overloading, too. IIRC, a different distance will be returned for points at the exact same location but in different coordinate systems? For example, I guess I would prefer
great_circle_distance( a, b );
over a strategy-based overload of distance() returning the same, as long as the strategy is defined by a coordinate system (and not by a space or a metric).
This is indeed how it is implemented, "distance" everywhere. You can call "distance" for two points in a lat-long coordinate system and get back this great circle distance. Calling it for cartesian and you get back pythagorean distance. So I understand you prefer to have it *not* the same. Sorry, I didn't understand this point from your previous posting. It works everywhere like this, you can call area and you get the area (in meters) which makes more sense than the area in square degrees. If you *don't* want that behaviour, you can override it with a strategy... Or force points to be in a different coordinate system than they really are... Regards, Barend