Hi, Sean Farrow wrote:

Hi,

Ok, take a windows RECT structure:

typedefstruct_RECT {

LONG left;

LONG top;

LONG right;

LONG bottom;

} RECT, *PRECT;

The remarks then state:

By convention, the right and bottom edges of the rectangle are normally considered exclusive. In other words, the pixel whose coordinates are ( right, bottom ) lies immediately outside of the rectangle. For example, when RECT is passed to the FillRect function, the rectangle is filled up to, but not including, the right column and bottom row of pixels.

How can I gain the same behaviour when doing equals, overlaps etc.?

Any help appreciated.

Cheers

Sean.

*From:*Boost-users [mailto:boost-users-bounces@lists.boost.org] *On Behalf Of *Barend Gehrels *Sent:* 26 January 2014 21:49 *To:* boost-users@lists.boost.org *Subject:* Re: [Boost-users] making a geometry half closed

Hi Sean,

Sean Farrow wrote On 26-1-2014 14:44:

Hi,

From what I understand any boost geometry is fully closed. Is there a way of making a geometry half closed, such that the bottom row is not included?

I'm needing to do this with a Box2D$Values.

Any help appreciated.

No, this is not really implemented. Which problem do you have in mind? For example a "touch" relationship where two geometries touch each other, would this differ if they touch the upper row instead of the lower row?

The within-algorithm (for point-in-box) considers a point within if it is completely inside. That can be finetuned by supplying a strategy which considers bottom-row / right row.

The coordinates aren't floating points. Maybe using right-1 for and bottom-1 for could work? It probably depends on the use case. Just a quick thought. Coordinates are increasing top-down right? E.g. polygons marked as CW in Boost.Geometry would appear as CCW on your screen. Regards, Adam

Hi, Mateusz Łoskot wrote On 27-1-2014 10:40:

On 26 January 2014 23:00, Adam Wulkiewicz wrote:

...

The coordinates aren't floating points. Maybe using right-1 for and bottom-1 for could work? It probably depends on the use case. I also think offsetting right and bottom segments would do the trick, as long as the coordinates are discrete.

Yes, it is a good idea to consider but it really depends on the use-case, indeed. For example: calculating the area would then go quite wrong. And calculating the perimeter would go a bit wrong. But within might succeed. We follow OGC's model for all geometries, so there is an interior, there is a boundary and there is an exterior. Points can be placed "on boundary" or inside or outside. A segment-crossing goes via the boundary. If there is at one side no boundary, the underlying assumptions fail. So that's why I wrote: "it's not implemented". But you can try to do things of course, it will compile. Regards, Barend

On Sun, Jan 26, 2014 at 6:05 PM, Barend Gehrels wrote:

Sean Farrow wrote On 26-1-2014 22:57:

Ok, take a windows RECT structure: ...

By convention, the right and bottom edges of the rectangle are normally considered exclusive. In other words, the pixel whose coordinates are ( right, bottom ) lies immediately outside of the rectangle. For example, when RECT is passed to the FillRect function, the rectangle is filled up to, but not including, the right column and bottom row of pixels.

How can I gain the same behaviour when doing equals, overlaps etc.?

As said it is not implemented like this.

Does adapting RECT for Geometry involve copying values? Could one write an adapter specific to RECT which would subtract 1 from the original right and bottom?