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
>* 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