[
https://issues.apache.org/jira/browse/LUCENE-8396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16564672#comment-16564672
]
Steve Rowe commented on LUCENE-8396:
------------------------------------
Test failure, from
[https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/726/]:
{noformat}
Checking out Revision a9f129190f9065c8775a628df181fb53248db488
(refs/remotes/origin/branch_7x)
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestLatLonShapeQueries -Dtests.method=testRandomTiny
-Dtests.seed=1BAECFBE374F07D6 -Dtests.slow=true -Dtests.locale=en-PN
-Dtests.timezone=America/Edmonton -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] FAILURE 0.03s J1 | TestLatLonShapeQueries.testRandomTiny <<<
[junit4] > Throwable #1: java.lang.AssertionError: wrong hit (first of
possibly more):
[junit4] > FAIL: id=11 should not match but did
[junit4] > query=LatLonShapeBoundingBoxQuery:
field=shape:Rectangle(lat=-52.35433959402144 TO 58.83083060849458
lon=-79.63909948244691 TO 179.99999991618097) docID=11
[junit4] > polygon=[-4.190951585769653E-8, -152.01172342523932]
[89.99999995809048, -152.01172342523932] [89.99999995809048,
-49.80329998768866] [-4.190951585769653E-8, -152.01172342523932]
[junit4] > deleted?=false rect=Rectangle(-52.35433959402144 TO
58.83083060849458 lon=-79.63909948244691 TO 179.99999991618097)
[junit4] > at
__randomizedtesting.SeedInfo.seed([1BAECFBE374F07D6:52E911F8696E3F7A]:0)
[junit4] > at
org.apache.lucene.document.TestLatLonShapeQueries.verifyRandomBBoxes(TestLatLonShapeQueries.java:262)
[junit4] > at
org.apache.lucene.document.TestLatLonShapeQueries.verify(TestLatLonShapeQueries.java:133)
[junit4] > at
org.apache.lucene.document.TestLatLonShapeQueries.doTestRandom(TestLatLonShapeQueries.java:129)
[junit4] > at
org.apache.lucene.document.TestLatLonShapeQueries.testRandomTiny(TestLatLonShapeQueries.java:97)
[junit4] > at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4] > at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit4] > at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4] > at
java.base/java.lang.reflect.Method.invoke(Method.java:564)
[junit4] > at java.base/java.lang.Thread.run(Thread.java:844)
[...]
[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70),
sim=RandomSimilarity(queryNorm=true): {}, locale=en-PN,
timezone=America/Edmonton
{noformat}
> Add Points Based Shape Indexing
> -------------------------------
>
> Key: LUCENE-8396
> URL: https://issues.apache.org/jira/browse/LUCENE-8396
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Nicholas Knize
> Priority: Major
> Attachments: LUCENE-8396.patch, LUCENE-8396.patch, polyWHole.png,
> tessellatedPoly.png
>
>
> I've been tinkering with this for a while and would like to solicit some
> feedback. I'd like to introduce a new shape field based on the BKD/Points
> codec to bring much of the Points based performance improvements to the shape
> indexing and search usecase. Much like the existing shape indexing in
> {{spatial-extras}} the shape will be decomposed into smaller parts, but
> instead of decomposing into quad cells (which have the drawback of precision
> accuracy and sheer volume of terms) I'd like to explore decomposing the
> shapes into a triangular mesh; similar to gaming and computer graphics. Not
> only does this approach reduce the number of terms, but it has the added
> benefit of better accuracy (precision is based on the index encoding
> technique instead of the spatial resolution of the quad cell).
> For better clarity, consider the following illustrations (of a polygon in a 1
> degree x 1 degree spatial area). The first is using the quad tree technique
> applied in the existing inverted index. The second is using a triangular mesh
> decomposition as used by popular OpenGL and javascript rendering systems
> (such as those used by mapbox).
> !polyWHole.png!
> Decomposing this shape using a quad tree results in 1,105,889 quad terms at 3
> meter spatial resolution.
> !tessellatedPoly.png!
>
> Decomposing using a triangular mesh results in 8 triangles at the same
> resolution as {{encodeLat/Lon}}.
> The decomposed triangles can then be encoded as a 6 dimensional POINT and
> queries are implemented using the computed relations against these triangles
> (similar to how its done with the inverted index today).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
