>> >> No, the question is: what justification is there for adding spatial >> support to solr-only, leaving lucene with a broken contrib module, >> versus adding it where it belongs and exposing it to solr? > > There need not be any linkage to lucene to improve a Solr feature. > If you disagree, we should vote to clarify - this is too important > (and too much of a negative for Solr). >
I don't think there is *requirement* to move the core spatial stuff to lucene, but I think there is huge benefit to both communities if things have as few dependencies as possible. To be frank, the spatial support in solr is pretty hairy -- it works for some use cases, but is not extendable and quite basic. Calling it 'distance' seems more appropriate then 'spatial' For good spatial support, I think we want to organize things with as few dependencies/assumptions as possible. This will let: * only basic math/geometry -- anything complex should use existing well tested solid frameworks (JTS/proj4/geotools/etc) we should not be reinventing/retesting this stuff. We need basic APIs that will work well with these external tools * lucene focus on fields and queries * solr focus on configuration and external interface This structure and constraints would be a big win for everyone. As always this stuff is hard to talk about in the abstract w/o a real proposal -- of course fixing/improving solr features does not *require* working in lucene-core. But I think we get better solutions when we aim for modular designs with minimum dependencies. ryan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
