: 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
