lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "patrick o'leary" <pj...@pjaol.com>
Subject Re: [OT] who are jteam ?
Date Thu, 03 Dec 2009 19:21:35 GMT
Think we crossed lines somewhere on the first part of the discussion.


>>But your doing that yourself at source forge? Hasn't there been a lot of
work on an external LocalLucene, even after it was put into contrib?
While the contrib version was left in a fairly hairy state?
Thats just the nature of the license - but putting LocalLucene into
contrib hasn't appeared to help much.
====

I disagree Mark, locallucene hasn't been updated in 8 month on source forge
http://locallucene.svn.sourceforge.net/viewvc/locallucene/trunk/
 locallucene/<http://locallucene.svn.sourceforge.net/viewvc/locallucene/trunk/locallucene/>
 *168*<http://locallucene.svn.sourceforge.net/viewvc/locallucene/trunk/locallucene/?view=log>
 8
months  pjaol  Added getQuery(Query) method to convert distance filter to a
query allowing loca...
Only localsolr has had work performed on it,while waiting to get something
in Solr, spatial lucene has been slowly updated over time, by more than just
I
which is what open source and iteration is all about.
If you want to wait for perfection, you have to wait.

As for leaving spatial contribution in a hairy state, you care to clarify?


On Thu, Dec 3, 2009 at 10:53 AM, Mark Miller <markrmiller@gmail.com> wrote:

> patrick o'leary wrote:
> > Someone pulling an Al Gore (inventing the internet) on this isn't my
> > concern, heck you can just google for some of the class names of
> > locallucene and see how far spread it is,
> Then whats this about:
>
> "
>
> but it's giving significant, 'impression of ownership' of a lot of work
> that's been completed
> by other folks."
>
> > what I am more concerned about
> >
> > "Future versions of these patches may include support for search with
> > regular polygons, and the introduction of distance facets, allowing Solr
> > users to be able to filter their results based on the calculated
> distances."
> >
> > They're now 'flogging' recent and current work I and others are doing?
> >
> > ... not encouraging, and certainly not healthy for open source.
> >
> Doesn't sound that way to me.
> > I'm going to be brash and request that there is commitment to adding a
> basic
> > Spatial feature set for distance searching (restricted by distance) &
> > sorting
> > to Solr's trunk by the end of December. Iterate and refactor as needed
> after
> > that.
> >
> > There should not be any more excuses to having this code out in the cold
> as
> > patches and external projects.
> >
> But your doing that yourself at source forge? Hasn't there been a lot of
> work on an external LocalLucene, even after it was put into contrib?
> While the
> contrib version was left in a fairly hairy state?
>
> Thats just the nature of the license - but putting LocalLucene into
> contrib hasn't appeared to help much.
> >
> > On Thu, Dec 3, 2009 at 8:48 AM, Mark Miller <markrmiller@gmail.com>
> wrote:
> >
> >
> >> Yonik Seeley wrote:
> >>
> >>> On Thu, Dec 3, 2009 at 11:22 AM, patrick o'leary <pjaol@pjaol.com>
> >>>
> >> wrote:
> >>
> >>>> What spatial contributions have been contributed from this?
> >>>> I'm only seeing some query parsing / multi-threading extensions, no
> >>>>
> >> shapes /
> >>
> >>>> SRID's etc
> >>>> but it's giving significant, 'impression of ownership' of a lot of
> work
> >>>> that's been completed
> >>>> by other folks.
> >>>>
> >>>>
> >>> Looks like they acknowledge building on local solr and local lucene to
> >>>
> >> me:
> >>
> >>> """SSP started out its life as a patch for Solr Spatial Search
> >>> (Solr-773) and Spatial Lucene (Lucene-1732) and extends Solr and
> >>> Lucene with hereunto missing geodetic search functions (bounding boxes
> >>> etc) while improving on the speed of the result and performance when
> >>> dealing with a large data set through better query parsing and
> >>> multi-threaded filtering. Also included are improved extensibility and
> >>> documentation."""
> >>>
> >>> And in a way, they do "own" their plugin - their customizations,
> >>> packaging, etc (note: I haven't looked at it).  And they offer support
> >>> for it - which might be attractive to some companies that need
> >>> supported geosearch now.
> >>>
> >>> It's also open source under the Apache license, so presumably we could
> >>> borrow anything we want from it.
> >>>
> >>> -Yonik
> >>> http://www.lucidimagination.com
> >>>
> >>>
> >> I think Patrick is obviously referring to: However, in the last 6 months
> >> support for spatial search has begun to be added to Apache Lucene and
> >> Solr, much of which has been developed here at JTeam.
> >>
> >> "Much of which" is obviously a bit of an overstatement (to a great
> >> degree or extent) when you look at all the work thats been done.
> >>
> >> Oh well though. So it goes. Its Apache - they could package it all up,
> >> hide the code under the covers, put a notice saying some work was
> >> derived from Solr, call it Solr: geo search edition, and essentially
> >> take even more credit while adding little to nothing. I wouldn't sweat
> it.
> >>
> >>
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message