From: Barend Gehrels (barend_at_[hidden])
Date: 2008-03-26 17:56:28
Bruno Lalande wrote:
>Indeed, things have to be clear on that point, and I'm a bit confused
>about what really constitutes the concept of a point. What I have
>understood until now is that a class is the point if it exposes:
>* the value<>() getter and setter
>and that besides this, the .x and .y of the point_xy class were just
>some syntactic helpers provided for an easier external use of this
>class. But I see that almost all the algorithms use .x and .y, which
>means that they won't work with the basic concept I just described.
>Shouldn't all those algorithms be implemented in terms of value<>()
>Some headers that use .x and .y:
All right, thanks for examining the sources so closely. The .x and .y
are not meant to be in most of those sources, but as it is a preview,
and not final submission, they are still there.
I didn't introduced strategies for the "side-geometries" box and circle,
until now. Therefore in area, centroid, correct and envelope there are
still .x and .y coordinates. The are only in the box and/or circle
geometries there. I left them more or less untouched after the preview.
This should be solved. As you will see, in point, linestring and polygon
they are gone in the correct / envelope / centroid and area algorithms,
as they are in simplify, length and distance.
I also didn't yet introduce strategies for intersections yet. It is just
a matter of time, available time and effort. I made comments about that
in source and documentation. Will also be solved.
The header strategies_point_xy.hpp uses .x and .y and there it is
I agree that the "point concept" should be made more clear and will work
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk