Does Geohash enable range based queries? It's unclear from the wiki site.
Can we do something like this
http://code.google.com/apis/base/attrs-queries.html#LocDatQuer I
would rather see SOLR go in the direction of being compatible with
GData and GBase and invent more unique things, unless they
May be if I expand on it a bit ?
Basically, I want localsolr to work with the latest trunk of the solr. And
it seems to work just fine, but the distributed version doesn't work. Even
though looking at the comments it seems the modes from solr-303 were planned
to be moved to the latest code
On Sep 18, 2008, at 9:28 AM, Jason Rutherglen wrote:
Does Geohash enable range based queries? It's unclear from the wiki
site.
yes -- if you munge the algorithm a bit, finding points within a
region is a lexographic range query.
This alteration was developed to support bounding box
On Thu, Sep 18, 2008 at 7:57 PM, outre [EMAIL PROTECTED] wrote:
So is any code from solr-303 going to merged with latest solr trunk?
I'm not sure about your problem but SOLR-303 is already committed and has
been released with Solr 1.3
I saw a post about localsolr being donated to solr. So,
[
https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-560.
Resolution: Fixed
Fix Version/s: 1.4
i'll close this for now... if we run into any issues we
[
https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632239#action_12632239
]
patrick o'leary commented on SOLR-773:
--
Hey guys
Placing both lat and long in the same
[
https://issues.apache.org/jira/browse/SOLR-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-549.
Resolution: Duplicate
Fix Version/s: 1.4
resolved with SOLR-560
Enable configurable
Too many acronyms in there. What is the WKT used for? Storing the
data? The schema? I am confused by the wikipedia text about WKT.
On Thu, Sep 18, 2008 at 11:08 AM, patrick o'leary (JIRA)
[EMAIL PROTECTED] wrote:
[
Placing both lat and long in the same field is good when used internally
The initial filtered range query should be much faster this way. Is
it possible to then extract the lat and long out of the geohash for
the narrowing portion?
On Thu, Sep 18, 2008 at 11:08 AM, patrick o'leary (JIRA)
WKT is just a standard way to describe geometry. There *many* other
options, but WKT is a simple text based one that is used in other gis
databases, including mysql and PostGIS:
http://dev.mysql.com/doc/refman/5.0/en/gis-wkt-format.html
I'm not saying we *should* use it, just that we
On Sep 18, 2008, at 11:53 AM, Jason Rutherglen wrote:
Placing both lat and long in the same field is good when used
internally
The initial filtered range query should be much faster this way. Is
it possible to then extract the lat and long out of the geohash for
the narrowing portion?
[
https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632284#action_12632284
]
Ryan McKinley commented on SOLR-773:
I'm looking over the code grant now... (thanks
[
https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632327#action_12632327
]
patrick o'leary commented on SOLR-773:
--
I believe you guys are using a branch of the
Maven Artifacts need to be signed.
--
Key: SOLR-776
URL: https://issues.apache.org/jira/browse/SOLR-776
Project: Solr
Issue Type: Bug
Affects Versions: 1.3
Reporter: Grant Ingersoll
Seems like my problem could be that qt parameter is not passed.
I see it in the createMainQuery and then after it in SolrCore execute params
do not have qt in there.
It appears that in SearchHandle:
String shardHandler = req.getParams().get(ShardParams.SHARDS_QT);
if (shardHandler == null) {
[
https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632356#action_12632356
]
Ryan McKinley commented on SOLR-773:
Thanks for the clarification...
Then I use
[
https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632358#action_12632358
]
patrick o'leary commented on SOLR-773:
--
Yep agree
Incorporate Local Lucene/Solr
[
https://issues.apache.org/jira/browse/SOLR-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated SOLR-776:
-
Attachment: SOLR-776.patch
Here's a first crack at this. The only thing I don't like is that I
Here is what I got so far.
I can add shard.qt parameter to the query string along with shards and qt,
then distributed version of my component is working.
Otherwise process function in my custom component is not called, only
default SolrCore execute.
It seems like a hacky approach to the
backword match search, for domain search etc.
-
Key: SOLR-777
URL: https://issues.apache.org/jira/browse/SOLR-777
Project: Solr
Issue Type: New Feature
Components: search
Affects
[
https://issues.apache.org/jira/browse/SOLR-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632489#action_12632489
]
Walter Underwood commented on SOLR-777:
---
You don't need backwards matching for this,
[
https://issues.apache.org/jira/browse/SOLR-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-777:
Attachment: SOLR-777-reverseStringFilter.patch
ReverseStringFilter and its factory class to reverse
[
https://issues.apache.org/jira/browse/SOLR-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632491#action_12632491
]
Koji Sekiguchi commented on SOLR-777:
-
Walter,
The domain example is a just example for
[
https://issues.apache.org/jira/browse/SOLR-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-778.
Resolution: Fixed
Fix Version/s: 1.3.1
Assignee: Shalin Shekhar
24 matches
Mail list logo
