[OT] who are jteam ?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[OT] who are jteam ?

pjaol
Got a google alert from a very interesting / confusing page,
http://blog.jteam.nl/2009/08/03/geo-location-search-with-solr-and-lucene/

Anyone know who these guys are?
Reply | Threaded
Open this post in threaded view
|

Re: [OT] who are jteam ?

Yonik Seeley-2-2
On Thu, Dec 3, 2009 at 10:44 AM, patrick o'leary <[hidden email]> wrote:
> Got a google alert from a very interesting / confusing page,
> http://blog.jteam.nl/2009/08/03/geo-location-search-with-solr-and-lucene/

Yep, looks like they have their own spatial search component for solr.
Any concerns?
Long term I see it as a positive - local/spacial search will be in
core solr eventually, and the more people with practical experience to
provide input, the better.

> Anyone know who these guys are?

If you look at the authors on that link, a number of them are active
here in the solr community.

-Yonik
http://www.lucidimagination.com
Reply | Threaded
Open this post in threaded view
|

Re: [OT] who are jteam ?

pjaol
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.

Is the community being strengthening / weakened by patch distributions?
I still believe that spatial is better served as a contrib, rather than
core, or certainly would have been up until now.
So at least an easier to maintain and distribute version of it, could be
developed and iterated upon.

On Thu, Dec 3, 2009 at 7:51 AM, Yonik Seeley <[hidden email]>wrote:

> On Thu, Dec 3, 2009 at 10:44 AM, patrick o'leary <[hidden email]> wrote:
> > Got a google alert from a very interesting / confusing page,
> >
> http://blog.jteam.nl/2009/08/03/geo-location-search-with-solr-and-lucene/
>
> Yep, looks like they have their own spatial search component for solr.
> Any concerns?
> Long term I see it as a positive - local/spacial search will be in
> core solr eventually, and the more people with practical experience to
> provide input, the better.
>
> > Anyone know who these guys are?
>
> If you look at the authors on that link, a number of them are active
> here in the solr community.
>
> -Yonik
> http://www.lucidimagination.com
>
Reply | Threaded
Open this post in threaded view
|

Re: [OT] who are jteam ?

Yonik Seeley-2-2
On Thu, Dec 3, 2009 at 11:22 AM, patrick o'leary <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [OT] who are jteam ?

Mark Miller-3
Yonik Seeley wrote:

> On Thu, Dec 3, 2009 at 11:22 AM, patrick o'leary <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] who are jteam ?

IsabelDrost
In reply to this post by pjaol
On Thu, 3 Dec 2009 07:44:06 -0800
"patrick o'leary" <[hidden email]> wrote:

> Got a google alert from a very interesting / confusing page,
> http://blog.jteam.nl/2009/08/03/geo-location-search-with-solr-and-lucene/
>
> Anyone know who these guys are?

They did give a rather good talk on what they are doing with Solr at
this year's Apache Con EU in Amsterdam:

http://eu.apachecon.com/c/aceu2009/sessions/251

They are using Solr for customer search projects. Back then they were
planning to contribute back (bug fixes immediately, larger extensions
after some time).

Isabel
Reply | Threaded
Open this post in threaded view
|

Re: [OT] who are jteam ?

pjaol
In reply to this post by Mark Miller-3
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, 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.

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.


On Thu, Dec 3, 2009 at 8:48 AM, Mark Miller <[hidden email]> wrote:

> Yonik Seeley wrote:
> > On Thu, Dec 3, 2009 at 11:22 AM, patrick o'leary <[hidden email]>
> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: [OT] who are jteam ?

Mark Miller-3
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 <[hidden email]> wrote:
>
>  
>> Yonik Seeley wrote:
>>    
>>> On Thu, Dec 3, 2009 at 11:22 AM, patrick o'leary <[hidden email]>
>>>      
>> 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.
>>
>>    
>
>  

Reply | Threaded
Open this post in threaded view
|

Re: [OT] who are jteam ?

pjaol
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 <[hidden email]> 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 <[hidden email]>
> wrote:
> >
> >
> >> Yonik Seeley wrote:
> >>
> >>> On Thu, Dec 3, 2009 at 11:22 AM, patrick o'leary <[hidden email]>
> >>>
> >> 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.
> >>
> >>
> >
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [OT] who are jteam ?

Mark Miller-3
patrick o'leary wrote:

> 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.
>  
Okay, fair enough - I was going by the front page stats that mention a
number of recent commits and hearsay that was told to me by others (or
other ;) ).
To be fair, I haven't looked at the code, so I'm happy to take your word
for it. My apologies.

