lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Rodenburg" <>
Subject Re: One item, multiple fields, and range queries
Date Thu, 18 Jan 2007 01:49:16 GMT
Now I follow.  I was misreading the first comments, thinking that the field
content would be deconstructed to smaller components or pieces.  Too much
(or not enough) coffee.

I'm expecting the index doc needs to be constructed with lat/long/dates in
sequential order, i.e.:

   <field name="event_id">123</field>

   <field name="latitude">32.123456</field>
   <field name="longitude">-88.987654</field>
   <field name="when">01/31/2007</field>

   <field name="latitude">42.123456</field>
   <field name="longitude">-98.987654</field>
   <field name="when">01/31/2007</field>

   <field name="latitude">40.123456</field>
   <field name="longitude">-108.987654</field>
   <field name="when">01/30/2007</field>

Assuming slop count of 0, while the intention is to match lat/long/when in
that order, could it possibly match long/when/lat, or when/lat/long?  Does
PhraseQuery enforce order and starting point as well?

Assuming all of this, how does range query come into play?  Or could the
PhraseQuery portion be applied as a filter?

On 1/17/07, Chris Hostetter <> wrote:
> : OK, you lost me.  It sounds as if this PhraseQuery-ish approach involves
> : breaking datetime and lat/long values into pieces, and evaluation occurs
> : with positioning.  Is that accurate?
> i'm not sure what you mean by pieces ... the idea is that you would have a
> single "latitude" field and a single "longitude" field and a single "when"
> field, and if an item had a single event, you would store a single value
> in each field ... but if the item has multiple events, you would store
> them in the same relative ordering, and then use the same kind of logic
> PhraseQuery uses to verify that if the "latitude" field has a value in the
> right range, and the "longitude" field has a value in the right range, and
> the "when" field has a value in the right range, that all of those values
> have the same position (specificly: are within a set amount of slop from
> eachother, which you would allways set to "0")
> : > It seems like this could even be done in the same field if one had a
> : > query type that allowed querying for tokens at the same position.
> : > Just index "_noun" at the same position as "house" (and make sure
> : > there can't be collisions between real terms and markers via escaping,
> : > or use \0 instead of _, etc).
> true ... but the point doug made way back when is that with a generalized
> multi-field phrase query you wouldn't have to do that escaping ... the
> hard part in this case is the numeric ranges.
> -Hoss

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message