You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Karl Wright (JIRA)" <ji...@apache.org> on 2016/03/31 20:48:25 UTC
[jira] [Commented] (LUCENE-7157) Geo3DPoint implementation should
pay attention to the ordering of lat/lon points
[ https://issues.apache.org/jira/browse/LUCENE-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15220433#comment-15220433 ]
Karl Wright commented on LUCENE-7157:
-------------------------------------
The key observation is that any sequence of polygon points can be viewed from two perspectives. One perspective is from any point on one side of the boundary, and another perspective is from any point on the other side of the boundary. It so happens that your choice of point doesn't matter because from that point you *always* describe the same area based on the ESRI rules; the points appear to go clockwise if the point you chose is inside the area and appear to go counterclockwise if outside the area, from wherever you look at it.
If you consider the point you choose to be a "pole" (through the center of the earth), and you assess the angle delta between the pole and the previous point and the next point as being positive when clockwise from the top of the pole and negative when counterclockwise, then you will get a total angle as you march around the polygon of +360 if the points are clockwise, and -360 if they are not. The only requirement is that the point you choose for a pole is not actually on the edge of the polygon. That turns out to be the hardest thing to reliably insure about this algorithm.
The choice of pole point has to be made so that the point does not lie on a polygon edge. If we pick a random point, we can just proceed until it blows up, and then try a different point. The way it blows up is by either having no calculable angle between the pole and a point, or by computing a delta from the last point that is exactly 180 degrees.
I'm a bit nervous using a completely random pole point but I can't think of any algorithmic way to come up with a known-safe point.
> Geo3DPoint implementation should pay attention to the ordering of lat/lon points
> --------------------------------------------------------------------------------
>
> Key: LUCENE-7157
> URL: https://issues.apache.org/jira/browse/LUCENE-7157
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Karl Wright
>
> The LatLonPoint API implementation pays attention to the order of the points; "clockwise" means one side of the polygon boundary, and "counterclockwise" means the complement. We need to use that in Geo3DPoint and convert into whatever the underlying GeoPolygonFactory method requires.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org