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 * coordinate_type * coordinate_count
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<>() accesses ?
Some headers that use .x and .y: area.hpp strategies_point_xy.hpp centroid.hpp correct.hpp envelope.hpp intersection_linestring.hpp intersection_segment.hpp
Bruno, 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 intentionally. I agree that the "point concept" should be made more clear and will work on that. Barend