[jira] [Updated] (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:all-tabpanel ] Robert Muir updated LUCENE-7157: Attachment: LUCENE-7157.patch here is a quick patch at the docs: just refining what we have now, which is essentially nothing. > 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 > Attachments: LUCENE-7157.diff, LUCENE-7157.diff, LUCENE-7157.diff, > LUCENE-7157.diff, LUCENE-7157.diff, LUCENE-7157.patch > > > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (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:all-tabpanel ] Karl Wright updated LUCENE-7157: Attachment: LUCENE-7157.diff Here's the latest; not much different from before but iterates over the directional test to be sure its inherent pole choice algorithm is not a factor. > 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 > Attachments: LUCENE-7157.diff, LUCENE-7157.diff, LUCENE-7157.diff, > LUCENE-7157.diff, LUCENE-7157.diff > > > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (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:all-tabpanel ] Karl Wright updated LUCENE-7157: Attachment: LUCENE-7157.diff Everything is now working. [~mikemccand]: This is ready for review. There are a number of improvements here for polygons in general -- namely, faster computation of intersections and bounds, along with ability to handle concave polygons. There is one algorithmic area of concern with how we figure out clockwise/counterclockwise directionality during the construction. This code is problematic because it generates a random pole repeatedly until it finds one that works. It may be possible in future revs to reduce the search area for a good pole, but I doubt the need for randomness will go away ever entirely. > 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 > Attachments: LUCENE-7157.diff, LUCENE-7157.diff, LUCENE-7157.diff, > LUCENE-7157.diff > > > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (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:all-tabpanel ] Karl Wright updated LUCENE-7157: Attachment: LUCENE-7157.diff No more hash-order dependencies, and fix some of the logical errors found so far. > 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 > Attachments: LUCENE-7157.diff, LUCENE-7157.diff, LUCENE-7157.diff > > > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (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:all-tabpanel ] Karl Wright updated LUCENE-7157: Attachment: LUCENE-7157.diff Updated patch. > 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 > Attachments: LUCENE-7157.diff, LUCENE-7157.diff > > > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (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:all-tabpanel ] Karl Wright updated LUCENE-7157: Attachment: LUCENE-7157.diff The attached patch has a significant reworking of polygon construction. It passes basic tests. However, it failed beasting once, which I need to look into, plus there's a disabled test that exercises detection of clockwise/counterclockwise. Attaching mostly so I don't inadvertantly lose stuff, since my git abilities are still limited... > 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 > Attachments: LUCENE-7157.diff > > > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
