[ https://issues.apache.org/jira/browse/LUCENE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16818019#comment-16818019 ]
Nicholas Knize edited comment on LUCENE-8736 at 4/15/19 2:43 PM: ----------------------------------------------------------------- {quote}it would be good to have an example where the determinant overflows as I haven't been able to exercise such an error. {quote} I'll see if I can grab an example. As expected, it doesn't occur when computing on encoded integer space; only decoded 64 bit double space. {quote}I guess I don't see them as boundary failures. {quote} The issue I have is the behavior of excluding boundary points does not follow [OGC specifications;|http://portal.opengeospatial.org/files/?artifact_id=25355] (pg 37, "touches" relationship) which is the standard that geo systems _should_ follow; and the standard I think we should follow. {quote}this patch really really hurts points {quote} Looking at the benchmarks I don't know that it _really_ _really_ hurts points. For me it's most important the behavior is correct. Then we can look at ways to improve performance? In this instance I think following the OGC community definition is probably best for defining "correct" behavior. was (Author: nknize): {quote}it would be good to have an example where the determinant overflows as I haven't been able to exercise such an error. {quote} I'll see if I can grab an example. As expected, it doesn't occur when computing on encoded integer space; only decoded 64 bit double space. {quote}I guess I don't see them as boundary failures. {quote} The issue I have is the behavior of excluding boundary points does not follow [OGC specifications;|http://portal.opengeospatial.org/files/?artifact_id=25355] which is the standard that geo systems _should_ follow; and the standard I think we should follow. {quote}this patch really really hurts points {quote} Looking at the benchmarks I don't know that it _really_ _really_ hurts points. For me it's most important the behavior is correct. Then we can look at ways to improve performance? In this instance I think following the OGC community definition is probably best for defining "correct" behavior. > 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