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

Robert Muir commented on LUCENE-8736:
-------------------------------------

{quote}
The concern I have is the behavior of excluding boundary points does not follow 
OGC specifications; (pg 37, "touches" relationship) which is the standard that 
geo systems should follow; and the standard I think we should follow.
{quote}

I don't agree with that: that document is about shapes, I am talking about 
points. Again, I think it makes sense for point-in-polygon to follow the simple 
formula that everyone has used for decades. It is easy to explain that way. 

Its also easy to explain that a single point (e.g. lat/lon coordinate) can only 
be in at most 1 country, rather than trying to explain how its in two. Same 
goes with county or state or anything else. So the partitioning and other 
properties are important, for points.

This JIRA issue was supposedly about polygons, but it did a real drive-by on 
points. Now they are no longer possible to reason about, tests are failing in 
jenkins, etc. I really think the points should just go back. 

Its fine if shapes behave differently, whatever makes sense for them.

> LatLonShapePolygonQuery returning incorrect WITHIN results with shared 
> boundaries
> ---------------------------------------------------------------------------------
>
>                 Key: LUCENE-8736
>                 URL: https://issues.apache.org/jira/browse/LUCENE-8736
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Nicholas Knize
>            Assignee: Nicholas Knize
>            Priority: Major
>             Fix For: 8.1, master (9.0)
>
>         Attachments: LUCENE-8736.patch, LUCENE-8736.patch, 
> adaptive-decoding.patch
>
>
> Triangles that are {{WITHIN}} a target polygon query that also share a 
> boundary with the polygon are incorrectly reported as {{CROSSES}} instead of 
> {{INSIDE}}. This leads to incorrect {{WITHIN}} query results  as demonstrated 
> in the following test:
> {code:java}
>   public void testWithinFailure() throws Exception {
>     Directory dir = newDirectory();
>     RandomIndexWriter w = new RandomIndexWriter(random(), dir);
>     // test polygons:
>     Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new 
> double[] {3d, 4d, 4d, 3d, 3d});
>     Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new 
> double[] {6d, 7d, 7d, 6d, 6d});
>     Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new 
> double[] {3d, 4d, 4d, 3d, 3d});
>     Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new 
> double[] {0d, 1d, 1d, 0d, 0d});
>     // index polygons:
>     Document doc;
>     addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
>     w.addDocument(doc);
>     addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
>     w.addDocument(doc);
>     addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
>     w.addDocument(doc);
>     addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
>     w.addDocument(doc);
>     ///// search //////
>     IndexReader reader = w.getReader();
>     w.close();
>     IndexSearcher searcher = newSearcher(reader);
>     Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d, 
> 0d, 0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
>     Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN, 
> searchPoly);
>     assertEquals(4, searcher.count(q));
>     IOUtils.close(w, reader, dir);
>   }
> {code}



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

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

Reply via email to