lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-7056) Spatial3d/Geo3d should have zero runtime dependencies
Date Tue, 01 Mar 2016 10:47:18 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173576#comment-15173576
] 

Michael McCandless commented on LUCENE-7056:
--------------------------------------------

Hmm I don't think this is a good idea?

Lucene shouldn't try to be in the business of "exporting spatial math libraries for others
to use".  We are a search engine, and our priorities here are to make spatial indexing and
searching work well.

If someone wants the geo3d math implemenation, alone, they can poach/fork from us?

It's the same reason why we don't e.g. invest in making FSTs easier for outsiders to use:
these are internal data structures that we use to provide awesome indexing/searching.

I would rather see us do the opposite: make all the geo3d math only APIs package private,
and publicly expose only the {{Geo3DPoint}} class, for indexing and searching?  This gives
us the most freedom to iterate on geo3d APIs, privately.

Also, it's still early for these new geo APIs, and it's not clear where they will live longish
term.  E.g., we are struggling with precision/fuzzines issues in the 2D geo math (this is
why only now we finally have a BKD/points distance query: see LUCENE-6698, LUCENE-6540, LUCENE-7054,
etc.), so we may very well want to make the geo3d the primary spatial implementation instead,
or a hybrid 2D/3D solution, which well mean more shuffling.

bq. In Lucene 5 that's actually all it has

Actually 5.x also has the classes for Lucene users to index and search with geo3d, under the
{{org.apache.lucene.bkdtree3d}} package in the {{spatial3d}} module.

It's just that in 6.0 most of that is folded into core, with core support for N-dimensional
points, so the minimal (2) classes were moved under the {{geo3d}} package.


> 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
>
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message