: aaah -- Just to be clear, if you could augment the doc list with a calculated
: field ('distance') you would not need to extend XMLWritter - correct?
:
: And then it would also work with the JSON/pyton/php etc writers.
i don't think i ever looked at the patch in question (is it in Jira?) but
patrick o'leary wrote:
Actually misspoke it's the XMLWritter that's final that was a little
annoying rather than a handler.
Would have been nice to just extend that, and cut down on the code.
aaah -- Just to be clear, if you could augment the doc list with a
calculated field ('distance') you
Actually misspoke it's the XMLWritter that's final that was a little
annoying rather than a handler.
Would have been nice to just extend that, and cut down on the code.
P
Ryan McKinley wrote:
SOLR-281 looks like it will solve one of my frustrations, another being
that the handlers were f
SOLR-281 looks like it will solve one of my frustrations, another being
that the handlers were final ;-)
What handlers are final that you found annoying?
Is it close to being committed to the trunk?
I hope so ;) Since this patch reworks the *core* query handlers
(dismax/standard) I real
Hi Ryan
Thanks for looking at it, yes definitely I'd like to contribute back.
I'm currently working out some of the logistics to make it easier to
maintain.
I think I'd need a centralized project to do the releases from, it will
have 2 sets
of patches in 2 different trunks (lucene & solr), un
This looks good!
Are you interested in contributing it to solr core?
One major thing in the solr pipeline you may want to be aware of is the
search component interface (SOLR-281).
This would let you make simple component that adds the:
DistanceQuery dq = new DistanceQuery(dlat,dlng,dradius)
o operates exactly the same way: you send signals here, they
>>> receive them there. The only difference is that there is no cat.
>>> - Albert Einstein
>>>
>>> View Patrick O Leary's LinkedIn profileView Patrick O Leary's profile
>>> <http://www.linkedin.com/in/pjaol>
>>>
>>>
>>>
>>
>>
>
> --
>
> Patrick O'Leary
>
>
> You see, wire telegraph is a kind of a very, very long cat. You pull his
> tail in New York and his head is meowing in Los Angeles.
> Do you understand this?
> And radio operates exactly the same way: you send signals here, they
> receive them there. The only difference is that there is no cat.
> - Albert Einstein
>
> View Patrick O Leary's LinkedIn profileView Patrick O Leary's profile
> <http://www.linkedin.com/in/pjaol>
>
>
--
View this message in context:
http://www.nabble.com/Geographical-distance-searching-tf4524338.html#a13296862
Sent from the Solr - User mailing list archive at Nabble.com.
Hi Doug
What exactly are you looking for?
The code for localsolr is still in dev state, but I've left my work
open and available for download
at http://www.nsshutdown.com/viewcvs/viewcvs.cgi/localsolr/
Once I'm happy with it, I'll donate it back in the form of patches
until / unless it's acce
ry
>
>
> You see, wire telegraph is a kind of a very, very long cat. You pull his
> tail in New York and his head is meowing in Los Angeles.
> Do you understand this?
> And radio operates exactly the same way: you send signals here, they
> receive them there. The only dif
As far as I'm concerned nothings going to beat PG's GIS calculations,
but it's tsearch was
a lot slower than myisam.
My goal was a single solution to reduce our complexity, but am
interested to know if combining
both an rdbms & lucene works for you. Definitely let me know how it
goes !
P
Gu
Hi Patrick,
On 9/27/07, patrick o'leary <[EMAIL PROTECTED]> wrote:
> p.s after a little tidy up I'll be adding this to both lucene and solr's
> repositories if folks feel that it's a useful addition.
It's definitely very interesting. Did you compare performances of
Lucene with a database allowi
ld be able to pull in the lat/lon
values from valuesource fields and then do your greater circle
calculation.
- will
-Original Message-
From: Lance Norskog [mailto:[EMAIL PROTECTED]] Sent: Wednesday,
September 26, 2007 3:15 PM
To: solr-user@lucene.apache
ld be able to pull in the lat/lon
values from valuesource fields and then do your greater circle calculation.
- will
-Original Message-
From: Lance Norskog [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 3:15 PM
To: solr-user@lucene.apache.org
Subject: Geographical dis
PROTECTED]
Sent: Wednesday, September 26, 2007 3:15 PM
To: solr-user@lucene.apache.org
Subject: Geographical distance searching
It is a "best practice" to store the master copy of this data in a
relational database and use Solr/Lucene as a high-speed cache.
MySQL has a geographical database
It is a "best practice" to store the master copy of this data in a
relational database and use Solr/Lucene as a high-speed cache.
MySQL has a geographical database option, so maybe that is a better option
than Lucene indexing.
Lance
(P.s. please start new threads for new topics.)
-Original M
15 matches
Mail list logo
