You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "David Smiley (JIRA)" <ji...@apache.org> on 2015/02/04 21:38:35 UTC

[jira] [Commented] (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=14305898#comment-14305898 ] 

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

(I'm copying a comment from the review board that is better served here:)

I'm thinking instead of a param named 'wkt' we call it 'geom'.  'geom' has a generic sounding name (and familiar in other systems) whereas 'wkt' is clearly for WKT only.  By using 'geom' we can look at the first character and then parse further based on wether it's a letter (WKT) a '[' (box range query style, as seen in my heatmap patch).  Maybe even try and parse as a point.  I'm not asking you to do all this parsing check right now, just want your opinion on naming it 'geom' for the moment and I'll worry about parsing it (I'll add a method to SpatialUtils).

> 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
>
>         Attachments: SOLR-4242.patch
>
>
> 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