Solr
  1. Solr
  2. SOLR-2154

Spatial support for MultiValued fields

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0-ALPHA
    • Fix Version/s: 4.0
    • Component/s: Build
    • Labels:
      None

      Description

      Is this an issue - it appears to work ?

      This appears to work on LatLon Spatial fields. It appears to find the right lat long... Is this supposed to work?
      I read that this does not work on solr.PointType, but it appears to work on LatLonType.

      <fieldType name="location" class="solr.PointType" dimension="2" subFieldSuffix="_d"/>
      <field name="store" type="location" indexed="true" stored="true" multiValued="true"/>

      Trying a few queries and I can get either of the 2 points.

      http://localhost:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=41.9244,-87.6473&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(41.9244,-87.6473))+asc,+score+desc&debugQuery=on
      
      1 result.
      
      http://10.0.1.37:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=47.7651,-122.362&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+desc&debugQuery=on
      
      2 results.
      
      schema.xml:
      <fieldType name="latLon" class="solr.LatLonType" subFieldSuffix="_latLon"/>
       <field name="store_lat_lon" type="latLon" indexed="true" stored="true" multiValued="true"/>
       
      sample.xml to import:
      <add>
        <doc>
          <field name="address">2300 North Childrens Plaza</field>
          <field name="id">1</field>
          <field name="store_lat_lon">41.9244,-87.6473</field>
          <field name="store_lat_lon">47.7651,-122.362</field>
          <field name="zipcode">60614</field>
        </doc>
        <doc>
          <field name="address">357 North West Richmond Beach Road</field>
          <field name="id">2</field>
          <field name="store_lat_lon">48.7651,-122.362</field>
          <field name="zipcode">98177</field>
        </doc>
        <doc>
          <field name="address">7555 North Overfield Road</field>
          <field name="id">3</field>
          <field name="store_lat_lon">32.948,-111.653</field>
          <field name="zipcode">85294</field>
        </doc>
      </add>
      

        Issue Links

          Activity

          Hide
          Bill Bell added a comment -

          The sort by does not work right.

          Sorting from 47.7651,-122.362

          http://localhost:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=47.7651,-122.362&d=200.9344&fq=

          {!sfilt%20fl=store_lat_lon}

          &sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+desc&debugQuery=on

          I get 48.7651,-122.362 (357 North West Richmond Beach Road) coming out first.

          Show
          Bill Bell added a comment - The sort by does not work right. Sorting from 47.7651,-122.362 http://localhost:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=47.7651,-122.362&d=200.9344&fq= {!sfilt%20fl=store_lat_lon} &sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+desc&debugQuery=on I get 48.7651,-122.362 (357 North West Richmond Beach Road) coming out first.
          Hide
          Bill Bell added a comment -

          If the sort by could scan both lat long values for the one closest this would be solved.

          Grant can you look at this?

          Show
          Bill Bell added a comment - If the sort by could scan both lat long values for the one closest this would be solved. Grant can you look at this?
          Hide
          David Smiley added a comment -

          I needed multi-valued spatial search too and I wrote the code to do it using a geohash prefix technique. Check out my patch at SOLR-2155.

          Show
          David Smiley added a comment - I needed multi-valued spatial search too and I wrote the code to do it using a geohash prefix technique. Check out my patch at SOLR-2155 .
          Hide
          Bas de Nooijer added a comment -

          The problem is not just sorting. When using a multivalue latLon field ANY combination of latitude and longitude values will match.
          You can try it in the given example schema and data with this query:
          [code]
          http://localhost:8983/solr/core0/select/?q=store_lat_lon:[40,-125%20TO%2045,-100]&version=2.2&start=0&rows=10&indent=on
          [/code]
          This range query (bounding box) returns document 1, while both latlon combinations are outside the box.

          What actually happens is a match on each multivalue subfield of the latlon polyfield. You can see it in debug:
          [code]
          +store_lat_lon_0_latLon:[40.0 TO 45.0] +store_lat_lon_1_latLon:[-125.0 TO -100.0]
          [/code]

          So as long as any latitude value and any longitude value match the bbox, the document will be returned. In this case it is matched on the combination 41.9244,-122.362
          The token position in each multivalue field should be respected, but as far as I know this is not easily possible.

          Show
          Bas de Nooijer added a comment - The problem is not just sorting. When using a multivalue latLon field ANY combination of latitude and longitude values will match. You can try it in the given example schema and data with this query: [code] http://localhost:8983/solr/core0/select/?q=store_lat_lon:[40,-125%20TO%2045,-100]&version=2.2&start=0&rows=10&indent=on [/code] This range query (bounding box) returns document 1, while both latlon combinations are outside the box. What actually happens is a match on each multivalue subfield of the latlon polyfield. You can see it in debug: [code] +store_lat_lon_0_latLon: [40.0 TO 45.0] +store_lat_lon_1_latLon: [-125.0 TO -100.0] [/code] So as long as any latitude value and any longitude value match the bbox, the document will be returned. In this case it is matched on the combination 41.9244,-122.362 The token position in each multivalue field should be respected, but as far as I know this is not easily possible.
          Hide
          Bill Bell added a comment -

          This is duplicated

          Show
          Bill Bell added a comment - This is duplicated
          Hide
          Grant Ingersoll added a comment -

          I'd say this is not specifically a duplicate of the geo-hash.

          Show
          Grant Ingersoll added a comment - I'd say this is not specifically a duplicate of the geo-hash.
          Hide
          David Smiley added a comment -

          True; it's not a duplicate. I propose that this issue can be closed when LSP core (lucene-spatial-playground) replaces the defunct lucene-spatial module. It includes multi-value geospatial fields. And yes it uses geohashes. Around January 1st, Chris or Ryan or I will get the ball rolling on a proposal to make this happen.

          Show
          David Smiley added a comment - True; it's not a duplicate. I propose that this issue can be closed when LSP core (lucene-spatial-playground) replaces the defunct lucene-spatial module. It includes multi-value geospatial fields. And yes it uses geohashes. Around January 1st, Chris or Ryan or I will get the ball rolling on a proposal to make this happen.
          Hide
          Joel Bernstein added a comment - - edited

          It appears from the ticket LUCENE-3795 that LSP has been integrated into Lucene. Can the Multi-valued fields be accessed from Solr as well?

          Show
          Joel Bernstein added a comment - - edited It appears from the ticket LUCENE-3795 that LSP has been integrated into Lucene. Can the Multi-valued fields be accessed from Solr as well?
          Hide
          David Smiley added a comment -

          This issue and the one for polygons can be closed once the Solr adapters are committed SOLR-3304.

          Show
          David Smiley added a comment - This issue and the one for polygons can be closed once the Solr adapters are committed SOLR-3304 .
          Hide
          David Smiley added a comment -

          SOLR-3304 is committed, and consequently there is now multi-value index support. I'm resolving this issue.

          Show
          David Smiley added a comment - SOLR-3304 is committed, and consequently there is now multi-value index support. I'm resolving this issue.
          Hide
          Uwe Schindler added a comment -

          Closed after release.

          Show
          Uwe Schindler added a comment - Closed after release.

            People

            • Assignee:
              David Smiley
              Reporter:
              Bill Bell
            • Votes:
              5 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development