[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14692912#comment-14692912
]
Nicholas Knize commented on LUCENE-6699:
----------------------------------------
bq. Introducing a stray dependency outside of spatial3d seems like it would
make maintenance more of a nightmare rather than less.
I don't recall module dependency for Geo3D being an issue when it was part of
the spatial package, now we have spatial code in 3 separate modules and
suddenly you oppose module dependency? It makes no sense and this disarray of
spatial functionality only introduces more confusion, disorganization, and a
wider gap for getting more spatial contributors involved. Nevertheless, I
assume (hope) it resolves itself in time, otherwise lucene spatial capabilities
will continue to fragment.
bq. I don't recall you complaining over the last seven months about geo3d's
architecture and organization...
Rather combative. Don't confuse my suggestions for keeping things light,
approachable, and organized, as holding any enmity towards geo3d.
bq. I guess it's all part of the bigger question is whether geo3d should remain
separable from Lucene.
I still prefer it be a part of core/util so that (once again) the 90% geo use
case can be accomplished with no dependencies other than core. Having it in a
3d specific package seems no better than simply moving it to Apache SIS (where
all EPSG ellipsoids, OGC compliance, etc. are already provided). But that's not
my call.
bq. For me, Geo3d at the moment needs to remain as a working whole without
dependencies on the rest of Lucene
This messaging seems to change based on the agenda. Not that it matters except
for keeping in mind whats best for the lucene project as a whole.
> Integrate lat/lon BKD and spatial3d
> -----------------------------------
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch
>
>
> I'm opening this for discussion, because I'm not yet sure how to do
> this integration, because of my ignorance about spatial in general and
> spatial3d in particular :)
> Our BKD tree impl is very fast at doing lat/lon shape intersection
> (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
> points.
> I think to integrate with spatial3d, we would first need to record
> lat/lon/z into doc values. Somewhere I saw discussion about how we
> could stuff all 3 into a single long value with acceptable precision
> loss? Or, we could use BinaryDocValues? We need all 3 dims available
> to do the fast per-hit query time filtering.
> But, second: what do we index into the BKD tree? Can we "just" index
> earth surface lat/lon, and then at query time is spatial3d able to
> give me an enclosing "surface lat/lon" bbox for a 3d shape? Or
> ... must we index all 3 dimensions into the BKD tree (seems like this
> could be somewhat wasteful)?
--
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
