[jira] [Commented] (SOLR-4242) A better spatial query parser

["David Smiley (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13543586#comment-13543586 ] 

David Smiley commented on SOLR-4242:
------------------------------------

I suppose the biggest pain point usability-wise is getting the distance, sometimes needed for sorting, boosting, and simply displaying to the user.  The spatial query being able to returning the distance as the score is a cute trick but it's awkward when the spatial query isn't directly in 'q'.  It never feels right to put the user's keyword search anywhere but 'q'.  For an example of the awkwardness, see this example in SOLR-4255:
{noformat}
http://localhost:8983/solr/collection1/select?
defType=edismax
&q.alt=*:*
&debugQuery=on
&fl=*,score,distdeg:query({! score=distance filter=false v=$spatialfilter})
&boost=query({! score=recipDistance filter=false v=$spatialfilter})
&fq={! v=$spatialfilter}
&spatialfilter=geo:"Intersects(Circle(54.729696,-98.525391 d=10))"
{noformat}

The {{query(\{! score=... filter=false v=... \})}} function query is the ugliest part. Simply by having a named function like "spatialDist" would remove the need for 'query' and 'filter', and the default could be distance score so out goes the 'score' part to.  The function's argument could refer to both the field and query shape by parameter reference like how it's doing it now.  Or, the field name "geo" could be stored into the "sfield" parameter and referenced via 'fq' as a 'df' local-param, leaving the spatial query to just the CQL-ish part that can be parsed directly by SpatialArgsParser.  So end result could be:

{noformat}
http://localhost:8983/solr/collection1/select?
defType=edismax
&q.alt=*:*
&debugQuery=on
&sfield=geo
&fl=*,score,distdeg:spatialDist($spatialfilter})
&boost=spatialDist('recipDistance',$spatialfilter)
&fq={! df=$sfield v=$spatialfilter}
&spatialfilter=Intersects(Circle(54.729696,-98.525391 d=10))
{noformat}

In addition, a query parser named "spatial" could simplify the filter portion to fq=\{!spatial}  with default 'sfield' pointing to the spatial field, the default 'op' (or perhaps 'predicate') being intersects, and the default query shape being in a 'qgeom'.  The spatialDist function could even default to look for those parameters making it even more succinct.  So this would borrow a lot in concept from the Spatial 3 approach.
                
> A better spatial query parser
> -----------------------------
>
>                 Key: SOLR-4242
>                 URL: https://issues.apache.org/jira/browse/SOLR-4242
>             Project: Solr
>          Issue Type: New Feature
>          Components: query parsers
>            Reporter: David Smiley
>             Fix For: 4.2
>
>
> I've been thinking about how spatial support is exposed to Solr users. 
> Presently there's the older Solr 3 stuff, most prominently seen via \{!geofilt} and \{!bbox} done by [~gsingers] (I think). and then there's the Solr 4 fields using a special syntax parsed by Lucene 4 spatial that looks like mygeofield:"Intersects(Circle(1 2 d=3))" What's inside the outer parenthesis is parsed by Spatial4j as a shape, and it has a special (non-standard) syntax for points, rects, and circles, and then there's WKT.  I believe this scheme was devised by [~ryantxu].
> I'd like to devise something that is both comprehensive and is aligned with standards to the extent that it's prudent.  The old Solr 3 stuff is not comprehensive and not standardized.  The newer stuff is comprehensive but only a little based on standards. And I think it'd be nicer to implement it as a Solr query parser.  I'll say more in the comments.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org