On Sat, Mar 26, 2011 at 2:17 PM, Ryan McKinley <[email protected]> wrote:
>>>
>>> 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'

Having something basic that works (and has a clean enough high level
HTTP interface)
was clearly a win for Solr users.  The


> 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]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to