Hi Guido,
Check this out: http://wiki.apache.org/solr/SpatialClustering
It captures some information on the subject.
What I really want to do is built-in heatmap-faceting but I have no time
right now.
~ David
On 1/29/14, 10:38 AM, "Guido Medina" wrote:
>Hi,
>
>Is the
hoose, once you give an approach a try.
~ David
From: Bojan Šmid [bos...@gmail.com]
Sent: Thursday, January 30, 2014 1:15 PM
To: solr-user@lucene.apache.org
Subject: Geospatial clustering + zoom in/out help
Hi,
I have an index with 300K docs with lat,lon. I
cause
you're basically hosed. Of course, why would I even want to do that? Well
I'm experimenting with ways to restore a backed-up replica to replace
existing data for the shard.
If this is unexpected behavior then I'll file a bug.
~ David
-
Author: http://www.packtp
th the hash ranges post-shard
split. Solr doesn't have an API for me to explicitly say what the hash
ranges should be on each shard (to match up with a backup). And I'm
concerned about undocumented pitfalls that may exist in manually
constructing a clusterstate.json, as another approach
ard hash ranges unless I can specify
what those hash-ranges are (but I can't). Maybe manual clusterstate.json
surgery is inevitable. This is what I raised in the other email I sent at a
similar time to the one your replied to.
~ David
-
Author: http://www.packtpub.com/apache-solr-3-en
Thanks; that is *exactly* the behavior I'm talking about. I tried to find an
existing issue before posting but missed this one somehow.
Ramkumar R. Aiyengar wrote
> There's already an issue for this,
> https://issues.apache.org/jira/browse/SOLR-5209, we were once bitten by
> the
> same issue, wh
te that parent shard
(since it's not needed anymore; it becomes inactive). I'm not sure why this
metadata is recorded because, at least after the split, I can't see why it's
pertinent to anything.
~ David
David Smiley (@MITRE.org) wrote
> Hi,
>
> I'm attempti
ction.
>- Ability to search for properties that fall outside of a polygon
You could use ³IsDisjointTo" (instead of ³Intersects²) but you¹ll
generally get faster results by negating intersects. For an example,
simply precede the first polygonal example with a ³NOT ³.
>
>Thanks
>Lee
~ David
t the fields on documents from the "from" side of
the query are not available to be returned in search results, just the "to"
side. Yup; that's true. To remedy this, you might write a Solr
SearchComponent that adds fields from the "from" side. That could be tricky
easy to port to 4x and put independently into a JAR file plug-in to Solr 4.
It’s lacking better tests, and until your question I haven’t seen interest
from users. Ryan McKinley ported it from GeoServer.
~ David
On 2/10/14, 12:53 AM, "geoport" wrote:
>Hi,
>i am using solr 4.6
ch can get abbreviated.
~ David
From: , "Jim (US-KOP)" mailto:jim.be...@hibu.com>>
Date: Wednesday, February 12, 2014 at 2:05 PM
To: "Smiley, David W." mailto:dsmi...@mitre.org>>,
"solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org>"
mailto:s
Your new code should also work, and should be equivalent.
The longer stack trace you have is of the wrapping SolrException which wraps
another exception — InvalidShapeException. You should also see the stack trace
of InvalidShapeException which should originate out of Spatial4j.
~ David
From
a handful of times. But it you can't predict how selective it
might be; it might be anything including matching a ton of stuff, then RPT
is going to be fairly consistent in its performance, and I believe generally
faster. Personally I'd take consistently fast versus an option that is
sometimes
+1 Excellent responses, Jack.
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-is-NoSQL-database-or-not-tp4120554p4120682.html
Sent from the Solr - User mailing list archive at Nabble.com.
/
trunk.
All this said, recognize this is a bit of a hack (one that works well).
There is a good chance a more ideal implementation approach is going to be
developed this year.
~ David
On 3/1/14, 2:54 PM, "Shawn Heisey" wrote:
>On 3/1/2014 11:41 AM, Thomas Scheffler wrote:
>>
This is what we use for our autosuggest field in Solr 3.4. It works for us as
you describe below.
Another problem in addition to dynamicField being declared in the wrong
place, is that you've declared that your geoFindspot field is
multi-valued. LatLonType can't handle that. Use location_rpt in the
example schema to get a multi-value capable geo field.
~ David
On 7/15/13 5:10
to numbers that
big. I don't know where the boundary is, but I doubt 10B. You could try
and see what happens. I'm working (very slowly on very little spare time)
on improving the PrefixTree implementations to scale to such large numbers;
I hope something will be available this fall.
~ D
ks out for you. Your use-case would benefit a
lot from an improved prefix tree implementation.
I don't gather how a 3rd dimension would play into this. Support for
multi-dimensional spatial is on the drawing board.
~ David
Kevin Stone wrote
> What are the dangers of trying to use a ra
ructions. Also, be sure to read more of the details on "Search" on
this wiki page in which you are advised to buffer the query shape
slightly; you didn't do this in your examples below. This is all a bit of
a hack when using a field that internally is using floating point instead
stent. I wish there was a field type that wrapped all this up so
that users wouldn't have to concern themselves with these tricky details.
I created an issue to track it:
https://issues.apache.org/jira/browse/SOLR-5072
~ David
On 7/24/13 9:26 AM, "Kevin Stone" wrote:
>I tried
;s very dense then I'll tell you how to raise the
"prefix grid scan level" to a # closer to max-levels.
(4) Do all of your searches find less than a million points, considering all
filters? If so then it's worth comparing the results with LatLonType.
~ David Smiley
Stev
d.
Nevermind on LatLonType; it doesn't support JTS/Polygons. There is
something close called SpatialPointVectorFieldType that could be modified
trivially but it doesn't support it now.
~ David
On 7/30/13 11:32 AM, "Steven Bower" wrote:
>#1 Here is my query:
>
>so
I think.
I just created an issue for it:
https://issues.apache.org/jira/browse/SOLR-5093but don't expect me to
work on it anytime soon ;-)
~ David
On 7/30/13 2:02 PM, "Steven Bower" wrote:
>I am curious why the field:* walks the entire terms list.. could this be
&g
difference. Anyway, the official/best way to ask for all data in a
field (without cheating and indexing a boolean in a different field) is
field:[* TO *].
~ David
On 7/30/13 4:44 PM, "Luis Cappa Banda" wrote:
>Hey, David,
>
>I´ve been reading the thread and I think that is on
fer size (100MB -> 200MB) and the
mergeFactor (10->20 albeit temporarily and/or issue optimize), both in
solrconfig.xml.
Changing the servlet engine won't help. Calling server.addBean(item) isn't a
problem either.
~ David
Simonian, Marta M (US SSA) wrote
> Hi,
>
> We a
From: "Steven Bower-2 [via Lucene]"
mailto:ml-node+s472066n4082569...@n3.nabble.com>>
Date: Monday, August 5, 2013 9:14 AM
To: "Smiley, David W." mailto:dsmi...@mitre.org>>
Subject: Re: Performance question on Spatial Search
So after re-feeding our data with
dDates:"Intersects(0, 2013224, 2014231, 300)"
More clear: grantRoundDates:["0 2013224" TO "2014231 300"]
~ David
zonski wrote
> Hi,
>
> I'm trying to implement date range searching using spatial features as
> per:
> http://lucene.47206
Whoops; I copy'ed your error of using commas. I meant:
Less clear: grantRoundDates:"Intersects(0 2013224 2014231 300)"
More clear: grantRoundDates:["0 2013224" TO "2014231 300"]
On 8/12/13 3:13 PM, "David Smiley (@MITRE.org)" wrote:
4.5 you can simply use geodist().
Note: if you have only one point per document, I recommend sorting by
LatLonType.
~ David
roySolr wrote
> Hello,
>
> I use the following distance sorting of SOLR
> 4(solr.SpatialRecursivePrefixTreeFieldType):
>
> fl=*,score&sort=score asc&
Roy,
How fast/slow this is is dependent on the total number of points in
documents that match the search results. If one of those documents has
1000 points but most have a handful then it isn't such a big deal. The
bigger problem is: https://issues.apache.org/jira/browse/LUCENE-4698
~
dig into the code. The
relevant part is ShapeFieldCacheDistanceValueSource.
FYI something to keep in mind:
https://issues.apache.org/jira/browse/LUCENE-4698
~ David
Hi Roy,
You'll have to calculate this client-side. I am aware of this conundrum and
I put up a TODO JIRA item for it here months ago:
https://issues.apache.org/jira/browse/SOLR-4633It actually shouldn't be
that hard to do.
~ David
roySolr wrote
> Hello David,
>
> The
This is a known limitation. From CHANGES.txt:
* SOLR-2345: Enhanced geodist() to work with an RPT field, provided that the
field is referenced via 'sfield' and the query point is constant.
(David Smiley)
The reason why that limitation is there relates to the fact that the
func
t;
Clearly wrong. Try escaping the braces with URL percent escapes, etc.
~ David
Mingfeng Yang wrote
> My solr index has a field called "author_geo" which contains the author's
> location, and when I am trying to get all docs whose author are within 10
> km of 35.0,35.0 usi
function queries for filtering, which could work but the worse-case
performance can be bad (e.g. no other filtering and tons of data).
~ David
p.s. I'm on vacation so I'm not very responsive and my replies are less
descriptive
Shishir Jain wrote
> Hi,
>
> I have a very standard
feature in the schema; please don't --
your conundrum here shows how it can be a problem. Or perhaps you used 'df'
as a request parameter -- again, same issue. When I (rarely) use 'df', I
use it as a local-param.
~ David
Mingfeng Yang wrote
> Oh, man. I have been
ences whereas RPT
has one based on weak references, which will linger longer. But I think the
likelihood of OOM is the same.
Any way, the current best option is
https://issues.apache.org/jira/browse/SOLR-5170 which I posted a few days
ago.
~ David
Billnbell wrote
> We have been using 2155 fo
Awesome!
Be sure to "watch" the JIRA issue as it develops. The patch will improve
(I've already improved it but not posted it) and one day a solution is bound
to get committed.
~ David
Jeff Wartes wrote
> This is actually pretty far afield from my original subject, but it
onent doesn't
work with any of the spatial fields. Well... it's possible to use
LatLonType and then do stats on just the latitude or just the longitude (you
should see the auto-generated fields for these in the online schema browser)
but that would unlikely be useful.
~ David
zhangquan91
Hi Chris & Jeroen,
Tonight I posted some tips on Solr's wiki on this subject:
http://wiki.apache.org/solr/SpatialClustering
~ David
Chris Atkinson wrote
> Did you get any resolution for this? I'm about to implement something
> identical.
> On 3 Jul 2013 23:03, "
/05/getting-started-with-payloads/
You can get this done. Almost anything is doable if you have sufficient
time and determination.
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com
ems to demand 'v'.
You can probably make the standard geofilt parameters top-level request
parameters and thus share them between this sort and a spatial filter in an
'fq'.
~ David
Weber wrote
> I'm trying to get score by using a custom boost and also get the distan
then you'll run out of memory while indexing.
To get started, see:
http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4
~ David
On 9/23/13 5:21 PM, "Mark Backman" wrote:
>
>
>I'm new to spatial search within solr. If I have a set of records
>containing close
pache.org/solr/SolrAdaptersForLuceneSpatial4
~ David
On 10/5/13 8:53 AM, "user 01" wrote:
>For geospatial search, I need to filter out all points outside of certain
>radius from a certain point. No need for precise results, Approximation
>will work for me! No sorting is required either. I
*Don't* use JDK 7u40, it's been known to cause index corruption and
SIGSEGV faults with Lucene: LUCENE-5212 This has not been unnoticed by
Oracle.
~ David
On 10/10/13 12:34 PM, "Guido Medina" wrote:
>2. Java version: There are huges performance winning between Java
ll this said, I do think there's room for a proposed Solr DocTransformer to
expose the DocValues value as if it were a stored field in your search
results. Actually... I wish if you explicitly ask for the field, and it's
not stored, then it would just go use docValues automatically. Th
Bill,
I responded to the issue you created about this:
https://issues.apache.org/jira/browse/SOLR-4704
In summary, use {!geofilt}.
~ David
Billnbell wrote
> I would love for the SOLR spatial 4 to support pt so that I can run # of
> results around a central point easily like in 3.6. How
e:mul(query($sortsq),69.09)&sort=query($sortsq)%20asc
I'm aware things can get ugly but can't you just use 'q' for the spatial
query that turns the distance as the score both for sorting and returning
it? It'd significantly simply this query.
~ David
-
A
rsing it somehow, so you
might do that by extending the existing spatial 4 field type.
~ David
Lance Norskog-2 wrote
> Outer distance AND NOT inner distance?
>
> On 04/12/2013 09:02 AM, kfdroid wrote:
>> We currently do a radius search from a given Lat/Long point and it works
>&
Good question. With geofilt it's kilometers.
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Easier-way-to-do-this-tp4055474p4055784.html
Sent from the Solr - User mailing list archive at Nab
field.
~ David
On 4/16/13 7:23 AM, "Guido Medina" wrote:
>Hi,
>
>I got everything in place, my polygons are indexing properly, I played a
>bit with LSP which helped me a lot, now, I have JTS 1.13 inside
>solr.war; here is my challenge:
>
>I have big polygon (A) wh
On 4/16/13 10:57 AM, "Guido Medina" wrote:
>David,
>
>I have been following your stackoverflow posts, I understand what you
>say, we decided to change the criteria and index an extra field (close
>to your suggestion), so the sorting will happen now by polygon area des
Guido,
I encourage you to try to open-source the shape-related code you have to
Spatial4j. I realize that for some organizations, that can be really
difficult.
~ David
On 4/16/13 11:55 AM, "Guido Medina" wrote:
>David,
>
> I just peak it at github, the method will es
Hi Barani,
This identical question was posed at the same time on StackOverflow, and I
answered it there already:
http://stackoverflow.com/questions/16407110/solr-4-2-solr-latlontype-type-v
s-solr-spatialrecursiveprefixtreefieldtype/16409327#16409327
~ David
On 5/6/13 12:28 PM, "bbarani&qu
ee implementation is slated to be developed this
summer as part of the Google Summer of Code (GSOC). I hadn't planned to add
N-dimensionality to the feature list. It could be a stretch-goal maybe.
https://issues.apache.org/jira/browse/LUCENE-4922
~ David
Kiran Jayakumar wrote
> Hi,
>
&g
plane (a
so-called "projection") and use the Euclidean distance. If your data is
everywhere, you may need to use multiple projections, putting them in
separate fields for each projection and then choose the best projected set
of coordinates based on your starting point.
~ David
Nicholas
using WKT
syntax via POINT). Try this:
indexType:219 AND geo:"Contains(POINT(114.078327401257
22.5424866754136))"
This will also work using lat comma lon non-WKT syntax:
indexType:219 AND geo:"Contains(22.5424866754136, 114.078327401257)"
Disclaimer: I did
n anno is an anno",
"location":["33.44844800999897,-111.98840074003","33.44844800999897,-111.98840074003","33.44844800999897,-111.98840074003",
... etc.
~ David
blmak wrote
> Hi
> I am trying to index a multivalue l
Use this reference:
http://wiki.apache.org/solr/SpatialForTimeDurations
Alexandre Rafalovitch wrote
> On Thu, May 23, 2013 at 6:47 PM, Amit Nithian <
> anithian@
> > wrote:
>> Hossman did a presentation on something similar to this using spatial
>> data
>> at a Solr meetup some months ago.
>>
>
hat won't seem special to the user, then your 2nd query below is
close. You should use 'q', not 'fq'; filter queries don't score.
~ David
Billnbell wrote
> OK here is the use case:
>
> - Someone types "Dr. Joe Smith"
> - We have the lat long of
Absolutely. Use "location_rpt" in the example schema. Do *not* use
LatLonType, which doesn't support multiValued data.
~ David Smiley
On 5/28/13 8:02 AM, "Spadez" wrote:
> currently have an item which gets imported into solr, lets call it a book
>entry.
Your client needs to know to submit the proper filter query conditionally.
It's not really a spatial issue, and I disagree with the idea to make bbox
(and all other query parsers for that matter) do nothing if not given an
expected input.
~ David
bbarani wrote
> I am using the SOLR ge
use
0.3 -- a little less. Please report back how that goes.
~ David
On 6/3/13 7:27 AM, "Chris Atkinson" wrote:
>Hi,
>I'm seeing really slow query times. 7-25 seconds when I run a simple
>filter
>query that uses my SpatialRecursivePrefixTreeFieldType field.
>
>
If it doesn't, can you conjecture why
it doesn't work based on a sample point in a document that it matched, or
a document that should have matched but didn't?
~ David
On 6/4/13 3:31 PM, "Chris Atkinson" wrote:
>Here is an example I have tried.
>
>So let
it does not require a re-index because you
are indexing points, not other shapes. This only affects other shapes.
Speaking of that slight buffer to the query shape I said in my last email,
it should be < half of maxDistErr, whatever you set that to. So use like
0.1.
~ David
Chris Atkin
Bill, I added this comment:
https://issues.apache.org/jira/browse/SOLR-2345?focusedCommentId=13685627&p
age=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#commen
t-13685627
On 6/17/13 1:50 AM, "William Bell" wrote:
>This simple feature of "sort=geodist() asc" is very powerful s
through a packaged deal with their products
http://www.metacarta.com/products-overview.htm I have no idea if you can get
it stand-alone. As of a few months ago, it was based on a version of Solr trunk
from March 2010 and they have yet to update it.
~ David Smiley
On Aug 29, 2011, at 2:27 PM
In case anyone is curious, I responded to him with a solution using either
SOLR-2155 (Geohash prefix query filter) or LSP:
https://issues.apache.org/jira/browse/SOLR-2155?focusedCommentId=13115244#comment-13115244
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search
y. Recently I ported SOLR-2155 to Solr 3x, and in a way that
does NOT require that you patch Solr. I attached it to the issue just now.
~ David Smiley
On Sep 29, 2011, at 9:37 AM, Alessandro Benedetti wrote:
> Hi all,
> I have already read the topics in the mailing list that are regarding
On Sep 29, 2011, at 5:10 PM, Alessandro Benedetti wrote:
> Sorry David, probably I misunderstood your reply, what do you mean?
>
> I'm using Lucid Work Enterprise 1.8, and, as I know , it includes geohashes
> patch.
Solr 3x, trunk, and I suspect Lucid Works Enterprise
ading to LWE 2.0
or using plain Solr.
~ David Smiley
Author: http://www.packtpub.com/solr-1-4-enterprise-search-server/
was loaded from the database.
Any suggestions on how to accomplish my problem?
Thank you!
--
Sincerely,
David Webb
? Not sure if this is
> doable.
>
> Andre
>
> David T. Webb wrote:
>> I have a normalized database schema that I have flattened out to create
>> a Solr schema. My question is with regards to searching the multivalued
>> fields that are correlated from the sub-entity in
When indexing over 2MM documents with Solr and the TikaEntityProcessor,
the indexing fails if Tika encounters an exception with one of the
documents. How can I tell Solr to keep going and just ignore the failed
documents from the Tika Processor?
Thanks.
--
Sincerely,
David Webb
teHandler2
rollback
INFO: start rollback
Nov 12, 2011 10:22:16 AM org.apache.solr.update.DirectUpdateHandler2
rollback
INFO: end_rollback
--
Sincerely,
David Webb
-Original Message-----
From: David T. Webb [mailto:david.w...@brightmove.com]
Sent: Saturday, November 12, 2011 10:08 AM
To:
Same result on onError="continue" .
Any help is appreciatedthank you.
--
Sincerely,
David Webb
-Original Message-----
From: David T. Webb [mailto:david.w...@brightmove.com]
Sent: Saturday, November 12, 2011 10:27 AM
To: solr-user@lucene.apache.org
Subject: RE: TikaEnti
Fellow Solr users,
I am proud to announce that the book "Apache Solr 3 Enterprise Search Server"
is officially published! This is the second edition of the first book on Solr
by me, David Smiley, and my co-author Eric Pugh. You can find full details
about the book, download a fr
resents my solr doc, then use SolrJ to add/update the doc.
Are there any other options. Any advice from the veterans who have been
down this road before?
Thank you.
--
Sincerely,
David Webb
,
David Webb, President
BrightMove, Inc.
http://www.brightmove.com <http://www.brightmove.com/>
320 High Tide Dr, Suite 201
Saint Augustine Beach, FL 32080
(904) 861-2396
(866) 895-6299 (Fax)
aScript template technology like jQuery templates which I've
used to great success with AJAX-Solr in place of AJAX-Solr's "Theme" junk.
Sorry if this turned into an AJAX-Solr advertisement but it is my opinion
that adopting AJAX-Solr for the role /browse has is ulti
See
https://issues.apache.org/jira/browse/SOLR-2155?focusedCommentId=13114839&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13114839
with my response following Geert-Jan's question.
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterpri
gt;...
>
> ...
>
>...
> mutliValued="false"/>
>...
>
> ...
>
> Help is welcome!
Indeed, sortMissing,etc. are used in sorting, and play no part in wether a
document matches or not. And for LatLonType, they won't do anything.
LatLonType uses the a pair of double fields under the hood, as seen in your
schema excerpt. You could put those attributes there but I don't think that
would work. I was playing around with blank values yesterday and I found that
blank values result in a distance away from the query point that is very large…
I forget what value it was but you can try yourself.
~ David Smiley
I just noticed that field compression (e.g. compressed="true") is no longer
in Solr, nor can I find why this was done. Can a committer offer an
explanation? If the reason is that it eats up CPU, then I'd rather accept
this tradeoff for a big-data yet small query volume use case.
st as what Solr has been doing, then
surely there's a bug. There's no bug. :) Admittedly, I think it was a bit of
an apples and oranges comparison but I love that quote nonetheless.
~ David Smiley
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
Hi jend,
You need an extra layer of parenthesis for MultiPolygon. I see that you opened
up with MULTIPOLYGON((… instead of MULTIPOLYGON(((… Of course ensure you
balance your parenthesis. For examples of WKT, see Wikipedia:
http://en.wikipedia.org/wiki/Well-known_text
~ David
On Nov 19
our field is strange to me; I didn't
know you could do that; are you sure you can? I suspect it is erroneous.
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Probl
Viacheslav,
Did you re-index? Clearly re-indexing is needed when changing field types.
~ David
From: Viacheslav Davidovich [via Lucene]
[ml-node+s472066n4022861...@n3.nabble.com]
Sent: Wednesday, November 28, 2012 4:42 AM
To: Smiley, David W.
Subject: Re: Problem
this
equivalent time span.
You'll need to configure the field correctly: geo="false" worldBounds="0 0
maxTime maxTime" substituting an appropriate value for maxTime based on your
unit of time (number of 15 minute intervals you need) and distErrPct="0"
(full precis
Trie numeric fields), 52 should be no problem.
I'll have to remember to refer back to this email on the approach if I
create a field type that wraps this functionality.
~ David
britske wrote
> Again, this looks good!
> Geert-Jan
>
> 2012/12/8 David Smiley (@MITRE.org) [via Luce
Maybe it would? I don't completely get your drift. But you're talking about a
user writing a bunch of custom code to build, save, and query the bitmap
whereas working on top of existing functionality seems to me a lot more
maintainable on the user'
It's plausible to see it generalized, but I don't think
it'll scale well beyond 4-5 dimensions. I recall a research paper talking
about multi-dimensional numeric indexes seriously breaking down at about 6.
~ David
From: Mikhail Khludnev [vi
very small rectangles (relative to your grid
resolution -- 1 meter in your case). Using distErrPct=0 in the query is
safe, on the other hand.
Cheers,
David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.4720
(and configure some other attributes)
such that you are using standard planar math, not geodetic. Then your query
shape would appear to work correctly but IMO its misleading over the first
option (draw an ellipse, not a circle). The circle misleads the user; it
mislead you.
~ David
Javier Mol
The indexed="true" side is quite efficient. The stored="true" side -- not so
much, but the strings you have here are pretty small and I wouldn't worry
about it. Solr 4.1 (unreleased) does a great job here and compresses all
the stored field data across documents.
~ D
and doesn't relinquish
its resources (i.e. on commit) as quickly as it should. I know what it's
problems are but I have been quite busy.
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/modeling-prices-based-on-daterange-using-multipoints-tp4026011p4026151.html
Sent from the Solr - User mailing list archive at Nabble.com.
britske wrote
> Hi David,
>
> Yeah interesting (as well as problematic as far is implementing) use-case
> indeed :)
>
> 1. You mention "there are no special caches / memory requirements inherent
> in this.". For a given user-query this would mean all hotels would
>> confident the number of matching documents (hotels) is going to be
>> small-ish, say less than a couple hundred, then you could simply sort it
>> client-side. You'd have to get back all the values, or maybe write a
>> DocTransformer to
Solr 4 spatial
fields. I created an issue, SOLR-4230 to track this. I never got around to
doing this before because it wasn't strictly necessary to use the new
fields, but it is of course a nice-to-have.
~ David
mladen micevic wrote
> Hi,
> I went through example for spatial se
A standard servlet filter
* A search component
* A subclass of SearchHandler
The search component would probably be easy and most appropriate as you
could register it clearly in solr's config file vs. semi-hidden in web.xml
~ David
mladen micevic wrote
> Thank you David for your quick
1101 - 1200 of 1471 matches
Mail list logo
