You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Ishan Chattopadhyaya (JIRA)" <ji...@apache.org> on 2014/12/31 14:55:14 UTC
[jira] [Comment Edited] (SOLR-4242) A better spatial query parser
[ https://issues.apache.org/jira/browse/SOLR-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262172#comment-14262172 ]
Ishan Chattopadhyaya edited comment on SOLR-4242 at 12/31/14 1:54 PM:
----------------------------------------------------------------------
David, what are your thoughts on how we should proceed?
If I understood correctly, the path forward could be to:
* Have a new {!sfilt} parser that does all that {!geofilt} does, but also takes WKT as a local param. And, deprecate the {!geofilt}.
* Have a spatialDist() or spatialDistance() function that refers to sfield parameter by default for the spatial field, and accepts the query string (predicate and query shape string) as its only parameter. However, here, what if the user wants to combine spatialDist() scores from two different spatial fields, since both would end up refering to sfield param. If this is indeed a problem, how about having spatialDistance() accept both sfield and spatial query string, e.g. spatialDist("geo:Intersects(...)") or something similar?
was (Author: ichattopadhyaya):
David, what are your thoughts on how we should proceed?
If I understood correctly, the path forward could be to:
* Have a new {!sfilt} parser that does all that {!geofilt} does, but also takes WKT as a local param. And, deprecate the {!geofilt}.
* Have a spatialDist() or spatialDistance() function that refers to sfield parameter by default for the spatial field, and accepts the query string (predicate and query shape string) as its only parameter. However, here, what if the user wants to combine spatialDist() scores from two different spatial fields, since both would end up refering to sfield param. If this is indeed a problem, how about having spatialDistance() accept two parameters, sfield and spatial query string?
> A better spatial query parser
> -----------------------------
>
> Key: SOLR-4242
> URL: https://issues.apache.org/jira/browse/SOLR-4242
> Project: Solr
> Issue Type: New Feature
> Components: spatial
> Reporter: David Smiley
> Fix For: 4.9, Trunk
>
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org