On 11/19/13 4:06 AM, "Dhanesh Radhakrishnan" <dhan...@hifx.co.in> wrote:
>Hi David,
>Thank you so much for the detailed reply. I've checked each and every lat
>lng coordinates and its a purely polygon.
>After some time I did one change in the lat lng indexing.
>Changed the indexing format.
>
>Initially I indexed the latitude and longitude separated by comma Eg:-
>"location":["9.445890,76.540970"]
>Instead I indexed with space.
> "location":["9.445890 76.540970"]
Just to be clear, if you use a space, it's "x y" order. If you use a
comma, it's "y, x" order. If you use WKT, it's always a space in X Y
order (and of course, the shape name and other stuff). You may have
gotten your search to work but I have a hunch you have all your latitudes
and longitudes in the wrong position, but I can't possible know for sure
because your example datapoint is ambiguous. 76 degrees latitude is
pretty far up-there though, hence my hunch you've got it wrong.
>
>and it worked
>
>Also from your observation on IsWithIn predicate I tested with Intersects
>and I found there is a difference in the QTime.
>
>For IsWithin
> "QTime": 9
>ResponseHeader": {
>"status": 0,
>"QTime": 9
>},
>
>When I used "Intersects"
>responseHeader": {
>"status": 0,
>"QTime": 26
>}
There's no way the Intersects code is slower than IsWithin; IsWithin needs
to visit many more grid tiles -- big ones covering lots of docs. Perhaps
you have these times flipped as well ;-) Any way, given you have
multi-valued point data, you should choose the spatial predicate that
matches what you intend (your requirements). Maybe that's IsWithin, maybe
that's Intersects. *if* your field was *not* multi-valued (most people
don't have multi-valued spatial data per doc), then these two predicates
become semantically equivalent for such data, and so most people should
always choose Intersects even if "within" is colloquially how one thinks
of it.
~ David
