[ 
https://issues.apache.org/jira/browse/SOLR-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254354#comment-13254354
 ] 

Bill Bell commented on SOLR-2155:
---------------------------------

This is happening on SOLR 3.5 and SOLR 3.6. I did not check any other versions.

I changed the geodist() to name it geodisth() so I can try the LatLong and the 
GeoHash versions. They are different.

I tried dismax and edismax... No difference. This is not the only query that 
does this. Very consistent.

Here is the query:

http://localhost:8983/solr/select?fl=score,display_name,store_lat_lon,store_geohash,city_state&qt=autoproviderdist&d=100&pt=39.740112,-104.984856&defType=dismax&rows=100&q=shawn%20nakamura&echoParams=all&sfield=store_geohash&sort=geodisth%28%29%20asc&;

{code}

  <lst name="params">
    <str name="mm">1</str>
    <str name="d">100</str>
    <str name="sort">geodisth() asc</str>
    <str name="tie">0.01</str>
    <str name="sfield">store_geohash</str>
    <str name="qf">name_edgy name_edge name_word</str>
    <str name="q.alt">*:*</str>
    <str name="group.main">false</str>
    <str name="hl.fl">name_edgy</str>
    <str name="hl">false</str>
    <str name="defType">dismax</str>
    <str name="rows">100</str>
    <str name="echoParams">all</str>
    <str 
name="fl">score,display_name,store_lat_lon,store_geohash,city_state</str>
    <str name="pt">39.740112,-104.984856</str>
    <str name="boost">sum(recip(geodist(store_geohash), .5, 6, 6), 0.1)</str>
    <str name="group.field">pwid</str>
    <str name="group">false</str>
    <str name="d">100</str>
    <str name="sort">geodisth() asc</str>
    <str name="sfield">store_geohash</str>
    <str name="group.main">false</str>
    <str name="rows">100</str>
    <str name="defType">dismax</str>
    <str name="echoParams">all</str>
    <str name="debugQuery">true</str>
    <str 
name="fl">score,display_name,store_lat_lon,store_geohash,city_state</str>
    <str name="q">shawn nakamura</str>
    <str name="pt">39.740112,-104.984856</str>
    <str name="group">false</str>
    <str name="qt">autoproviderdist</str>
  </lst>

{code}

Results using geohash:

{code}

  <doc>
    <float name="score">1.7336502</float>
    <str name="city_state">Arvada, CO</str>
    <str name="display_name">Shawn M. XXX</str>
    <arr name="store_geohash">
      <str>39.8184319306165,-105.1404038630426</str>
    </arr>
    <str name="store_lat_lon">39.818432,-105.140404</str>
  </doc>
  <doc>
    <float name="score">1.7336502</float>
    <str name="city_state">Quincy, MA</str>
    <str name="display_name">Shawna XXX</str>
    <arr name="store_geohash">
      <str>42.22851206548512,-71.03219585493207</str>
    </arr>
    <str name="store_lat_lon">42.228512,-71.032196</str>
  </doc>
  <doc>
    <float name="score">1.7336502</float>
    <str name="city_state">Portsmouth, NH</str>
    <str name="display_name">Shawn A. XXX, LSW</str>
    <arr name="store_geohash">
      <str>43.07758695445955,-70.75780486688018</str>
    </arr>
    <str name="store_lat_lon">43.077587,-70.757805</str>
  </doc>
  <doc>
    <float name="score">1.7336502</float>
    <str name="city_state">XXX, HI</str>
    <str name="display_name">Shawn D. XXX, NP</str>
    <arr name="store_geohash">
      <str>21.49900102056563,-158.07000713422894</str>
    </arr>
    <str name="store_lat_lon">21.499001,-158.070007</str>
  </doc>
{code}

Results using LatLon:

{code}
  <doc>
    <float name="score">1.7336502</float>
    <str name="city_state">Aurora, CO</str>
    <str name="display_name">Shawna L. XXX, RN</str>
    <arr name="store_geohash">
      <str>39.669720036908984,-104.86465500667691</str>
    </arr>
    <str name="store_lat_lon">39.669720,-104.864655</str>
  </doc>
  <doc>
    <float name="score">1.7336502</float>
    <str name="city_state">Arvada, CO</str>
    <str name="display_name">Shawn M. XXX</str>
    <arr name="store_geohash">
      <str>39.8184319306165,-105.1404038630426</str>
    </arr>
    <str name="store_lat_lon">39.818432,-105.140404</str>
  </doc>
  <doc>
    <float name="score">1.7336502</float>
    <str name="city_state">Albuquerque, NM</str>
    <str name="display_name">Shawn C. XXX, PA</str>
    <arr name="store_geohash">
      <str>35.13116103596985,-106.5403369255364</str>
    </arr>
    <str name="store_lat_lon">35.131161,-106.540337</str>
  </doc>
{code}


                
> Geospatial search using geohash prefixes
> ----------------------------------------
>
>                 Key: SOLR-2155
>                 URL: https://issues.apache.org/jira/browse/SOLR-2155
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: David Smiley
>         Attachments: GeoHashPrefixFilter.patch, GeoHashPrefixFilter.patch, 
> GeoHashPrefixFilter.patch, 
> SOLR-2155_GeoHashPrefixFilter_with_sorting_no_poly.patch, SOLR.2155.p3.patch, 
> SOLR.2155.p3tests.patch, Solr2155-1.0.2-project.zip, 
> Solr2155-1.0.3-project.zip, Solr2155-1.0.4-project.zip, 
> Solr2155-for-1.0.2-3.x-port.patch
>
>
> {panel:title=NOTICE} There is a .zip attached to the issue with a .jar you 
> can drop in to Solr 3.x.  Lucene 4's new spatial module is largely based on 
> this code.  The Solr 4 glue for it should come very soon but as of this 
> writing it's hosted temporarily at Spatial4j.com.  For more information on 
> using SOLR-2155 with Solr 3, see 
> http://wiki.apache.org/solr/SpatialSearch#SOLR-2155  This JIRA issue is 
> closed because it won't be committed in its current form.
> {panel}
> There currently isn't a solution in Solr for doing geospatial filtering on 
> documents that have a variable number of points.  This scenario occurs when 
> there is location extraction (i.e. via a "gazateer") occurring on free text.  
> None, one, or many geospatial locations might be extracted from any given 
> document and users want to limit their search results to those occurring in a 
> user-specified area.
> I've implemented this by furthering the GeoHash based work in Lucene/Solr 
> with a geohash prefix based filter.  A geohash refers to a lat-lon box on the 
> earth.  Each successive character added further subdivides the box into a 4x8 
> (or 8x4 depending on the even/odd length of the geohash) grid.  The first 
> step in this scheme is figuring out which geohash grid squares cover the 
> user's search query.  I've added various extra methods to GeoHashUtils (and 
> added tests) to assist in this purpose.  The next step is an actual Lucene 
> Filter, GeoHashPrefixFilter, that uses these geohash prefixes in 
> TermsEnum.seek() to skip to relevant grid squares in the index.  Once a 
> matching geohash grid is found, the points therein are compared against the 
> user's query to see if it matches.  I created an abstraction GeoShape 
> extended by subclasses named PointDistance... and CartesianBox.... to support 
> 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 administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to