[
https://issues.apache.org/jira/browse/SOLR-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859647#comment-13859647
]
David Smiley commented on SOLR-4242:
------------------------------------
Just a small update to this issue. Spatial4j 0.4 is nearly done, and it has
it's own WKT parser. That makes it easier to have a Solr spatial query parser
that reads WKT without inadvertent dependencies on JTS which isn't (and can't
be) shipped with Solr.
My curent thinking is to simply add a new "wkt" param that is read by
\{!geofilt\} & geodist() which they could use in the absence of "pt" being
specified. The main annoyance I have with the situation is that the current
query parser "geofilt" suggest *geo*spatial (i.e. geodetic) and not a
Euclidean/Cartesian flat plane model. So might there be a new \{!sfilt\} and
sdist()? But "dist()" already exists and has strange args. I wish all these
things were thought out in advance before the existing names were chosen
because as Solr compatibility goes, it's all on stone tablets for generations
to come now. Something can be worked out though.
> 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.6
>
>
> 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.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
