[
https://issues.apache.org/jira/browse/LUCENE-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15183950#comment-15183950
]
Nicholas Knize commented on LUCENE-7056:
----------------------------------------
bq. search shapes are typically not bizarre polygons or rectangles
I guess I should have clarified. The adversarial rectangles are created from
internal BKD nodes during split, they are not bizarre rectangles one would
create from a query. They are also not an abnormal corner case. Adversarial
rectangles can/will be created unless you know your data in advance.
bq. A worldwide selection of points are typically quite localized on the globe
+1. localized clusters. Unless separate indexes are created for different
regions - a viable recommendation if we find global data sets to drastically
degrade search performance.
bq. But it probably makes sense to evaluate using a better global test set.
Any good spatial indexing benchmark (as seen in most publications) should test
with real data, but also not ignore the sparse random data sets just for
characterizing performance for randomly distributed spatial data applications
(regardless of the popularity of this type of use case).
> Spatial3d/Geo3d should have zero runtime dependencies
> -----------------------------------------------------
>
> Key: LUCENE-7056
> URL: https://issues.apache.org/jira/browse/LUCENE-7056
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
> Reporter: David Smiley
> Assignee: David Smiley
> Fix For: 6.0
>
> Attachments: LUCENE_7056__split_spatial3d_package.patch,
> LUCENE_7056__split_spatial3d_package.patch
>
>
> This is a proposal for the "spatial3d" module to be purely about the
> shape/geometry implementations it has. In Lucene 5 that's actually all it
> has. In Lucene 6 at the moment its ~76 files have 2 classes that I think
> should go elsewhere: Geo3DPoint and PointInGeo3DShapeQuery. Specifically
> lucene-spatial-extras (which doesn't quite exist yet so lucene-spatial) would
> be a suitable place due to the dependency. _Eventually_ I see this module
> migrating elsewhere be it on its own or a part of something else more
> spatial-ish. Even if that never comes to pass, non-Lucene users who want to
> use this module for it's geometry annoyingly have to exclude the Lucene
> dependencies that are there because this module also contains these two
> classes.
> In a comment I'll suggest some specifics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
