[
https://issues.apache.org/jira/browse/SOLR-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14266665#comment-14266665
]
Ryan McKinley commented on SOLR-4242:
-------------------------------------
so what would a sample URL look like, and how do we get results out (distance,
etc)
In the example:
{code}
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))
{code}
Following something like:
http://postgis.org/docs/ST_Intersects.html
would we have multiple argument functions? or always assume a single spatial
field ``&sfield=geo`` is the first arg
{code}
&spatialfilter= ST_Intersects(geo, Circle(54.729696,-98.525391 d=10))
{code}
vs
{code}
&spatialfilter= ST_Intersects(Circle(54.729696,-98.525391 d=10))
{code}
This stuff is always complicated/messy since often want the same value in:
* filter
* boost
* return values
I guess the duplication or tagging syntax makes that better, but it still looks
ugly
> 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: [email protected]
For additional commands, e-mail: [email protected]
