[
https://issues.apache.org/jira/browse/SOLR-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13540996#comment-13540996
]
David Smiley commented on SOLR-4242:
------------------------------------
FYI I've been making progress on introducing a WKT parser native to Spatial4j
without it having to rely on JTS's WKT parser. WKT, being an important spatial
standard, should be had without yet another dependency. Another reason to not
use JTS is that JTS's WKT parser isn't extensible.
I've looked at a few specs and APIs out there for commonality:
# The SQL realm has an Open Geospatial Consortium (OGC) standard called [Simple
Feature Access - Part 2: SQL
Option|http://www.opengeospatial.org/standards/sfs]. [Wikipedia
says|http://en.wikipedia.org/wiki/Simple_Features] the latest version is
governed by ISO as the "SQL/MM" spec (not available freely). This is well
adopted by relational databases and is recognizable by all the "ST_" prefixes
to the SQL extensions. Quick example (I may not have this quite right):
{noformat}ST_WITHIN(myGeomField,ST_POINT(50, 50)){noformat}
# The [OGC Filter Encoding spec|http://www.opengeospatial.org/standards/filter]
has additional operators DWithin (within distance, e.g. intersects a circle),
Beyond (the opposite of DWithin), and BBOX (intersects a rect). All 3 address
shortcomings in WKT concerning lack of circles and no native rectangle shape.
The spec as a whole isn't applicable as its XML oriented however these
operators are welcome; I've seen them in other contexts; and these could be
transferrable.
# The spatial predicate portion of Common Query Language created (CQL) by OGC
(or
[ECQL|http://docs.geoserver.org/latest/en/user/filter/ecql_reference.html#spatial-predicate]
(Extended CQL) as defined by Geoserver)). Notably has DWITHIN, BBOX, and
BEYOND, as well as the usual suspects.
> A better spatial query parser
> -----------------------------
>
> Key: SOLR-4242
> URL: https://issues.apache.org/jira/browse/SOLR-4242
> Project: Solr
> Issue Type: New Feature
> Components: query parsers
> Reporter: David Smiley
> Fix For: 4.2
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
