Sperical / geo coordinates question: crossing anti-meridian
I am trying to determine if boost.geometry handles certain cases of spherical coordinates. Suppose you have county outlines of Alaska. The Aleutian Islands chain crosses the anti-meridian, and so contains latitudes that are in the ranges [ 180 - delta ... 180 ] and [ -180, -180 + delta ] where delta is < 20 degrees or so. Simple (2D planar) point-in-polygon and polygon intersection algorithms fall down on these cases due to anti-meridian crossings and flipping between +/- values. Does Boost geometry deal with these issues "correctly"? I put correctly in quotes because there is some real ambiguity in the coordinate system (maybe the polygon really does wrap around the world?), but one could apply a "minimum perimeter" heuristic and normalize the polygons before performing the computation by moving the [ 180 - delta ... 180 ] range over to [ -180 - delta ... -180 ] or vice-versa. Thanks, john
Hi John, If you mail about Boost.Geometry, please include [geometry] in the subject, or mail to the Boost.Geometry mailing list, otherwise we might miss it (but not always apparently). On 17-2-2013 15:41, John Lilley wrote:
I am trying to determine if boost.geometry handles certain cases of spherical coordinates. Suppose you have county outlines of Alaska. The Aleutian Islands chain crosses the anti-meridian, and so contains latitudes that are in the ranges [ 180 -- delta ... 180 ] and [ -180, -180 + delta ] where delta is < 20 degrees or so.
Simple (2D planar) point-in-polygon and polygon intersection algorithms fall down on these cases due to anti-meridian crossings and flipping between +/- values. Does Boost geometry deal with these issues "correctly"?
Yes. Point in polygon and area do support date crossings. Not all algorithms are yet implemented for spherical (e.g. intersection is not), so it is not yet applicable there, but if so, it should support it. We test with Wrangel which is also crossing the dateline.
I put correctly in quotes because there is some real ambiguity in the coordinate system (maybe the polygon really does wrap around the world?), but one could apply a "minimum perimeter" heuristic and normalize the polygons before performing the computation by moving the [ 180 -- delta ... 180 ] range over to [ -180 -- delta ... -180 ] or vice-versa.
Yes, we assume the range is within 180 degrees. What is NOT yet correctly supported is a polygon spanning the north pole or south pole. Regards, Barend
For operations like intersection, would a stop-gap be to project the coordinates onto a Cartesian space (with say, an assumed origin at the prime meridian)? john From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Barend Gehrels Sent: Sunday, February 17, 2013 10:52 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [geometry] Sperical / geo coordinates question: crossing anti-meridian Hi John, If you mail about Boost.Geometry, please include [geometry] in the subject, or mail to the Boost.Geometry mailing list, otherwise we might miss it (but not always apparently). On 17-2-2013 15:41, John Lilley wrote: I am trying to determine if boost.geometry handles certain cases of spherical coordinates. Suppose you have county outlines of Alaska. The Aleutian Islands chain crosses the anti-meridian, and so contains latitudes that are in the ranges [ 180 - delta ... 180 ] and [ -180, -180 + delta ] where delta is < 20 degrees or so. Simple (2D planar) point-in-polygon and polygon intersection algorithms fall down on these cases due to anti-meridian crossings and flipping between +/- values. Does Boost geometry deal with these issues "correctly"? Yes. Point in polygon and area do support date crossings. Not all algorithms are yet implemented for spherical (e.g. intersection is not), so it is not yet applicable there, but if so, it should support it. We test with Wrangel which is also crossing the dateline. I put correctly in quotes because there is some real ambiguity in the coordinate system (maybe the polygon really does wrap around the world?), but one could apply a "minimum perimeter" heuristic and normalize the polygons before performing the computation by moving the [ 180 - delta ... 180 ] range over to [ -180 - delta ... -180 ] or vice-versa. Yes, we assume the range is within 180 degrees. What is NOT yet correctly supported is a polygon spanning the north pole or south pole. Regards, Barend
participants (2)
-
Barend Gehrels -
John Lilley