You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Grant Ingersoll (JIRA)" <ji...@apache.org> on 2009/11/16 20:42:39 UTC
[jira] Created: (SOLR-1568) Implement Cartesian Tier Filter
Implement Cartesian Tier Filter
-------------------------------
Key: SOLR-1568
URL: https://issues.apache.org/jira/browse/SOLR-1568
Project: Solr
Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 1.5
Given an index with cartesian tiers, we should be able to pass in a filter query that takes in the field name, lat, lon and radius and produces an appropriate Filter for use by Solr. Note, contrib/spatial has such a filter, so it may just be that we need to hook in a QParserPlugin to handle it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796249#action_12796249 ]
Grant Ingersoll commented on SOLR-1568:
---------------------------------------
Here's the thing I keep coming back to with this issue. For all the field types other than SpatialTile (Cartesian Tier), filters are already easily creatable. It seems odd to have to write this special QParserPlugin that has all this syntax support, etc. to create filters for all of the other cases beside the spatial tile. For instance, pure radial distance filtering is easily handled through the FunctionRangeQParserPlugin and the various distance functions. In fact, going this route is more convoluted for those cases b/c now you need a way to pass in what distance function you want to use.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1568) Implement Spatial Filter
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843902#action_12843902 ]
Chris A. Mattmann edited comment on SOLR-1568 at 3/11/10 4:28 AM:
------------------------------------------------------------------
OK, this guy compiles, and I tried to guess in a couple areas (e.g., please look at Haversine) where variables were missing. One nice thing you can take out of this is the normalize functions for lat and lon in DistanceUtils -- those will probably be generally useful.
I'll also look to bring some of this over to SIS, as we start to flesh it out.
I saw an error during unit tests in org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest, but it seems unrelated (so suspicious -- is this a real bug?):
{noformat}
[chipotle:solr/build/test-results] mattmann% more TEST-org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest.txt
Testsuite: org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
Testcase: testContentStreamRequest took 0.003 sec
Caused an ERROR
Forked Java VM exited abnormally. Please note the time in the report does not re
flect the time until the VM exit.
junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please n
ote the time in the report does not reflect the time until the VM exit.
[chipotle:solr/build/test-results] mattmann%
{noformat}
was (Author: chrismattmann):
OK, this guy compiles, and I tried to guess in a couple areas (e.g., please look at Haversine) where variables were missing. One nice thing you can take out of this is the normalize functions for lat and lon in DistanceUtils -- those will probably be generally useful.
I'll also look to bring some of this over to SIS, as we start to flesh it out.
I saw an error during unit tests in org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest, but it seems unrelated (so suspicious -- is this a real bug?):
[chipotle:solr/build/test-results] mattmann% more TEST-org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest.txt
Testsuite: org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
Testcase: testContentStreamRequest took 0.003 sec
Caused an ERROR
Forked Java VM exited abnormally. Please note the time in the report does not re
flect the time until the VM exit.
junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please n
ote the time in the report does not reflect the time until the VM exit.
[chipotle:solr/build/test-results] mattmann%
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java, SOLR-1568.Mattmann.031010.patch.txt, SOLR-1568.patch, SOLR-1568.patch
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796299#action_12796299 ]
Grant Ingersoll commented on SOLR-1568:
---------------------------------------
bq. Are we filtering by bounding box or by distance, sorting by distance, or boosting by distance?
I see this as a filtering only issue. To me, all the other capabilities other than filtering by a Spatial Tile Field are already covered through normal Solr capabilities, so I don't see much benefit to inventing new syntax and more code to maintain even if it is slightly easier for the app designer to consume.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "patrick o'leary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795014#action_12795014 ]
patrick o'leary commented on SOLR-1568:
---------------------------------------
I would be concerned that this starts making it more complex for users to implement.
we're going from
{code}
&lat=49.45&long=-77.33&radius=10
{code}
to :
{code}
&fq={!sfilt p=49.32,-79.0 f=location dist=20}
{code}
What do you get out of it?
I remember FAST tm, a subsidiary of microsoft (think I got all that right), used have
{code}
geo_location:{-79.0,49.32,10)
{code}
And that was unnecessarily awkward to explain to folks, again because different folks viewed GIS calculations in different manors
Remember GIS is often like an Abbot and Costello sketch, who's on first, lat or long?
Keep it simple, and please don't obscure it
--1
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796485#action_12796485 ]
Grant Ingersoll commented on SOLR-1568:
---------------------------------------
For those who only want pure radial search, it is the only way, scalable or not, unless I'm missing something.
As I see, it there are several options for filtering that already work out of the box and that someone may want to use:
1. Radial distance as above
2. Range query (i.e. bounding box)
The one remaining that isn't implemented is the tile stuff.
Now, obviously, we can provide tools to make these slightly easier to consume. I've already prototyped most of it, but in doing so, I just couldn't shake the sense that it is a waste of time for anything but the tile stuff and that it hides too much in terms of what the tradeoffs are going to be. I just think it is easy enough for an app designer to use their existing toolbox (#1 and #2) while throwing in one more lightweight, easy to use new tool (tile support.)
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843883#action_12843883 ]
Chris A. Mattmann commented on SOLR-1568:
-----------------------------------------
Hey Grant:
I'll take a look at your latest patch and try to iterate on it (at least make sure it compiles, and take a pass with javadocs, run the unit tests, etc.). Should have something up in the next few hours.
Cheers,
Chris
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java, SOLR-1568.patch, SOLR-1568.patch
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Grant Ingersoll updated SOLR-1568:
----------------------------------
Attachment: SOLR-1568.patch
A totally NON WORKING patch. The only thing really defined is the interface, per earlier discussions. I doubt it even compiles. I'm putting it up here for something to talk about eventually.
I'd like to achieve at least 2 things:
1. Good defaults for the filters based on the FieldType
2. Pluggable implementations for the filters based on the FieldType. I've seen enough of these now that just hardcoding bounding box to the PointType is not sufficient. I think we need a bit looser coupling. I have that now as an abstract class called SpatialFilterable (will rename to SpatialFilter) which my plan is to have the QParserPlugin load up from the Solr Config. This way, if people want to implement there own, they can
As I said, this totally NON WORKING.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java, SOLR-1568.patch
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1568) Implement Cartesian Tier Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Grant Ingersoll updated SOLR-1568:
----------------------------------
Attachment: CartesianTierQParserPlugin.java
Here's the start of a QParserPlugin for this functionality. It's just the Java code and is not integrated with Solr yet.
It works using the Lucene spatial stuff, but it should not be committed at this point, b/c I want to make it work with Tier based field types so that the end user need not even think about what the field name structure is (i.e. tier_).
Can query with it as something like: {!tier x=32 y=-79 dist=20 prefix=tier_}. If you did want to use it, you would need to add it to your solrconfig.xml.
> Implement Cartesian Tier Filter
> -------------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with cartesian tiers, we should be able to pass in a filter query that takes in the field name, lat, lon and radius and produces an appropriate Filter for use by Solr. Note, contrib/spatial has such a filter, so it may just be that we need to hook in a QParserPlugin to handle it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796352#action_12796352 ]
Ryan McKinley commented on SOLR-1568:
-------------------------------------
{quote}
could be written as
{code}
&fq={!sfilt f=location}
&p=49,-77
&d=1000
{code}
{quote}
Jeez -- I had no idea... then I think (most?) cases are taken care of...
With this, a handler could be defined with the default param: 'fq={!sfilt f=location}' and the 'end user' could simply call:
&p=49,-77&d=1000
never needing to grock the local-params/function syntax.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "patrick o'leary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796524#action_12796524 ]
patrick o'leary commented on SOLR-1568:
---------------------------------------
bq. A smart spatial filter, at a minimum, only does the distance calculation for those documents that lie within the bounding box. That's the main point to the bounding box. I had assumed this is what Patrick's local-solr already did?
It's a little more contrived - I actually executed the lucene query as part of the filter,
* Bounded box
* Text query standard query
* And bitset
* Pass in that bitset to radial filter to only calculate distances of both text search, and bounded box
Thus only doc's matching the query within the bounding box have their distances calculated.
Check out
DistanceQueryBuilder
{code}
public Filter getFilter(Query query) {
// Chain the Query (as filter) with our distance filter
if (distanceFilter != null) {
distanceFilter.reset();
}
QueryWrapperFilter qf = new QueryWrapperFilter(query);
return new ChainedFilter(new Filter[] {qf, filter},
ChainedFilter.AND);
}
public Query getQuery(Query query){
return new ConstantScoreQuery(getFilter(query));
}
{code}
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796282#action_12796282 ]
Grant Ingersoll commented on SOLR-1568:
---------------------------------------
Keep in mind distance functions are about more than just lat/lon, although there is no reason why we can't support both.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851154#action_12851154 ]
Yonik Seeley commented on SOLR-1568:
------------------------------------
Things are looking good! I like the SpatialQueryable interface and the SpatialOptions class, which should allow us to use an interface and slowly migrate by changing SpatialOptions w/o breaking back compat. I haven't looked much at the implementations of geohash or tier stuff yet - more the basic point type and user interfaces.
High Level Interface:
* units: if we do specify units, more standard abbreviations would probably be "km" and "mi" rather than "K" and "M"
* just standardizing on units might be the best option, as I think it would be simplest to use (and client conversion is trivial)
* Examples of confusion and complications that "units" can case:
** When filtering and sorting, what happens if there is a units mismatch?
** does "units" apply to the optional "radius" argument?
** what are the units for calculated and returned distances? People might assume that because they filtered using "km", that a distance sort or other function queries would be in "km" or "mi"
** if returned distances can be in any unit, it complicates client code that may not know the exact request, and hence the units
** boosting or adding in a function of distance to the relevancy score: changing the units would unexpectedly change how this worked.
* fl should probably just be "f" (fl stands for "field list")? Update: looking at the code again, it seems that the idea is to allow specifying lat,lon separately too?
we have point and latlon fields for this though... shouldn't it always just be a single field?
* "radius" parameter is likely to confuse people... (i.e. I specified radius=1 because I wanted to search within a 1 mile radius), while in reality this represents the radius of the earth. Since 99.99% of people should not use this parameter, perhaps rename to "planet_radius" or "sphere_radius"?
* Seems like it would be really nice to be able to do both distance filtering and bounding box filtering.
** Distance filtering would normally be implemented as a combination of a bounding box + distance calculations for points within that box.
** Distance filtering could get even more efficient in the future... we could also calculate an "inner" box within the bounding box.
Any points in the inner box would be guaranteed to be less than the distance, hence no need to calculate exact distance.
** It looks like the current implementation(s) does bounding box only?
Code:
* SpatialFilterQParserPlugin should probably just be a standard parser - no need to explicitly register in solrconfig.xml
** oops, I see that this is already done under "sfilt" currently - so it can just be removed from solrconfig.xml
** is there a reason why it's ResourceLoaderAware?
* for the implementation that creates a single range query for lattitude and a single one for longitude: we actually need multiple ranges (or multiple boxes) to handle boxes that cross the 180 meridian, as well as boxes that cross the poles.
Tests:
* SpatialQParserPluginTest - it might be nice (and easier to maintain) if this were slightly higher level - test that the produced filter successfully filters out points outside the box, rather than testing that a specific type of query is returned (currently the test does "query instanceof NumericRangeQuery").
Example schema:
* before release, we'll prob want to cut down the spatial field types to just one recommended one that people can use w/o having to figure out the difference between all the types. OK to keep multiple in during development though... makes for easier ad hoc testing.
With an eye toward the end game, here's an example of what we might want to shoot for:
{code}
// use case: filter by distance, sort by distance
&point=49,-77
&dist=1000
&fq={!sfilt fl=location}
&sort=dist($point,location) asc
// we can't quite do this yet with function query syntax, but it seems nice?
// use case: filter by distance, boost relevance score by a function of distance
&point=49,-77
&dist=1000
&fq={!sfilt fl=location}
&boost=recip(dist($point,location),1,$dist,$dist))
// "boost" is an edismax param.
// function will yield values between .5 and 1
{code}
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java, SOLR-1568.Mattmann.031010.patch.txt, SOLR-1568.patch, SOLR-1568.patch, SOLR-1568.patch, SOLR-1568.patch
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804759#action_12804759 ]
Grant Ingersoll commented on SOLR-1568:
---------------------------------------
bq. And how would that be specified out of the box?
It's just a simple range query: point:[33.5,-80 TO 35.0,-81] or some other similar thing. The point is that Solr already supports this, so I don't see a lot to be gained by actually doing it in Solr.
bq. (example please?) You're not suggesting that be delegated to the user do you? That's very hard, very field specific, and will often result in multiple range queries, not one.
It doesn't strike me as that hard, but perhaps I'm missing something. Many times this stuff is automatically generated by a user clicking on a map or via other, application side calculations.
bq. I actually executed the lucene query as part of the filter
That's interesting. So, you end up calculating it twice, once for scoring and once for filtering? I can see why that would speed things up.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796308#action_12796308 ]
Grant Ingersoll commented on SOLR-1568:
---------------------------------------
Also, in all of these proposals, how do we intend to specify what distance calculation to use? Which is another reason for not going down the path of a generic QParser for this, since if we use the FunctionRangeQParser, it's inherent in the passing in of the function.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796478#action_12796478 ]
Yonik Seeley commented on SOLR-1568:
------------------------------------
While it's nice that this works (to double-check results, etc), this isn't particularly scalable as it calculates the distance (the expensive part) for every document. Or are you suggesting some other kind of implementation in conjunction with this syntax?
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796280#action_12796280 ]
Ryan McKinley commented on SOLR-1568:
-------------------------------------
I'm torn on this also...
The function query syntax (and all local params really) are a bit cryptic. When I look into it though they are really powerful, and i see an advantage to having that level of control. (and it works in solr now)
I wonder if there is a simple way to add query rewriting that would convert:
&lat=49&long=-77&radius=10
to:
&fq={!sfilt p=49,-77 f=location dist=10}
Perhaps a RequestRewrite component?
I doubt adding something like http://tuckey.org/urlrewrite/ would work off-the-shelf, but it could go a long way to hide the ugly innards for a simple case like this, yet still allow the power of the function query syntax.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Cartesian Tier Filter
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779670#action_12779670 ]
Chris A. Mattmann commented on SOLR-1568:
-----------------------------------------
bq. So, in the end, my decision was based on the fact that the code for it was pretty simple and wouldn't be a big deal to fix. Longer term, I will fix the issue in trunk of Lucene and then over time Solr can adapt to use that once we are on 3.x
+1 on this. My group at JPL has gone the route of trying to co-develop Lucene and SOLR patches for this without much success. I think the best way is to maintain the code pieces in SOLR, try and flow them back into Lucene (those updates needed there), and then flow back into SOLR as releases in Lucene-ville are made.
> Implement Cartesian Tier Filter
> -------------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with cartesian tiers, we should be able to pass in a filter query that takes in the field name, lat, lon and radius and produces an appropriate Filter for use by Solr. Note, contrib/spatial has such a filter, so it may just be that we need to hook in a QParserPlugin to handle it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796491#action_12796491 ]
Yonik Seeley commented on SOLR-1568:
------------------------------------
bq. For those who only want pure radial search, it is the only way, scalable or not, unless I'm missing something.
A smart spatial filter, at a minimum, only does the distance calculation for those documents that lie within the bounding box. That's the main point to the bounding box. I had assumed this is what Patrick's local-solr already did?
Although I do think it's a good idea to also allow a user to specify *only* a bounding box if they don't want to pay the price for the distance calculation at all.
bq. 2. Range query (i.e. bounding box)
And how would that be specified out of the box? (example please?) You're not suggesting that be delegated to the user do you? That's very hard, very field specific, and will often result in multiple range queries, not one.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796476#action_12796476 ]
Grant Ingersoll commented on SOLR-1568:
---------------------------------------
{code}
fq={!frange l=0 u=400}hsin(0.57, -1.3, lat_rad, lon_rad, 3963.205)
{code}
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852009#action_12852009 ]
Grant Ingersoll commented on SOLR-1568:
---------------------------------------
Thanks for the thorough feedback, Yonik. Some thoughts inline.
{quote}
# units: if we do specify units, more standard abbreviations would probably be "km" and "mi" rather than "K" and "M"
# just standardizing on units might be the best option, as I think it would be simplest to use (and client conversion is trivial)
# Examples of confusion and complications that "units" can case:
* When filtering and sorting, what happens if there is a units mismatch?
* does "units" apply to the optional "radius" argument?
* what are the units for calculated and returned distances? People might assume that because they filtered using "km", that a distance sort or other function queries would be in "km" or "mi"
* if returned distances can be in any unit, it complicates client code that may not know the exact request, and hence the units
* boosting or adding in a function of distance to the relevancy score: changing the units would unexpectedly change how this worked.
{quote}
Agreed on abbreviations. The units mostly come into play with picking the radius. Lucene spatial seems to assume miles in a lot of places, but I imagine this is actually kind of silly given that the majority of the world uses metric. I guess ideally, I want people to be able to save on conversion, but it's probably silly to try to engineer that in. I suppose we could have a whole discussion on whether to assume English or Metric. I'm still on the fence.
{quote}
fl should probably just be "f" (fl stands for "field list")? Update: looking at the code again, it seems that the idea is to allow specifying lat,lon separately too?
we have point and latlon fields for this though... shouldn't it always just be a single field?
{quote}
I was thinking that I might support multiple fields for those people who are already indexing lat/lon as two fields. That way they could get the benefits of this code w/o re-indexing. That being said, it is still unimplemented and I'm not sure how to implement it.
{quote}
"radius" parameter is likely to confuse people... (i.e. I specified radius=1 because I wanted to search within a 1 mile radius), while in reality this represents the radius of the earth. Since 99.99% of people should not use this parameter, perhaps rename to "planet_radius" or "sphere_radius"?
{quote}
sphere_radius it is.
{quote}
Seems like it would be really nice to be able to do both distance filtering and bounding box filtering.
* Distance filtering would normally be implemented as a combination of a bounding box + distance calculations for points within that box.
* Distance filtering could get even more efficient in the future... we could also calculate an "inner" box within the bounding box.
Any points in the inner box would be guaranteed to be less than the distance, hence no need to calculate exact distance.
* It looks like the current implementation(s) does bounding box only?
{quote}
LatLonType will implement bounding box + distance filtering. I imagine people will want to override the FieldTypes for their specifics on creating the Filter. Right now, PointType really is designed for a rectangular coordinate system. Most people will likely use LatLonType, which will be geared towards spherical (i.e. Earth). But, agreed, we will be able to optimize over time.
bq. is there a reason why it's ResourceLoaderAware?
Artifact of earlier design. Removed.
bq. SpatialQParserPluginTest
Already changed and "higher" level, just haven't posted the patch. I actually renamed it too.
bq. oops, I see that this is already done under "sfilt" currently - so it can just be removed from solrconfig.xml
Done.
bq. before release, we'll prob want to cut down the spatial field types to just one recommended one that people can use w/o having to figure out the difference between all the types. OK to keep multiple in during development though... makes for easier ad hoc testing.
For now, I have a comment in the schema that says something to the effect that you likely will not need all of these. I think this gets to a bigger discussion we should have on dev@ about what the example should be. I'd like the example to be more self contained and more self explanatory. We could have a light version and a full featured one.
bq. With an eye toward the end game, here's an example of what we might want to shoot for:
Agreed the syntax is nice. I don't think I will do that as part of this patch. Otherwise, I think all of those use cases are covered.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java, SOLR-1568.Mattmann.031010.patch.txt, SOLR-1568.patch, SOLR-1568.patch, SOLR-1568.patch, SOLR-1568.patch
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1568) Implement Spatial Filter
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris A. Mattmann updated SOLR-1568:
------------------------------------
Attachment: SOLR-1568.Mattmann.031010.patch.txt
OK, this guy compiles, and I tried to guess in a couple areas (e.g., please look at Haversine) where variables were missing. One nice thing you can take out of this is the normalize functions for lat and lon in DistanceUtils -- those will probably be generally useful.
I'll also look to bring some of this over to SIS, as we start to flesh it out.
I saw an error during unit tests in org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest, but it seems unrelated (so suspicious -- is this a real bug?):
[chipotle:solr/build/test-results] mattmann% more TEST-org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest.txt
Testsuite: org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
Testcase: testContentStreamRequest took 0.003 sec
Caused an ERROR
Forked Java VM exited abnormally. Please note the time in the report does not re
flect the time until the VM exit.
junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please n
ote the time in the report does not reflect the time until the VM exit.
[chipotle:solr/build/test-results] mattmann%
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java, SOLR-1568.Mattmann.031010.patch.txt, SOLR-1568.patch, SOLR-1568.patch
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831611#action_12831611 ]
Grant Ingersoll commented on SOLR-1568:
---------------------------------------
Actually, in thinking some more about this, it seems like it is just as easy to extend the FieldType to override a method as it is to invent new syntax to support configuring these things. I'm going to go that route, which is, of course, what Yonik suggested all along :-)
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java, SOLR-1568.patch
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Cartesian Tier Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779662#action_12779662 ]
Grant Ingersoll commented on SOLR-1568:
---------------------------------------
Honestly, it's a bit tricky and I'm not sure how best to resolve it (keep in mind that I'm not recommending the above piece be committed). There are a few pieces that can be improved in the CartesianShapeFilter to perform better (I still need to fix them in Lucene) but if I go that route, then I need to update the Lucene JARs associated with that in Solr. I can't really do that, b/c that likely means one of two things:
1. Patching the 2.9.1 branch and packaging up that JAR for Solr or wait for a 2.9.2 release from Lucene which isn't likely.
2. Patching trunk and including it. This would be a huge undertaking for Solr
So, in the end, my decision was based on the fact that the code for it was pretty simple and wouldn't be a big deal to fix. Longer term, I will fix the issue in trunk of Lucene and then over time Solr can adapt to use that once we are on 3.x
> Implement Cartesian Tier Filter
> -------------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with cartesian tiers, we should be able to pass in a filter query that takes in the field name, lat, lon and radius and produces an appropriate Filter for use by Solr. Note, contrib/spatial has such a filter, so it may just be that we need to hook in a QParserPlugin to handle it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Cartesian Tier Filter
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779726#action_12779726 ]
Ryan McKinley commented on SOLR-1568:
-------------------------------------
| I think the best way is to maintain the code pieces in SOLR, try and flow them back into Lucene (those updates needed there), and then flow back into SOLR as releases in Lucene-ville are made.
+1
> Implement Cartesian Tier Filter
> -------------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with cartesian tiers, we should be able to pass in a filter query that takes in the field name, lat, lon and radius and produces an appropriate Filter for use by Solr. Note, contrib/spatial has such a filter, so it may just be that we need to hook in a QParserPlugin to handle it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Grant Ingersoll updated SOLR-1568:
----------------------------------
Attachment: SOLR-1568.patch
More progress. Don't think it even compiles, but putting it up for others to start to look at and for me to get it off of my hard drive. Just going down the FieldType route.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java, SOLR-1568.patch, SOLR-1568.patch
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Lance Norskog (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851726#action_12851726 ]
Lance Norskog commented on SOLR-1568:
-------------------------------------
Dublin Core includes conventions for encoding points & "rectangles":
[DCMI Point Encoding Scheme|http://dublincore.org/documents/dcmi-point/]
[DCMI Box Encoding Scheme|http://dublincore.org/documents/dcmi-box/]
These are maybe too high-level for the spatial tools, but are an interesting packaging of metadata & coordinates.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java, SOLR-1568.Mattmann.031010.patch.txt, SOLR-1568.patch, SOLR-1568.patch, SOLR-1568.patch, SOLR-1568.patch
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796457#action_12796457 ]
Yonik Seeley commented on SOLR-1568:
------------------------------------
bq. since if we use the FunctionRangeQParser, it's inherent in the passing in of the function.
It's not clear exactly what you're proposing - can you give an example request so we can compare?
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796348#action_12796348 ]
Yonik Seeley commented on SOLR-1568:
------------------------------------
bq. Also, in all of these proposals, how do we intend to specify what distance calculation to use?
IMO, the user shouldn't have to. The vast majority of users want "normal" spatial search... fast yet good enough. They won't know the details and won't want to know (except perhaps that it's accurate to x meters).
For those super-advanced users that wish to specify their own distance function, we could allow an optional parameter on sfilt that specifies an arbitrary function.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (SOLR-1568) Implement Cartesian Tier Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on SOLR-1568 started by Grant Ingersoll.
> Implement Cartesian Tier Filter
> -------------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
>
> Given an index with cartesian tiers, we should be able to pass in a filter query that takes in the field name, lat, lon and radius and produces an appropriate Filter for use by Solr. Note, contrib/spatial has such a filter, so it may just be that we need to hook in a QParserPlugin to handle it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Cartesian Tier Filter
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779543#action_12779543 ]
Chris Male commented on SOLR-1568:
----------------------------------
Hi,
I'm just wondering why you have created your own TierFilter instead of using the CartesianShapeFilter from the Lucene spatial contrib?
Cheers
> Implement Cartesian Tier Filter
> -------------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with cartesian tiers, we should be able to pass in a filter query that takes in the field name, lat, lon and radius and produces an appropriate Filter for use by Solr. Note, contrib/spatial has such a filter, so it may just be that we need to hook in a QParserPlugin to handle it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831140#action_12831140 ]
Grant Ingersoll commented on SOLR-1568:
---------------------------------------
So, one of the things I'm not sure on here is how best to associate the filtering information with the FieldType. On the one hand, we could have a base class or a small interface that defines the filter call back on the FieldType and then the PointType and other spatial FieldTypes could implement/extend that capability. Going this approach means that if someone wants to provide a different way of filtering for a FieldType, they would have to implement a derived class overriding the method. For instance, on the PointType, the base implementation may be to just generate a range query for each field based on distance. However, if someone wanted a different approach, they would then have to extend PointType and register a whole other FieldType, let's call it NewFilterPointType.
An alternative approach would be to separate the filter calculation in a different class and then somehow associate it with the FieldType (maybe as a map). I've started this to some extent on the last NON WORKING patch, but don't feel great about the actual implementation just yet. In the case above, Solr would provide a default implementation (automatically registered) and then it could be overridden by configuring in solrconfig.xml.
I'm also open to other suggestions. I still am pretty open to taking baby steps here by defining the API as Yonik described above (more or less, see my last patch) but only providing a single implementation right now for the Spatial Tile Field Type (Cartesian Tier).
Thoughts and suggestions welcome? I'd like to get something in Solr pretty soon.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java, SOLR-1568.patch
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835347#action_12835347 ]
Yonik Seeley commented on SOLR-1568:
------------------------------------
I'm not a fan of optional units... I think we should just standardize on something (meters perhaps) and stick with it.
This is a programmatic API, not a user API, and it's not a hardship for a programmer to convert to whatever units are appropriate.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java, SOLR-1568.patch
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Grant Ingersoll updated SOLR-1568:
----------------------------------
Attachment: SOLR-1568.patch
Here's what I have in my trunk now. Chris, haven't had a chance to work on yours, but am going to look today, as well as move over to the new trunk. Just putting this up here in case I do something stupid on my local drive.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java, SOLR-1568.Mattmann.031010.patch.txt, SOLR-1568.patch, SOLR-1568.patch, SOLR-1568.patch
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Grant Ingersoll updated SOLR-1568:
----------------------------------
Description:
Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
The interface _could_ look like:
{code}
&fq={!sfilt dist=20}location:49.32,-79.0
{code}
or it could be:
{code}
&fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
{code}
or:
{code}
&fq={!sfilt p=49.32,-79.0 f=location dist=20}
{code}
or:
{code}
&fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
{code}
was:Given an index with cartesian tiers, we should be able to pass in a filter query that takes in the field name, lat, lon and radius and produces an appropriate Filter for use by Solr. Note, contrib/spatial has such a filter, so it may just be that we need to hook in a QParserPlugin to handle it.
Summary: Implement Spatial Filter (was: Implement Cartesian Tier Filter)
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796289#action_12796289 ]
Yonik Seeley commented on SOLR-1568:
------------------------------------
The examples are not of equivalent power. What field are we working off of? Are we filtering by bounding box or by distance, sorting by distance, or boosting by distance?
Further, given that query parsers default to grabbing global params if local ones aren't specified this
{code}
&fq={!sfilt p=49,-77 d=1000 f=location}
{code}
could be written as
{code}
&fq={!sfilt f=location}
&p=49,-77
&d=1000
{code}
Which I assumed people would do anyway to make it easier for clients to construct queries and do filtering + sorting w/o repeating parameters.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1568) Implement Spatial Filter
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Grant Ingersoll updated SOLR-1568:
----------------------------------
Attachment: SOLR-1568.patch
Compiles and is much closer, but still doesn't work exactly right. Currently focusing on filtering for LatLonType. Haven't tested filter creation for the other types yet. Need to write unit tests.
> Implement Spatial Filter
> ------------------------
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java, SOLR-1568.Mattmann.031010.patch.txt, SOLR-1568.patch, SOLR-1568.patch, SOLR-1568.patch, SOLR-1568.patch
>
>
> Given an index with spatial information (either as a geohash, SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be able to pass in a filter query that takes in the field name, lat, lon and distance and produces an appropriate Filter (i.e. one that is aware of the underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.