[
https://issues.apache.org/jira/browse/SOLR-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262270#comment-14262270
]
David Smiley commented on SOLR-4242:
------------------------------------
*For filtering*, I suggest following established standards, which means parsers
registered under these names:
st_contains, st_covers, st_intersects, st_equals, st_disjoint, st_within,
st_coveredby, st_overlaps, st_crosses. But there would be just one actual
QParser implementation that has the "SpatialOperation" instance to
differentiate. 'sfield', 'pt', 'd', and 'bbox' can all be the same as they are
now, plus 'wkt'. And it needs to support the extra parameters that SpatialArgs
has, like distErr and distErrPct. Based on my experience, I think distErrPct
should default to 0, not 2.5%.
Also, register st_dwithin which will use 'd' to buffer either 'pt', 'bbox', or
'wkt' (detect in that order) creating a query shape that is then used with
'WITHIN' SpatialOperation. As a side note, the RPT Solr field could use a
'pointsOnly' boolean so that it's smart enough to use the faster and equivalent
intersects algorithm when all indexed shapes are points. It's there on the
Lucene spatial side but not exposed to Solr yet. That optimization flag should
be a separate JIRA issue.
*For returning distance*, I suggest 'st_distance' as seen in PostGIS and
perhaps elsewhere. But I _think_ (?) this can simply be an alias, more or
less, to geofilt... LatLonType being geo, PointType being not geo, and
AbstractSpatialFieldType has a context that has isGeo() boolean. I'd like to
move away from the "geo:Intersects(...)" syntax and I'm not sure why you
brought it up here. We might add a parameter to st_distance called calc or
units that ultimately get passed on to
AbstractSpatialFieldType.getValueSourceFromSpatialArgs. Some refactoring
therein may be in order.
[~ryantxu] Is this cool with you? (or anyone else for that matter)
> 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]
