[
https://issues.apache.org/jira/browse/LUCENE-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15183477#comment-15183477
]
Michael McCandless commented on LUCENE-7056:
--------------------------------------------
Naming is the hardest part ;) But I think that should be moot in this case,
because I think geo3d shouldn't ever be seen by users: it's a low level geo
math implementation detail.
Lucene's dimensional point values (new in 6.0.0) are agnostic to whatever "user
space math" is used at search time to guide the intersection, and so we should
pick, in the spatial module, whatever math 1) gives the right results (no
fuzziness in the tests!) and 2) has good performance with no adversaries, and
give that to our users as the "spatial" indexing and searching implementation.
The math in projected 2D space seems fraught with accuracy issues that after
much iterating won't go away, e.g. see the struggles in LUCENE-6698,
LUCENE-6540, LUCENE-7054. Only that last issue (LUCENE-7054) finally succeeded
in adding a points based distance query that can pass its test that don't allow
for any "fuzz", except for quantization error, and only then by doing the most
limited of geo 2D math (so limited this query could easily be promoted to
core), but likely leaving a lot of search performance on the table. Even so,
it seems (based on the London, UK bench) to have similar performance to the
legacy (postings based) {{GeoPointDistanceQuery}}.
I tested the corresponding geo3d distance query (as best I could so far) and it
has nearly 2X the performance as our geo2d solution from LUCENE-7054, so unless
we can fix the geo2d math to be an "admissible" optimization for Lucene's
points, I think we should plan to make geo3d our default spatial implementation
going forwards, so that users index a {{LatLonPointField}} and under the hood
it's using the accurate, and fast, geo3d math.
> 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
