GIS

[Guillermo Payet <gp...@localharvest.org>]

Hello,

I'm new here, so first of all I'd like to say hello to everyone. 

So, hi there...

I just spent two days trying to get Lucene to handle "geographically
constricted" searches for our website. (Check out www.localharvest.org)

I got close, but no cigar. (it works, but is very slow)

We need to be able to do searches only within a geographicaly limited
set of documents.  (In this case, our member listings)

So... I'd like to volunteer to add the needed functions in Lucene
to:

  - build a LatLonField class for geographical coordinates
  - build a LatLonRectTerm (or whatever) to define matches 
    within a latitude/longituded defined rectangle.
  - build a LatLonRadiusTerm (or whatever) to define all matches
    within X distance from a point (lat,lon).

We're now doing all of this through MySQL, which works "ok", but leaves
a lot to be desired for the relevance of search results for a lot of 
searches.  I've already written all the spherical trig functions to
to do these searches accurately, and I'd love to port them into
Lucene.

So my questions are:

 - Has there been any talk about doing this before?
 - Is this a bad idea for any reason?
 - What would be the right approach to do this?

The fact that Lucene stores and indexes (or seems it seems) all terms 
as Strings and that there is no NumericTerm makes me think that I 
might be missing something and that this migh be a much bigger deal
than I think?

	--G




-- 
Guillermo Payet
L O C A L  H A R V E S T
http://www.localharvest.org

Every Morning I awake torn between a desire to save the world and 
an inclination to savor it.  This makes it hard to plan the day.

                                                       -E.B.White


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org

Re: GIS

[Doug Cutting <cu...@apache.org>]

Guillermo Payet wrote:
> The fact that Lucene stores and indexes (or seems it seems) all terms 
> as Strings and that there is no NumericTerm makes me think that I 
> might be missing something and that this migh be a much bigger deal
> than I think?

You could write a HitCollector that uses 
FieldCache.getFloats("latitude") and FieldCache.getFloats("longitude") 
to efficiently lookup the latitude and longitude of each textual match. 
  Then combine the distance score with the text score.

Doug



---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org

Re: Pluggable Lock Framework - how to submit code enhancement?

[Otis Gospodnetic <ot...@yahoo.com>]

Official Hi Jeff,

That sounds like something many users would appreciate.  Bugzilla is
the best way to submit your code.  Open a new 'bug' in Bugzilla, prefix
the summary line with [PATCH], and then attach your code.  This will
have to be a 2-step process: 1) open a bug, 2) attach code.  That's
just how Bugzilla works.

Otis

--- Jeff Patterson <lu...@webdoyen.com> wrote:

> I've been lurking here as a watcher for a while, but
> this is my first post - make this an official "hi!"
> 
> We use Lucene at work on a HA system across 2
> machines with multiple JVMs accessing the same
> NFS-mounted index directory.  We overcame the
> NFS locking deficiencies in Lucene by wrapping
> the Lucene API calls in a home-grown database
> locking mechanism.  I have since hooked up to
> the CVS tree for the 1.5 candidate and have
> built in to the codebase a pluggable Lock
> Override framework allowing a user to build their
> own locking mechanism (if you don't, it defaults
> to the current filesystem Lock).
> 
> This framework seems like it would be beneficial
> to the larger community.  What is the best way
> for me to get the changes incorporated in to the
> next release?  I slightly modified:
> 
>   org.apache.lucene.store.FSDirectory
> 
> and added one new small class:
> 
>   org.apache.lucene.store.LockFactory
> 
> Additional tweaks would be advised around
> my changes, but I think they would be minor.
> 
> Please advise on proper submission protocol. Is it
> Bugzilla, to this list, or other?
> 
> Thanks - Jeff
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org

Pluggable Lock Framework - how to submit code enhancement?

[Jeff Patterson <lu...@webdoyen.com>]

I've been lurking here as a watcher for a while, but
this is my first post - make this an official "hi!"

We use Lucene at work on a HA system across 2
machines with multiple JVMs accessing the same
NFS-mounted index directory.  We overcame the
NFS locking deficiencies in Lucene by wrapping
the Lucene API calls in a home-grown database
locking mechanism.  I have since hooked up to
the CVS tree for the 1.5 candidate and have
built in to the codebase a pluggable Lock
Override framework allowing a user to build their
own locking mechanism (if you don't, it defaults
to the current filesystem Lock).

This framework seems like it would be beneficial
to the larger community.  What is the best way
for me to get the changes incorporated in to the
next release?  I slightly modified:

  org.apache.lucene.store.FSDirectory

and added one new small class:

  org.apache.lucene.store.LockFactory

Additional tweaks would be advised around
my changes, but I think they would be minor.

Please advise on proper submission protocol. Is it
Bugzilla, to this list, or other?

Thanks - Jeff

---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org