[prev in list] [next in list] [prev in thread] [next in thread] 

List:       solr-dev
Subject:    [jira] [Commented] (LUCENE-8669) LatLonShape WITHIN queries fail with Multiple search Polygons that 
From:       "ASF subversion and git services (JIRA)" <jira () apache ! org>
Date:       2019-01-31 23:02:00
Message-ID: JIRA.13212884.1548874821000.216227.1548975720214 () Atlassian ! JIRA
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/LUCENE-8669?page=com.atlassian.jira.plugin \
.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757786#comment-16757786 ] 

ASF subversion and git services commented on LUCENE-8669:
---------------------------------------------------------

Commit be471ea91d53ae9b362f223e4fafecc612b4d309 in lucene-solr's branch \
refs/heads/branch_7_7 from Nicholas Knize [ \
https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=be471ea ]

LUCENE-8669: Fix LatLonShape WITHIN queries that fail with Multiple search Polygons \
that share the dateline.


> LatLonShape WITHIN queries fail with Multiple search Polygons that share the \
>                 dateline
> -------------------------------------------------------------------------------------
>  
> Key: LUCENE-8669
> URL: https://issues.apache.org/jira/browse/LUCENE-8669
> Project: Lucene - Core
> Issue Type: Bug
> Affects Versions: 8.0, 7.7
> Reporter: Nicholas Knize
> Assignee: Nicholas Knize
> Priority: Blocker
> Attachments: LUCENE-8669.patch
> 
> 
> {{LatLonShape.newPolygonQuery}} does not support dateline crossing polygons. It is \
> therefore up to the calling application / user to split dateline crossing polygons \
> into a {{MultiPolygon}} query with two search polygons that share the dateline. \
> This, however, does not produce expected results because \
> {{EdgeTree.internalComponentRelateTriangle}} does not differentiate between a \
> triangle that {{CROSSES}} or is {{WITHIN}} the target polygon. Therefore \
> {{MultiPolygon}} {{WITHIN}} queries that share the dateline behave as an \
> {{INTERSECT}} and will therefore produce incorrect results. Consider the following \
> test, for example: {code:java}
> // index
> // western poly
> Polygon indexPoly1 = new Polygon(
> new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
> new double[] {-180d, -180d, -176d, -176d, -180d}
> );
> // eastern poly
> Polygon indexPoly2 = new Polygon(
> new double[] {15d, -7.5d, -15d, -10d, 15d, 15d},
> new double[] {180d, 180d, 176d, 174d, 176d, 180d}
> );
> //// index ////
> Field[] fields = LatLonShape.createIndexableFields("test", indexPoly1);
> for (Field f : fields) {
> doc.add(f);
> }
> fields = LatLonShape.createIndexableFields("test", indexPoly2);
> for (Field f : fields) {
> doc.add(f);
> }
> writer.addDocument(doc);
> ///// search //////
> Polygon[] searchPoly = new Polygon[] {
> new Polygon(new double[] {-20d, 20d, 20d, -20d, -20d},
> new double[] {-180d, -180d, -170d, -170d, -180d}),
> new Polygon(new double[] {20d, -20d, -20d, 20d, 20d},
> new double[] {180d, 180d, 170d, 170d, 180d})
> };
> Query q = LatLonShape.newPolygonQuery("test", QueryRelation.WITHIN, searchPoly);
> assertEquals(1, searcher.count(q));
> {code}
> 
> In the example above, a dateline spanning polygon is indexed as a {{MultiPolygon}} \
> with two polygons that share the dateline. Similarly, a polygon that spans the \
> dateline is provided as  two polygons that share the dateline in a {{WITHIN}} \
> query. The indexed polygon should be returned as a match; but it does not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]