> As for leaving spatial contribution in a hairy state, you care to clarify?
>  
No documentation, almost no javadoc, extremely sparse tests, quite a few
bugs, some funky code / left over unused code.

There is a history of it on the Lucene-dev list - not that its that big
of a deal, but kind of irksome that those that put it in haven't
responded to any of the issues, and others that are
less familiar have had to somewhat pick up the torch. A couple people
were made contrib committers with the hope that they would help with the
upkeep and fixes - otherwise an existing
committer could have just dumped it all in. I don't really mean that as
negative as it prob comes off though.

 Some things are now better, but I don't think great. Part of the nature
of open source as well, but irksome non the less.

>
> On Thu, Dec 3, 2009 at 10:53 AM, Mark Miller <[hidden email]> 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 <[hidden email]>
>>>      
>> wrote:
>>    
>>>      
>>>> Yonik Seeley wrote:
>>>>
>>>>        
>>>>> On Thu, Dec 3, 2009 at 11:22 AM, patrick o'leary <[hidden email]>
>>>>>
>>>>>          
>>>> 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.
>>    
>>>>        
>>>      
>>    
>
>  


--
- Mark

http://www.lucidimagination.com



Reply | Threaded
Open this post in threaded view
|

Re: [OT] who are jteam ?

pjaol
>>No documentation, almost no javadoc, extremely sparse tests, quite a few
bugs, some funky code / left over unused code.
Some things are now better, but I don't think great. Part of the nature
of open source as well, but irksome non the less.
=====

That is true, and I do accept responsibility for it, I have had to step away
from open source
over the past year to focus on significantly more important personal things.

The most important goal I feel isn't perfection, but a basis that can be
improved up, I will be honest that if spatial lucene
had not been in lucene/contrib, I doubt that it would be alive today.
It exists because others have helped. (Which is why I'm as irked as I am
about the original subject of this thread)

Consolidation of documentation I found to always be a problem, which is why
I put www.gissearch.com together a few years ago
to assist with it while it was in Sourceforge, again I haven't had
opportunities to update and move that over to Apache's Wiki.

To me open source is not run as a corporate waterfall delivery, where the
initial delivery is the end goal, but a mere start, that other engineers
can contribute significantly to.

If I wasn't a firm believer in it, I would not be pushing as hard as I am to
ensure it is added to Solr



On Thu, Dec 3, 2009 at 11:30 AM, Mark Miller <[hidden email]> wrote:

> patrick o'leary wrote:
> > 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.
> >
> Okay, fair enough - I was going by the front page stats that mention a
> number of recent commits and hearsay that was told to me by others (or
> other ;) ).
> To be fair, I haven't looked at the code, so I'm happy to take your word
> for it. My apologies.
>
> > As for leaving spatial contribution in a hairy state, you care to
> clarify?
> >
> No documentation, almost no javadoc, extremely sparse tests, quite a few
> bugs, some funky code / left over unused code.
>
> There is a history of it on the Lucene-dev list - not that its that big
> of a deal, but kind of irksome that those that put it in haven't
> responded to any of the issues, and others that are
> less familiar have had to somewhat pick up the torch. A couple people
> were made contrib committers with the hope that they would help with the
> upkeep and fixes - otherwise an existing
> committer could have just dumped it all in. I don't really mean that as
> negative as it prob comes off though.
>
>  Some things are now better, but I don't think great. Part of the nature
> of open source as well, but irksome non the less.
> >
> > On Thu, Dec 3, 2009 at 10:53 AM, Mark Miller <[hidden email]>
> 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 <[hidden email]>
> >>>
> >> wrote:
> >>
> >>>
> >>>> Yonik Seeley wrote:
> >>>>
> >>>>
> >>>>> On Thu, Dec 3, 2009 at 11:22 AM, patrick o'leary <[hidden email]>
> >>>>>
> >>>>>
> >>>> 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.
> >>
> >>>>
> >>>
> >>
> >
> >
>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: [OT] who are jteam ?

Uri Boness
In reply to this post by pjaol
Hi Guys,

Let me pour some light on JTeam and the work we're doing with Spatial Solr.

We've been working with local lucene/solr for quite some time now (about a
year and half or more). Actually when we started, only local lucene was
available and only later local solr came out. We've been implementing
geo-location search using this functionality in several projects and in each
one we had to develop quite a bit of extra code and fix bugs.

As we state in our website, we're great believers in open source in general
(our company is partly the driving force behind the Spring Framework... our
founders are also the founders of SpringSource) and in Solr/Lucene in
particular. We believe in contributing to open source and in collaborative
transparent development.

