Boost logo

Geometry :

Subject: Re: [geometry] unexpected results from Boost.Geometry expand()
From: Brook Milligan (brook_at_[hidden])
Date: 2018-06-28 14:29:37


> On Jun 28, 2018, at 3:08 AM, Vissarion Fisikopoulos <fisikop_at_[hidden]> wrote:
>
> On 27 June 2018 at 18:53, Brook Milligan via Geometry
> <geometry_at_[hidden]> wrote:
>> I am testing my understanding of the Boost.Geometry expand() function but am getting unexpected results.
>>
>> The program below produces the following output:
>>
>> ((0, 0), (5, 5))
>> ((0, 0), (5, 5))
>> ((-180, 0), (180, 5))
>> ((-3.14159, 0), (3.14159, 5))
>>
>> The first line basically recreates the documented example. The second does the same with using double as the coordinate type.
>>
>> The third and fourth lines are unexpected. The only difference between the second and third/fourth is the change of coordinate system from cartesian to geographic. Why should the x coordinate be expanded to the entire possible range, instead of the expected [0,5]?
>>
>> I would greatly appreciate any input that will help me understand what is occurring.
>
> The problem is in the initialization of the box, if you initialize it
> with your first point,
> e.g. box_type box = boost::geometry::make<box_type>(0,0,0,0);
> then the results are as expected.

Yes, I guess there is a work-around. Thanks for that.

However, the whole point of the make_inverse function that it creates a box that will have the correct behavior in exactly this use case. See https://www.boost.org/doc/libs/1_67_0/libs/geometry/doc/html/geometry/reference/algorithms/make/make_inverse.html which says "The make_inverse function initializes a 2D or 3D box with large coordinates, the min corner is very large, the max corner is very small. This is useful e.g. in combination with the expand function, to determine the bounding box of a series of geometries." If that cannot be relied upon, then there are other issues.

Something needs fixing. I am not sure if it is with expand() or with make_inverse(), but the combination is clearly not correct for some non-cartesian coordinate systems, even though that is the documented canonical use of the two functions together.

Cheers,
Brook


Geometry list run by mateusz at loskot.net