lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dhanesh Radhakrishnan <dhan...@hifx.co.in>
Subject Re: Solr spatial search within the polygon
Date Wed, 20 Nov 2013 05:50:48 GMT
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.JtsSpatialContextFactory"
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@1ed6c279
)"
    ],
    "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. <dsmiley@mitre.org> wrote:

>
>
> On 11/19/13 4:06 AM, "Dhanesh Radhakrishnan" <dhanesh@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*

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