From early on we tried to drive local solr in the community using Solr JIRA,
and if you look carefully, some of the latest patches in the relevant issue
(SOLR-773) were contributed by us (Chris Male). We tried to follow all the
discussion in this issue and provide patches for the different approaches
that were proposed. Unfortunately, there was very little activity on this
issue for quite some time and the same goes for the local lucene project
(both on SF and the patches in Lucene JIRA). It was even the case were some
of the committers started complaining that there is no real owner for these
issues.

So we tried to push it for quite some time but in the meantime we also
needed to further develop these patches due to continuous demand from some
of our clients and the community as a whole (after all, it is the second
most voted on feature in Solr, right after the Field Collapsing which also
happens to be pushed and heavily developed by us - by Martijn). The problem
obviously rose from the nature of this functionality - it's a patch. This
meant that clients that wanted to use it needed to have their own patched
version of Solr and I believe I don't need to explain that they were not
very amused by this fact.. in a way it put Solr in a bad light...  So we
took a decision to implement the exact same solution that we've committed as
patches but this time make it a proper plugin - one that can be jar'ed,
dropped in Solr lib directory and configured in solrconfig.xml... without
patching involved.

I'm sure you all know the balance game between open source and commercial
work. It is/was very hard for us to put and invest so much time in something
without getting paid for the time spent. This is the reason we decided to at
least sell support over this functionality. The plug-in itself is open
source and is available for anyone to download. We're not hiding anything.
The fact is, that a lot of companies just need support for these kind of
issues, specially when it still not provided by Solr and they need to find
their way in Solr JIRA to have it (not many people can or like to do that).
I see no problem with this model, in a way this is our commercial aspect of
this open source work that we're doing, I see no problem with it - this is
how SpringSource, JBoss, and Lucid (and many many other companies) do it. By
the end of the day we all need to put some food on the table.

So to make things a bit clearer. We're not taking any ownership on work that
is not ours, and in fact we try to commit all our work back to the community
under the Apache2 license. We tried to commit this code base to Solr and
we'll continue this efforts. We would be *extremely* happy if at least some
of it will be committed as we believe we did cleaned it up quite a bit and
made it much more extensible (BTW, mainly on the lucene part). We've been
active in the discussions in the JIRA issues and we'll continue to be
active... actually we were just about to have another major patch put in
Lucene's JIRA with all our code base. (probably will happen in the upcoming
week). I really recommend everyone that is interested to have a look at the
patches we're providing and we're always open for discussion on how these
can be integrated with the current committed code base and with the road map
of this functionality in general.

Feedback is more than welcome!

Cheers,
Uri
Reply | Threaded
Open this post in threaded view
|

Re: [OT] who are jteam ?

Grant Ingersoll-2
In reply to this post by Mark Miller-3

On Dec 3, 2009, at 4:48 PM, Mark Miller wrote:
>
> 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,

Actually, no, they cannot call it "Solr: geo search edition".  They can call it something else, but they can't call it Solr.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] who are jteam ?

Uri Boness
Grant Ingersoll wrote:
> On Dec 3, 2009, at 4:48 PM, Mark Miller wrote:
>  
>> 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,
>>    
>
> Actually, no, they cannot call it "Solr: geo search edition".  They can call it something else, but they can't call it Solr.
>  
Let's put things in proportions. We're not forking Solr and developing
our own version of it. We're not even forking the local solr
functionality. We only putting this functionality out there as a
*plugin* rather than a patch, because this is what the community asks
for. As far as the code base is concerned... it's still open sourced
under the Apache2 license, and it's still being contributed back to Solr
and Lucene as patches in JIRA.

Uri
Reply | Threaded
Open this post in threaded view
|

Re: [OT] who are jteam ?

Mark Miller-3
In reply to this post by Grant Ingersoll-2
For the sake of example it was easier to say that than go into Apaches  
name rules. I considered saying geo search for Solr (which apache  
still doesn't like) and those games (geo search on apache solr) or  
leaving solr out all together, but it just muddied the point for no  
reason.  The actual name doesn't really matter for the point ;) if you  
actually want to do this, talk to your lawyers :) Solr: geo search  
edition   Is just clearer for the fictional example without getting  
into name legalities. I wouldn't choose geo search edition for a name  
either, solr in front of it or not.

- Mark

http://www.lucidimagination.com (mobile)

On Dec 4, 2009, at 3:20 AM, Grant Ingersoll <[hidden email]> wrote:

>
> On Dec 3, 2009, at 4:48 PM, Mark Miller wrote:
>>
>> 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,
>
> Actually, no, they cannot call it "Solr: geo search edition".  They  
> can call it something else, but they can't call it Solr.