do I boost the score of the
matching documents based on geodist? How will I get the geodist based on
the closest matching lat-long point.
Thanks in advance.
--
Varun Gupta
On Mon, Mar 17, 2014 at 7:27 PM, Smiley, David W. dsmi...@mitre.org
wrote:
Absolutely. The most straight-forward approach
Absolutely. The most straight-forward approach is to use the default
query parser comprised of OR clauses of geofilt query parser based
clauses. Another way to do it in Solr 4.7 that is probably faster is to
use WKT with the custom “buffer extension:
myLocationRptField:BUFFER(MULTIPOINT(x y, x
You need to either quote your query (after the colon, and another at the
very end), or escape any special characters, or use a different query
parser like “field”. I prefer to use the field query parser:
{!field f=loc}Intersects(POLYGON(...
~ David
On 3/6/14, 10:52 AM, leevduhl
On 3/10/14, 6:45 AM, Javi javiersangra...@mitula.com wrote:
Hi all.
I need your help! I have read every post about Spatial in Solr because I
need to check if a point (latitude,longitude) is inside a Polygon.
/**/
/* 1. library */
/**/
(1) I use jts-1.13.jar and
On 3/10/14, 12:12 PM, Smiley, David W. dsmi...@mitre.org wrote:
c) I tried no WKT format by adding a comma and using longitude,latitude
doc
arr name=LOCATION
str40.442179,-3.69278/str
/arr
/doc
That is *wrong*. Remove the comma and it will then be okay. But again,
see my
On 3/10/14, 12:56 PM, javinsnc javiersangra...@mitula.com wrote:
/*/
/* Document contents */
/*/
I have tried with 3 different content for my documents (lat-lon refers
to
Madrid, Spain):
Um…. Just to be absolutely sure, are you adding the data in
Hi Steven,
Set distErrPct to 0 in order to get non-point shapes to always be as accurate
as maxDistErr. Point shapes are always that accurate. As long as you only
index points, not other shapes (you don’t index polygons, etc.) then distErrPct
of 0 should be fine. In fact, perhaps a future
The main reference for this approach is here:
http://wiki.apache.org/solr/SpatialForTimeDurations
Hoss’s illustrations he developed for the meetup presentation are great.
However, there are bugs in the instruction — specifically it’s important
to slightly buffer the query and choose an
.
~ David
From: Beale, Jim (US-KOP) jim.be...@hibu.commailto:jim.be...@hibu.com
Date: Wednesday, February 12, 2014 at 2:05 PM
To: Smiley, David W. dsmi...@mitre.orgmailto:dsmi...@mitre.org,
solr-user@lucene.apache.orgmailto:solr-user@lucene.apache.org
solr-user@lucene.apache.orgmailto:solr-user
: Beale, Jim (US-KOP) jim.be...@hibu.commailto:jim.be...@hibu.com
Date: Wednesday, February 12, 2014 at 5:21 PM
To: Smiley, David W. dsmi...@mitre.orgmailto:dsmi...@mitre.org,
solr-user@lucene.apache.orgmailto:solr-user@lucene.apache.org
solr-user@lucene.apache.orgmailto:solr-user
Hi,
BBoxStrategy is still only in “trunk” (not the 4x branch). And
furthermore… the Solr portion, a FieldType, is over in
Spatial-Solr-Sandbox —
https://github.com/ryantxu/spatial-solr-sandbox/blob/master/LSE/src/main/ja
va/org/apache/solr/spatial/pending/BBoxFieldType.java It should be quite
Hi Lee,
On 2/3/14, 1:59 PM, leevduhl ld...@corp.realcomp.com wrote:
We have a public property search site that we are looking to replace the
back
end index server on and we are looking at Solr as a possible replacement
(ElasticSearch is another possibility).
Both should work equally well.
One
Hi Bojan.
You've got some good ideas here along the lines of some that others have tried.
I've through together a page on the wiki about this subject some time ago that
I'm sure you will find interesting. It references a relevant stack-overflow
post, and also a presentation at DrupalCon
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 guido.med...@temetra.com wrote:
Hi,
Is there a
(US-KOP) jim.be...@hibu.commailto:jim.be...@hibu.com
Date: Friday, January 10, 2014 at 12:15 PM
To: solr-user@lucene.apache.orgmailto:solr-user@lucene.apache.org
solr-user@lucene.apache.orgmailto:solr-user@lucene.apache.org
Cc: Smiley, David W. dsmi...@mitre.orgmailto:dsmi...@mitre.org
Subject
,
The range query also looks like a good candidate to be moved to a
filter
query so it can be cached.
Joel Bernstein
Search Engineer at Heliosearch
On Tue, Jan 7, 2014 at 11:34 PM, Smiley, David W.
dsmi...@mitre.org
wrote:
Kranti,
I can't speak to the specific slow
Kranti,
I can't speak to the specific slow-down while grouping, but if you expect to
run [* TO *] queries with any frequency then you should index a boolean flag
and query for that instead. You might also reduce the precisionStep value for
the field you are using to 6 or even 4. But wow
},
stats: {
time: 0
},
debug: {
time: 1
}
}
}
}
On Tue, Nov 19, 2013 at 8:56 PM, Smiley, David W. dsmi...@mitre.org
wrote:
On 11/19/13 4:06 AM, Dhanesh Radhakrishnan dhan...@hifx.co.in wrote:
Hi
On 11/19/13 4:06 AM, Dhanesh Radhakrishnan dhan...@hifx.co.in wrote:
Hi David,
Thank you so much for the detailed reply. I've checked each and every lat
lng coordinates and its a purely polygon.
After some time I did one change in the lat lng indexing.
Changed the indexing format.
Initially I
Hi.
It's clear there is an ordering problem in your latitudes and longitudes.
If indeed you intend to index latitude 9.44Š and longitude 76.45Š as you
said, then you are indexing it correctly. You may also choose to index in
WKT format, which would be POINT(76.45 9.44) but either is fine.
Hi Kuro,
I don't know of any benchmarks featuring distance-sort performance.
Presumably you are using SOLR-2155 because you have multi-valued spatial
fields? If so, LatLonType is not an option. SOLR-2155 sorting
performance is *probably* about the same as the equivalent in Solr 4 RPT.
If you
Hi Dennis,
I would not expect the index growth to be quite linear as the number of
shapes grows, but nonetheless it may be significant. Indexing non-point
shapes will index more term data than it ideally should: LUCENE-4942 I
need to find the time/priority to do it. Probably within the next
much query-time performance gain
we can expect by switching to LatLonType from Solr-2155?
On 11/06/2013 09:56 AM, Smiley, David W. wrote:
Hi Kuro,
I don't know of any benchmarks featuring distance-sort performance.
Presumably you are using SOLR-2155 because you have multi-valued spatial
fields
*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 guido.med...@temetra.com wrote:
2. Java version: There are huges performance winning between Java 5, 6
Use the location_rpt field type in the example schema.xml -- it has good
performance less memory (what you asked for) compared to LatLonType.
To learn how to tweak some of the settings to get better performance at
the expense of some accuracy, see
Mark,
Yes you can. You should index polygons, not polylines. A polyline
semantically refers to the actual line but rather you want to index the
coverage of the nation (the space encircled by the polyline), not the
border literally.
One thing to be aware of is that indexed non-point shapes are
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
~ David
On 8/14/13 2:26 PM, Jeff Wartes jwar...@whitepages.com wrote:
I'm still pondering aggregate-type operations for scoring multi-valued
fields (original thread: http://goo.gl/zOX53f ), and it occurred to me
that distance-sort with SpatialRecursivePrefixTreeFieldType must be doing
something like
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) dsmi...@mitre.org wrote:
Less clear:
:53 AM, Smiley, David W.
dsmi...@mitre.orgwrote:
I see the problem ‹ it's +pp:*. It may look innocent but it's a
performance killer. What your telling Lucene to do is iterate over
*every* term in this index to find all documents that have this data.
Most fields are pretty slow to do
,
- Luis Cappa
2013/7/30 Smiley, David W. dsmi...@mitre.org
Steve,
The FieldCache and DocValues are irrelevant to this problem. Solr's
FilterCache is, and Lucene has no counterpart. Perhaps it would be cool
if Solr could look for expensive field:* usages when parsing its queries
and re-write
10:45 PM, Smiley, David W. dsmi...@mitre.org wrote:
Kevin,
Those are some good query response times but they could be better.
You've
configured the field type sub-optimally. Look again at
http://wiki.apache.org/solr/SpatialForTimeDurations and note in
particular
maxDistErr. You've left
Kevin,
Those are some good query response times but they could be better. You've
configured the field type sub-optimally. Look again at
http://wiki.apache.org/solr/SpatialForTimeDurations and note in particular
maxDistErr. You've left it at the value that comes pre-configured with
Solr,
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 PM, Scott
Bill, I added this comment:
https://issues.apache.org/jira/browse/SOLR-2345?focusedCommentId=13685627p
age=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#commen
t-13685627
On 6/17/13 1:50 AM, William Bell billnb...@gmail.com wrote:
This simple feature of sort=geodist() asc is
, Smiley, David W.
dsmi...@mitre.orgwrote:
Hi Chris:
Have you read: http://wiki.apache.org/solr/SpatialForTimeDurations
You're modeling your data sub-optimally. Full precision rectangles
(distErrPct=0) doesn't scale well and you're seeing that. You should
represent your durations as a point
Hi Chris:
Have you read: http://wiki.apache.org/solr/SpatialForTimeDurations
You're modeling your data sub-optimally. Full precision rectangles
(distErrPct=0) doesn't scale well and you're seeing that. You should
represent your durations as a point and it will take up a fraction of the
space
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 james_will...@hotmail.com wrote:
currently have an item which gets imported into solr, lets call it a book
entry. Well that has a
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
Guido,
The field type solr.SpatialRecursivePrefixTreeFieldType can only
participate in distance reporting for indexed points, not other shapes.
In fact, I recommend not attempting to get the distance if the field isn't
purely indexed points, as it may get confused if it seems some small
shapes.
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 guido.med...@temetra.com wrote:
David,
I just peak it at github, the method will
Hi Luis,
I'm glad it's working out. When I *eventually* get a patch together addressing
the issue, I'll let you know so you can try it out.
'd' is measured in kilometers. degrees is only for the Solr 4 spatial
field's Circle radius parameter and for its distance score results. Kind of a
Dotan,
http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4#Configuration
You need to put the its jar within Solr's WEB-INF/lib; unfortunately you
can't simply reference it via a lib entry and put it wherever. FWIW you
can find the same question and my response on Stackoverflow.
~ David
Hi Guilherme,
That's a neat idea for a feature. It'd be nice if there was a proper Solr
Qparser for these fields because that would then make a nice extension
point to further dereference the shape reference from the index itself.
There is a JIRA issue for that. At least writing such a Qparser
Yeah, solr.PointType. Or use solr.SpatialRecursivePrefixTree with
geo=false
http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4
On 2/8/13 10:38 AM, Kissue Kissue kissue...@gmail.com wrote:
I can see Solr has the field type solr.LatLonType which supports spatial
based on longitudes and
maven.
WBR Viacheslav.
On 23.01.2013, at 19:24, Smiley, David W. wrote:
Viacheslav,
SOLR-2155 is only compatible with Solr 3. However the technology it is
based on lives on in Lucene/Solr 4 in the
SpatialRecursivePrefixTreeFieldType field type. In the example schema
it's registered
Hi Jaspreet.
Your post is confusing. You're using spatial, so you say, yet your
question suggests you have yet to use it. If your documents are
associated with a city, then you should index the lat-lon location of that
city in your documents. It's denormalized like this.
~ David
On 1/23/13
Erick,
Alex asked about Solr 4 spatial, and his use-case requires it because
he's got multi-value spatial fields (multiple business office locations
per document). So the Solr 3 spatial solution you posted won't cut it.
Alex,
You can do this in Solr 4.0. Use one facet.query per circle (I.e.
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,
FWIW I helped someone a few days ago about a similar problem and similarly
advised modifying SpatialPrefixTree:
http://lucene.472066.n3.nabble.com/PointType-multivalued-query-tt4020445.html
IMO GeoHashField should be deprecated because it ads no value.
~ David
On Nov 16, 2012, at 1:49 PM,
Hi TJ.
If you use a circle query shape, it's O(N), plus it puts all the points in
memory. If you use a rectangle via bbox then I'm not sure but its fast enough
that I wouldn't worry about it. If my understanding is correct on Lucene
TrieRange fields, it's O(Log(N)). If you want fast
Hi Jorge,
Please see the notes on Polygons:
http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4#JTS_.2BAC8_WKT_.2BAC8_Polygon_notes
This bullet in particular is relevant:
• The standard way to specify a rectangle in WKT is a Polygon -- WKT
doesn't have a rectangle shape. If you
Hi Matt.
The documentation is here:
http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4
The sort / relevancy section is a TODO; I've been improving this document
lately a bit at a time lately.
My comments are within...
On Oct 5, 2012, at 10:10 AM, Matt Mitchell wrote:
Hi,
Looks like this important bug fix is making it into 4.0 !
http://lucene.472066.n3.nabble.com/VOTE-release-4-0-take-two-tp4010808p4011255.html
On Oct 1, 2012, at 10:26 AM, David Smiley (@MITRE.org) wrote:
Hi Ere,
You are using it correctly. The problem is this:
Spatial doesn't (yet) support 3d. If you have multi-value relationships across
all 3 parameters you mentioned, then you're a bit stuck. I thought you had 1d
(time) multi-value ranges without needing to correlate that to other numeric
ranges that are also multi-value.
On Sep 21, 2012, at 5:03
Stepping back a bit, the reason you are using multiple cores with a join is
because Solr doesn't have a multi-valued numeric range type. The spatial work
I'm doing in Lucene-spatial does, and it's 2-dimensional for an x y whereas
your case calls for one dimension. It's taking a bit of time,
This one should work for now:
https://issues.apache.org/jira/browse/SOLR-3304
If you're comfortable with checking out Lucene/Solr and applying a patch, then
you can do it yourself and get it working without any real coding. You'd have
to use a dummy constant value for 'y' as you index
On Apr 23, 2012, at 9:27 AM, Erick Erickson wrote:
50 hours is a really long time for 2M docs though, so something
doesn't seem right unless the docs are really unusual.
Don't forget he's n-gramming ;-) There's not much more demanding you could ask
of text analysis except for throwing
Ericz,
See this issue: https://issues.apache.org/jira/browse/SOLR-3304
It's just a TODO issue right now but when it's completed, you'll be able to do
polygon spatial queries. All the software is written to do it right now but
the missing Solr piece is temporarily at Spatial4j.com. If you
Hi Tanguy,
On Jan 11, 2012, at 6:14 AM, Tanguy Moal wrote:
Dear ML,
I'm performing some developments relying on spatial capabilities of solr.
I'm using Solr 3.5, have been reading
http://wiki.apache.org/solr/SpatialSearch#Spatial_Query_Parameters and have
the basic behaviours I wanted
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 free chapter, and
On Sep 30, 2011, at 4:14 AM, Alessandro Benedetti wrote:
Ok this is a good news !
I will integrate the jar and test the feature :)
Only one question regarding the indexing process in solrj.
We could index the location data in format : lat,lon in the geohash field?
Or we must encode lan lon
Hi Alessandro.
I can't think of any good reason anyone would use the geohash field type that
is a part of Solr today. If you are shocked I would say that, keep in mind the
work I've done with geohashes is an extension of what's in Solr, it's not
what's in Solr today. Recently I ported
a multivalued location field and I have to make location
queries on it!
So I figured to use the geohash type ...
Any hint about indexing and searching on a multivalued geohash field?
2011/9/29 Smiley, David W. dsmi...@mitre.org
Hi Alessandro.
I can't think of any good reason anyone would use
Hi Mike.
I have hopes that LSP will be ready in time for Solr 4. It's usable now with
the understanding that it's still fairly early and so there are bound to be
bugs. I've been focusing a lot on testing lately. You could try applying
SOLR-2155 but I think there was some Lucene/Solr code
Um, You might try googling LocalSolr or LocalLucene -- dead projects but you
insist on using an old Solr/Lucene.
Of course if all you need is a bounding box filter than a pair of lat lon
range queries is sufficient.
~ David Smiley
On Aug 25, 2011, at 4:01 AM, Javier Heras wrote:
Thanx
Well that's your problem :-P You need to be using the same version of Lucene
for reading writing. Create your index with Lucene 3.3.
FYI I tried indexing the point you said you had trouble with, and with a 300km
radius, and it found it.
On Aug 24, 2011, at 4:39 AM, Javier Heras wrote:
And
Could you reproduce a very simple example of this? For example if there is a
particular indexed point in your data that should be returned from your query
(a query smaller than d=4k10), then reproduce that bug in the Solr example app
by supplying a dummy document with this point and running
Hi.
Either port it to Solr 3, or use Solr 4 (trunk).
I know and have used a Metacarta solution but that is also based on Solr 4 and
I don't think they've back-ported it. I have no clue what they charge for it or
where to get it; I have it as part of their larger solution.
There's also a
Hi Ron.
This is an interesting problem you have. One idea would be to create an index
with the entity relationship going in the other direction. So instead of one
to many, go many to one. You would end up with multiple documents with varying
names but repeated parent entity information --
LucidWorks Enterprise (which is more than Solr, and a modified Solr at that)
isn't free; so you can't extract the Solr part of that package and use it
unless you are willing to pay them.
Lucid's Certified Solr, on the other hand, is free. But they have yet to
bump that to trunk/4.x; it was
On Aug 2, 2011, at 5:47 PM, eks dev wrote:
Sure, I know...,
the point I was trying to make, if someone serious like Lucid is
using solr 4.x as a core technology for own customers, the trunk could
not be all that bad = release date not as far as 2012 :)
Oh the current trunk is most
Can you demonstrate the bug against the example data? If so, provide the URL
please.
~ David
On Aug 1, 2011, at 4:00 PM, Ralf Musick wrote:
Hi,
I combined a spatial distance search with a fulltext search as described
in
above.
Thanks,
Ralf
Am 01.08.2011 22:21, schrieb Smiley, David W.:
Can you demonstrate the bug against the example data? If so, provide the
URL please.
~ David
On Aug 1, 2011, at 4:00 PM, Ralf Musick wrote:
Hi,
I combined a spatial distance search with a fulltext search
Wrapping the dateline or being able to encircle one of the poles (but not
necessarily both) are polygon query features that I feel need to be addressed
before this module is first released (whenever that is), definitely. And
arguably before benchmarking, which we're looking to focus on soon.
on a complex irregular
polygon (say the shape of NJ) I'm getting results which are actually
outside of that polygon. Is there a setting which controls this
resolution?
On Wed, Jul 20, 2011 at 2:53 PM, Smiley, David W. dsmi...@mitre.org wrote:
The notion of a system property is a java concept
the
distErrPct on a query parameter. I'll give this a whirl. Again thank
you.
On Thu, Jul 21, 2011 at 11:13 AM, Smiley, David W. dsmi...@mitre.org wrote:
If you are talking about indexed shapes, then there is an attribute on the
field type definition in your schema called distErrPct
. Thanks again.
On Tue, Jul 19, 2011 at 3:51 PM, Smiley, David W. dsmi...@mitre.org wrote:
Hi Jamie.
I work on LSP; it can index polygons and query for them. Although the
capability is there, we have more testing benchmarking to do, and then we
need to put together a tutorial to explain how
that a try now.
On Wed, Jul 20, 2011 at 10:58 AM, Smiley, David W. dsmi...@mitre.org wrote:
Ryan just updated LSP for Lucene/Solr trunk compatibility so you should do
a mvn clean install and you'll be back in business.
On Jul 20, 2011, at 10:37 AM, Jamie Johnson wrote:
Thanks
, Jul 20, 2011 at 2:37 PM, Smiley, David W. dsmi...@mitre.org wrote:
You can set the system property SpatialContextProvider to
com.googlecode.lucene.spatial.base.context.JtsSpatialContext
~ David
On Jul 20, 2011, at 2:02 PM, Jamie Johnson wrote:
So I've pulled the latest and can run
Hi Michael,
It appears that you want to index circles (aka point-radius) and you want to do
a query that is a point that matches documents where this point is within an
indexed circle. I'm working with a couple Lucene/Solr committers on a
geospatial module that can do this today against Solr 4
Hi Jamie.
I work on LSP; it can index polygons and query for them. Although the
capability is there, we have more testing benchmarking to do, and then we
need to put together a tutorial to explain how to use it at the Solr layer. I
recently cleaned up the READMEs a bit. Try downloading the
Thanks for offering feedback; if nobody commented I was going to send an FYI
post to the dev list.
Comments below.
On Jul 15, 2011, at 3:39 PM, Chris Hostetter wrote:
: integrating Solr with other applications. What isn't there is a list of
: what web/email/file crawlers exist, data
It is precisely this limitation which triggered me to develop a grid indexing
approach using Geohashes: https://issues.apache.org/jira/browse/SOLR-2155
This patch requires a Solr trunk release.
If you have a small number of distinct points in total, and you only need
filtering, then the geohash
Hi Zac.
The syntax in your example is odd, I didn't know you could do that. Except it
doesn't quite work as you show. You could file a bug. As an alternative that
might suffice, use the point-radius arguments in which Solr will take the
minimum-bounding-box for. See {!bbox}
Hi Jamie.
You can definitely use dismax geospatial; these are unrelated. Use
defType=dismax to get dismax and then use an appropriate geospatial filter like
fq={!bbox}sfield=storept=45.15,-93.85d=5
For temporal based constraints, add a temporal filter query:
fq=timestamp:[NOW-1MONTH TO NOW]
?
On Tue, May 24, 2011 at 9:43 AM, Smiley, David W. dsmi...@mitre.org wrote:
Hi Jamie.
You can definitely use dismax geospatial; these are unrelated. Use
defType=dismax to get dismax and then use an appropriate geospatial filter
like fq={!bbox}sfield=storept=45.15,-93.85d=5
For temporal based
Lucid's KStemmer is LGPL and the Solr committers have shown that they don't
want LGPL libraries shipping with Solr. If you are intent on releasing your
changes, I suggest attaching both the modified source and the compiled jar onto
Solr's k-stemmer wiki page; and of course say that it's LGPL
The old name is Lucandra not Lucendra. I've changed the subject accordingly.
I'm looking forward to responses from people but I'm afraid it appears it has
not yet gotten much uptake yet. I think it has enormous potential once it's
hardened a bit and there's more documentation. Personally, I've
Hi Roy.
See this:
http://wiki.apache.org/solr/SpatialSearch#Returning_the_distance
I recommend returning the point location and calculating the distance yourself
-- it's not hard. Getting Solr to return it is a bit of a hack now.
~ David Smiley
Author:
Hi folks. What you're supposed to do is run:
mvn -N -Pbootstrap install
as the very first one-time only step. It copies several custom jar files into
your local repository. From then on you can build like normally with maven.
~ David Smiley
Author:
It's probably not accurate to say that a lot of sites were *relying* on that
feature. It's an optimization.
Getting a working patch applying to trunk is on my TODO-list within the next
couple months.
https://issues.apache.org/jira/browse/SOLR-752
Watch the issue to see when I get to it.
~
LucidKStemmer ( LucidGaze) are LGPL licensed -- I just verified this with the
NOTICE.txt in the download. I wish Lucid's site was more clear on this -- I
checked their first but found no information on the license terms.
I don't know why you want an alternative. If you insist I suppose you
I haven't used PostGIS so I can't offer a real comparison. I think if you were
to try out both, you'd be impressed with Solr's performance/scalability thanks
in large part to its sharding. But for functionality richness in so far as
geospatial is concerned, that's where Solr currently comes
On Apr 5, 2011, at 3:17 PM, Chris Hostetter wrote:
one of the original use cases for bq was for artificial keyword boosting,
in which case it still comes in handy...
bq=meta:promote^100 text:new^10 category:featured^100 (*:*
-category:accessories)^10
Yeah I thought of this specific
As I was reviewing the boosting capabilities of the dismax edismax query
parsers, it's not clear to me that the boost query has much use. The value
of boost functions, particularly with a multiplied boost that edismax supports,
is very clear -- there are a variety of uses. But I can't think
, this was the reason we started the SIS project.
Cheers,
Chris
On Mar 28, 2011, at 11:16 AM, Smiley, David W. wrote:
(This is one of those messages that I would have responded to at the time if
I only noticed it.)
There is not yet indexing of arbitrary shapes (i.e. your data can only be
points
(This is one of those messages that I would have responded to at the time if I
only noticed it.)
There is not yet indexing of arbitrary shapes (i.e. your data can only be
points), but with SOLR-2155 you can query via WKT thanks to JTS. If you want
to index shapes then you'll have to wait a
Heh heh, you say it worked correctly for me yet you didn't actually have
multi-valued data ;-) Funny.
The only solution right now is to store the max and min into indexed
single-valued fields at index time. This is pretty straight-forward to do.
Even if/when Solr supports sorting on a
I was just about to jump in this conversation to mention Solandra and go fig,
Solandra's committer comes in. :-) It was nice to meet you at Strata, Jake.
I haven't dug into the code yet but Solandra strikes me as a killer way to
scale Solr. I'm looking forward to playing with it; particularly
1 - 100 of 161 matches
Mail list logo
