[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14693198#comment-14693198
]
Karl Wright commented on LUCENE-6699:
-------------------------------------
bq. Rather combative. Don't confuse my suggestions for keeping things light,
approachable, and organized, as holding any enmity towards geo3d.
I am not trying to be combative; I'm interested in the same things you are,
although I seem to look at the world a bit differently perhaps. My major
concern is that since January there's been quite a bit of back-and-forth with
David Smiley and others about various aspects of geo3d organization, structure,
abstractions, etc., and it seems like we'd be undoing quite a bit of what was
agreed on *then* to meet your concerns *now*?
bq. 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.
Unfortunately, *I* have constraints, in addition to Lucene. I cannot at the
moment contribute to Apache SIS, without going through a laborious and time
consuming company process. So if/when geo3d leaves Lucene, I won't immediately
be able to leave with it.
Also, as we've discussed before at some length, geo3d was developed and
optimized specifically for the search problem. While that seems like a minor
thing at first glance, it's actually quite a big deal. My impression was that
this was pretty far from the Apache SIS core mission.
bq. 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.
I've got two masters here. First, it's essential that my company continues to
be able to use geo3d, even before it is released via lucene. Remember that
development is taking place all the time on both sides. Right now, geo3d is
reasonably separable, and we've deliberately built the dependency structure to
maintain that. That was one of the reasons behind having a separate module.
If/when geo3d is actually pulled into core (which I still don't know will
definitely happen or not), then it's a different ballgame, and integration with
*other* core code will likely take place. But that hasn't happened yet and may
never happen.
> 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: [email protected]
For additional commands, e-mail: [email protected]
