You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Steve Rowe (JIRA)" <ji...@apache.org> on 2018/08/01 03:14:00 UTC
[jira] [Commented] (LUCENE-8396) Add Points Based Shape Indexing
[ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org