[
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: [email protected]
For additional commands, e-mail: [email protected]
