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.: <doc> <add> <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> .....etc. 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 <[EMAIL PROTECTED]> 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
