Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of erickerickson@gmail.com
 designates 209.85.215.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <788445007.6929.1331615866789.JavaMail.tomcat@hel.zones.apache.org>
References: 
 <788445007.6929.1331615866789.JavaMail.tomcat@hel.zones.apache.org>
Date: Tue, 13 Mar 2012 08:24:10 -0500
Message-ID: 
 <CAN4YXvdA53SoZWQKJL2KK4axAMX1pEbqP9GiyqEP_B4WctE5aA@mail.gmail.com>
Subject: Re: [jira] [Commented] (SOLR-2155) Geospatial search using geohash
 prefixes
From: Erick Erickson <erickerickson@gmail.com>
To: dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Be brave, just go for building it <G>...
It's actually surprisingly easy.

Start here:

http://wiki.apache.org/solr/HowToContribute


you should be able to get this all running (assuming
you have svn, ant and a jdk) in about 15 minutes,
exclusive of the checkout time. I was amazed first
time I tried it.

One note: Solr 3.x all go against the 1.5 JDK. It should
work against the 1.6, but note that the release was compiled
with 1.5.....


Applying the patches is patching source code and recompiling


Best
Erick

On Tue, Mar 13, 2012 at 12:17 AM, Harley Parks (Commented) (JIRA)
<jira@apache.org> wrote:
>
> =A0 =A0[ https://issues.apache.org/jira/browse/SOLR-2155?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
13228218#comment-13228218 ]
>
> Harley Parks commented on SOLR-2155:
> ------------------------------------
>
> So, basic question.. perhaps needs to be posted else where.
> I'm working with Solr 3.4, using the GeoHash to store multiple locations =
for a document.
> if geofilt or geodist doesn't work with the GeoHash, is the only way to a=
dd this patch into solr 3.4?
> I'm using a tomcat and solr, and jumping to 4.0 might be a while, even if=
 it's released soon.
>
> I'm not real clear how to apply the patch, as I would need basically crea=
te the solr.war file from the source... and compile all of the other source=
s... painful, but once setup, perhaps rewarding.
>
> Ideally, I would have a jar file from the patch, that I drop into the sol=
r/lib and make the needed changes to the config files.
>
> So, I'm real interested in getting something stable, so i'm watching the =
above mentioned links.
>
> David Smiley, would you be able to amend your book - Apache Solr 3 ESS, w=
hich mentions solr-2155, to include how to implement this patch? or do I ne=
ed to get brave, and build the source?
>
>> Geospatial search using geohash prefixes
>> ----------------------------------------
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Key: SOLR-2155
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 URL: https://issues.apache.org/jira/brow=
se/SOLR-2155
>> =A0 =A0 =A0 =A0 =A0 =A0 Project: Solr
>> =A0 =A0 =A0 =A0 =A0Issue Type: Improvement
>> =A0 =A0 =A0 =A0 =A0 =A0Reporter: David Smiley
>> =A0 =A0 =A0 =A0 Attachments: GeoHashPrefixFilter.patch, GeoHashPrefixFil=
ter.patch, GeoHashPrefixFilter.patch, SOLR-2155_GeoHashPrefixFilter_with_so=
rting_no_poly.patch, SOLR.2155.p3.patch, SOLR.2155.p3tests.patch, Solr2155-=
1.0.2-project.zip, Solr2155-1.0.3-project.zip, Solr2155-for-1.0.2-3.x-port.=
patch
>>
>>
>> There currently isn't a solution in Solr for doing geospatial filtering =
on documents that have a variable number of points. =A0This scenario occurs=
 when there is location extraction (i.e. via a "gazateer") occurring on fre=
e text. =A0None, one, or many geospatial locations might be extracted from =
any given document and users want to limit their search results to those oc=
curring in a user-specified area.
>> I've implemented this by furthering the GeoHash based work in Lucene/Sol=
r with a geohash prefix based filter. =A0A geohash refers to a lat-lon box =
on the earth. =A0Each successive character added further subdivides the box=
 into a 4x8 (or 8x4 depending on the even/odd length of the geohash) grid. =
=A0The first step in this scheme is figuring out which geohash grid squares=
 cover the user's search query. =A0I've added various extra methods to GeoH=
ashUtils (and added tests) to assist in this purpose. =A0The next step is a=
n actual Lucene Filter, GeoHashPrefixFilter, that uses these geohash prefix=
es in TermsEnum.seek() to skip to relevant grid squares in the index. =A0On=
ce a matching geohash grid is found, the points therein are compared agains=
t the user's query to see if it matches. =A0I created an abstraction GeoSha=
pe extended by subclasses named PointDistance... and CartesianBox.... to su=
pport different queried shapes so that the filter need not care about these=
 details.
>> This work was presented at LuceneRevolution in Boston on October 8th.
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administra=
tors: https://issues.apache.org/jira/secure/ContactAdministrators!default.j=
spa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

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