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" wrote:
>Gett
On 3/10/14, 6:45 AM, "Javi" 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 "spatial4j-0.4.1.ja
On 3/10/14, 12:12 PM, "Smiley, David W." wrote:
>>
>>
>>
>>c) I tried no WKT format by adding a comma and using "longitude,latitude"
>>
>>
>>
>> 40.442179,-3.69278
>>
>>
>
>That is *wrong*. Remo
On 3/10/14, 12:56 PM, "javinsnc" 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 Solr’
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 So
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
have one more question: How 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.
>wrot
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 ac
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 cou
an you give me some idea how 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.
>>
>
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. Howev
On 11/19/13 4:06 AM, "Dhanesh Radhakrishnan" 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 indexed t
0 =
>queryNorm\n"
>},
>"QParser": "LuceneQParser",
>"filter_queries": [
>"state:Kerala",
>"location:\"IsWithin(POLYGON((9.471920923238988
>76.5496015548706,9.464174399734185 76.53947353363037,9.457232
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 that'
d by definition.
>> >
>> > Am I missing something here?
>> >
>> >
>> >
>> >
>> > Thanks,
>> > Kranti K. Parisa
>> > http://www.linkedin.com/in/krantiparisa
>> >
>> >
>> >
>> > On Wed
reference the SpatialStrategy, for example.
~ David
From: , "Jim (US-KOP)" mailto:jim.be...@hibu.com>>
Date: Friday, January 10, 2014 at 12:15 PM
To: "solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org>"
mailto:solr-user@lucene.apache.org>>
Cc: "
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 there a way to cluster groups
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 which
Hi Lee,
On 2/3/14, 1:59 PM, "leevduhl" 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 of the key sear
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
eas
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
: , "Jim (US-KOP)" mailto:jim.be...@hibu.com>>
Date: Wednesday, February 12, 2014 at 5:21 PM
To: "Smiley, David W." mailto:dsmi...@mitre.org>>,
"solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org>"
mailto:solr-user@lucene.apache.org>&g
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 appropriat
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 Vand
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, 0.0
ing, whole numbers were working for
>all my edge cases.
>
>-Kevin
>
>On 7/23/13 10:45 PM, "Smiley, David W." wrote:
>
>>Kevin,
>>
>>Those are some good query response times but they could be better.
>>You've
>>configured the field type
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 that. Lucene/Solr does not have some
kind of cache for this. I
12:02 PM, Steven Bower
>>wrote:
>>
>>> Will give the boolean thing a shot... makes sense...
>>>
>>>
>>> On Tue, Jul 30, 2013 at 11:53 AM, Smiley, David W.
>>>wrote:
>>>
>>>> I see the problem ‹ it's +pp:*. It may lo
ould like to know the internal behavior of Solr.
>
>Best regards,
>
>- Luis Cappa
>
>
>2013/7/30 Smiley, David W.
>
>> Steve,
>> The FieldCache and DocValues are irrelevant to this problem. Solr's
>> FilterCache is, and Lucene has no counterpart. Perha
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:
> Less clear: grantRoundDates:"Intersects(0
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
On 8/14/13 2:26 PM, "Jeff Wartes" 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 that.
It isn't.
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 p
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
http://wiki.apache.org/solr/SolrAdaptersForLuce
*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 5, 6
>and 7; we use Ora
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. F
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 desc
>(Which induced another p
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 estimate well for our
>p
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" wrote:
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. Well that has a single location associa
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 (se
n-spatial-meetup-2013011
>>7/
>>
>> Here are the suggestions:
>>
>> q=fieldX:"Intersects(-ƒ end start ƒ)"
>> q=fieldX:"Intersects(-ƒ start end ƒ)"
>> q=fieldX:"Intersects(start -ƒ ƒ end)"
>>
>> All of these, are great
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
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 re-or
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 SOLR-2155
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.
>
>> Hi Alessandro.
>>
>> I can't t
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 &
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, an
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
(I don't twitter or blog so I thought I'd send this message here)
Today at work (at MITRE outside DC) there was (is) a day of technical
presentations about topics related to information dissemination and discovery
(broad squishy words there, but mostly covered "search") at which I spoke about
t
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, 2
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.
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 under the name "location_rpt". For more information on
how to use this field type
or.
>
>Also could you update the WIKI page after the words "it needs to be in
>WEB-INF/lib in Solr's war file, basically" also add the maven artifact
>code like this?
>
>
>com.vividsolutions
>jts
>1.13
>
>
>I think this may help for users us
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 11
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" wrote:
>I can see Solr has the field type solr.LatLonType which supports spatial
>based on longitudes and latitudes. Does it
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 entry and put it wherever. FWIW you
can find the same question and my response on Stackoverflow.
~ David
On 2/
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
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
m
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 shin
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 were
I recommend looking for answers on the wiki (or my book) before asking basic
questions on the list. Here you go:
http://wiki.apache.org/solr/DistributedSearch
~ David Smiley
Author: http://www.packtpub.com/solr-1-4-enterprise-search-server/
On Dec 29, 2010, at 3:24 PM, Mark wrote:
> Is it poss
I assume you found this?: http://wiki.apache.org/solr/MailEntityProcessor
You don't provide enough information to get assistance when you simply say "I
couldn't get it working".
(disclaimer: I haven't used DIH's mail feature)
~ David
On Feb 23, 2011, at 5:15 PM, Husrev Yilmaz wrote:
> Hi,
>
>
The DIH is no longer supplied embedded in the Solr war file. You need to get
it on the classpath somehow. You could add another http://www.packtpub.com/solr-1-4-enterprise-search-server/
On Feb 23, 2011, at 4:11 PM, Alexandre Rocco wrote:
> Hi guys,
>
> I'm having some issues when trying to us
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
Zoie adds NRT to Solr:
http://snaprojects.jira.com/wiki/display/ZOIE/Zoie+Solr+Plugin
I haven't tried it yet but looks cool.
~ David Smiley
Author: http://www.packtpub.com/solr-1-4-enterprise-search-server/
On Mar 9, 2011, at 9:01 AM, Jason Rutherglen wrote:
> Jae,
>
> NRT hasn't been implemen
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 mult
(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 mon
tegory-x
In practice, 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 arbitra
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 thin
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
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 s
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 cou
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.
~ Dav
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: http://www.packtpub.com/solr-1-4-enterprise-
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: http://www.packtpub.com/solr-1-4-enterpri
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
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 lic
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}
http://wiki.apache.
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=store&pt=45.15,-93.85&d=5
For temporal based constraints, add a temporal filter query:
fq=timestamp:[NOW-1MONTH TO N
eria in
> addition then correct?
>
> On Tue, May 24, 2011 at 9:43 AM, Smiley, David W. wrote:
>
>> Hi Jamie.
>>
>> You can definitely use dismax & geospatial; these are unrelated. Use
>> defType=dismax to get dismax and then use an appropriate geospatia
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
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 inte
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 t
til the updates have been made. Thanks again.
>
> On Tue, Jul 19, 2011 at 3:51 PM, Smiley, David W. 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 th
;> Thanks for the update David, I'll give that a try now.
>>
>> On Wed, Jul 20, 2011 at 10:58 AM, Smiley, David W. wrote:
>>> Ryan just updated LSP for Lucene/Solr trunk compatibility so you should do
>>> a "mvn clean install" and you'll
ere do you set that?
>
> On Wed, Jul 20, 2011 at 2:37 PM, Smiley, David W. wrote:
>> You can set the system property SpatialContextProvider to
>> com.googlecode.lucene.spatial.base.context.JtsSpatialContext
>>
>> ~ David
>>
>> On Jul 20, 2011, at 2:02
David. When trying to execute queries 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. wrote:
&g
query. Given
>> this it sounds as if I can get more precise results by changing 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. wrote:
>>> If yo
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. S
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
> http://wiki.apache.org/solr/SpatialSearch#geodist_-_The_distan
pseudo field solution described here
> http://wiki.apache.org/solr/SpatialSearch#Returning_the_distance did not
> word, so I created the query above.
>
> Thanks,
> Ralf
>
>
> Am 01.08.2011 22:21, schrieb Smiley, David W.:
>> Can you demonstrate the bug against the examp
"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 def
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 -- perh
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 sma
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 your
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:
> An
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 Dav
1 - 100 of 171 matches
Mail list logo
