Dhanesh,
> I'm pretty sure that the coordinates are in the right position.
> "9.445890,76.540970" is in India, precisely in Kerala state :)
My suspicion was wright; you have all of your latitudes and longitudes in
the wrong position. Your example that I quote you on above is correct
("lat,lon") , but you're not indexing it that way (you're doing "lat
lon"). If you corrected your indexing to use "lat,lon" (as you should
do), you will find that the WKT you generate in your queries is also
reversed. The way you're doing it now prevents you from searching
anywhere out of -90 & +90 degrees longitude. At this point I don't think
I can be any more clear.
Good luck.
~ David
On 11/20/13 12:50 AM, "Dhanesh Radhakrishnan" <dhan...@hifx.co.in> wrote:
>Hi David,
>Thank you for your reply
>This is my current schema and field type "location_rpt" is a
>SpatialRecursivePrefixTreeFieldType and
>Field "location" is a type "location_rpt" and its multiValued
>
><types>
> <fieldtype name="string" class="solr.StrField" sortMissingLast="true"
>omitNorms="true"/>
> <fieldType name="long" class="solr.TrieLongField" precisionStep="0"
>positionIncrementGap="0"/>
> <fieldType name="tdouble" class="solr.TrieDoubleField"
>precisionStep="8" omitNorms="true" positionIncrementGap="0"/>
> <fieldType name="location_rpt"
>class="solr.SpatialRecursivePrefixTreeFieldType"
>spatialContextFactory="com.spatial4j.core.context.jts.JtsSpatialContextFac
>tory"
>distErrPct="0.025" maxDistErr="0.000009" units="degrees" geo="true" />
></types>
>
>
>
><fields>
> <field name="_version_" type="long" indexed="true" stored="true"
>multiValued="false"/>
> <field name="id" type="string" stored="true" indexed="true"
>multiValued="false" omitNorms="true" omitTermFreqAndPositions="true"
>termVectors="false"/>
> <field name="name" type="string" stored="true" indexed="true" />
> <field name="state" type="string" stored="true" indexed="true"
>required="false" />
> <field name="locality" type="string" stored="true" indexed="true"
>required="false" />
> <field name="address" type="string" stored="true" indexed="true"
>required="false" />
> <field name="location" type="location_rpt" indexed="true"
>stored="true" multiValued="true" />
></fields>
>
>Whenever add a document to solr, I'll collect the current latitude and
>longitude of particular business and index in the field "location"
>It's like
>$doc->setField('location', $business['latitude']."
>".$business['longitude']);
>This should looks like "location":["9.445890 76.540970"] in solr
>
>What I'm doing is that in Map view of search result , there is one
>provision to draw polygon in map and fetch the result based on the
>drawing.
>
>http://localhost:8983/solr/poc/select?fl=id,name,locality&wt=json&json.nl=
>map&q=*:*&fq=state:Kerala&fq=location:"IsWithin(POLYGON((9.471920923238988
>76.5496015548706,9.464174399734185 76.53947353363037,9.457232011740006
>76.55457973480225,9.471920923238988 76.5496015548706)))
>distErrPct=0"&debugQuery=true
>
>I'm pretty sure that the coordinates are in the right position.
>"9.445890,76.540970" is in India, precisely in Kerala state :)
>
>It is highly appreciated that you kindly correct me if I'm in wrong way
>
>
>
>
>
>This is response from solr
>
>"responseHeader": {
> "status": 0,
> "QTime": 5
>},
>"response": {
> "numFound": 3,
> "start": 0,
> "docs": [
> {
> "id": "192",
> "name": "50 cents of ideal plot",
> "locality": "Changanassery"
> },
> {
> "id": "189",
> "name": "new independent house for sale",
> "locality": "Changanassery"
> },
> {
> "id": "188",
> "name": "Renovated Resort style home with 21 cent",
> "locality": "Changanassery"
> }
> ]
>}
>
>
>
>Here is the debug mode output of the query
>
>
>"debug": {
> "rawquerystring": "*:*",
> "querystring": "*:*",
> "parsedquery": "MatchAllDocsQuery(*:*)",
> "parsedquery_toString": "*:*",
> "explain": {
> "188": "\n1.0 = (MATCH) MatchAllDocsQuery, product of:\n 1.0 =
>queryNorm\n",
> "189": "\n1.0 = (MATCH) MatchAllDocsQuery, product of:\n 1.0 =
>queryNorm\n",
> "192": "\n1.0 = (MATCH) MatchAllDocsQuery, product of:\n 1.0 =
>queryNorm\n"
> },
> "QParser": "LuceneQParser",
> "filter_queries": [
> "state:Kerala",
> "location:\"IsWithin(POLYGON((9.471920923238988
>76.5496015548706,9.464174399734185 76.53947353363037,9.457232011740006
>76.55457973480225,9.471920923238988 76.5496015548706))) distErrPct=0\""
> ],
> "parsed_filter_queries": [
> "state:Kerala",
>
>"ConstantScore(org.apache.lucene.spatial.prefix.WithinPrefixTreeFilter@1ed
>6c279
>)"
> ],
> "timing": {
> "time": 5,
> "prepare": {
> "time": 1,
> "query": {
> "time": 1
> },
> "facet": {
> "time": 0
> },
> "mlt": {
> "time": 0
> },
> "highlight": {
> "time": 0
> },
> "stats": {
> "time": 0
> },
> "debug": {
> "time": 0
> }
> },
> "process": {
> "time": 4,
> "query": {
> "time": 3
> },
> "facet": {
> "time": 0
> },
> "mlt": {
> "time": 0
> },
> "highlight": {
> "time": 0
> },
> "stats": {
> "time": 0
> },
> "debug": {
> "time": 1
> }
> }
> }
>}
>
>
>On Tue, Nov 19, 2013 at 8:56 PM, Smiley, David W. <dsmi...@mitre.org>
>wrote:
>
>>
>>
>> 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
>>
>>
>
>
>--
>*dhanesh s.r*
