Re: Polygon search query working but NOT Multipolygon

[puneeta]

Hi David, I tried with other point coordinates and it works fine :) I am
still wondering why those coordinates worked with a Polygon though! 
Downloading JTS Test builder helped me a lot. 

Thank you so much!

Puneeta





--
View this message in context: 
http://lucene.472066.n3.nabble.com/Polygon-search-query-working-but-NOT-Multipolygon-tp4343143p4343363.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Not highlighting "and" and "or"?

[Walter Underwood]

Hmm, “and” is missing from the individual terms but present in the phrase.

"rawquerystring":"once and again",
"querystring":"once and again",

"parsedquery":"(+(+DisjunctionMaxQuery(((concept_ai_concepts_names_default:once)^2.0
 | (question:once)^2.0 | subjectNames:once | (bookTitle_text:once)^4.0)) 
+DisjunctionMaxQuery(((concept_ai_concepts_names_default:again)^2.0 | 
(question:again)^2.0 | subjectNames:again | (bookTitle_text:again)^4.0))) 
DisjunctionMaxQuery(((bookTitle_text:\"once and again\")^8.0 | (question:\"once 
and again\")^4.0 | (concept_ai_concepts_names_default:\"once and again\")^4.0 | 
(subjectNames:\"once and again\")^2.0)))/no_coord",
"parsedquery_toString":"+(+((concept_ai_concepts_names_default:once)^2.0 | 
(question:once)^2.0 | subjectNames:once | (bookTitle_text:once)^4.0) 
+((concept_ai_concepts_names_default:again)^2.0 | (question:again)^2.0 | 
subjectNames:again | (bookTitle_text:again)^4.0)) ((bookTitle_text:\"once and 
again\")^8.0 | (question:\"once and again\")^4.0 | 
(concept_ai_concepts_names_default:\"once and again\")^4.0 | 
(subjectNames:\"once and again\")^2.0)",
"QParser":"ExtendedDismaxQParser",


wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Jun 28, 2017, at 9:27 PM, David Smiley  wrote:
> 
> Hi Walter,
> No they are not.  Does debug=query show that these words are in your parsed
> query?
> 
> On Wed, Jun 28, 2017 at 5:13 PM Walter Underwood 
> wrote:
> 
>> Is there some special casing in the highlighter to skip query syntax
>> words? The words “and” and “or” don’t get highlighted.
>> 
>> This is in 6.5.0.
>> 
>>   question
>>   html
>>   440
>>   fastVector
>>   1
>> 
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>> 
>> 
>> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com

Re: Not highlighting "and" and "or"?

[David Smiley]

Hi Walter,
No they are not.  Does debug=query show that these words are in your parsed
query?

On Wed, Jun 28, 2017 at 5:13 PM Walter Underwood 
wrote:

> Is there some special casing in the highlighter to skip query syntax
> words? The words “and” and “or” don’t get highlighted.
>
> This is in 6.5.0.
>
>question
>html
>440
>fastVector
>1
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Polygon search query working but NOT Multipolygon

[David Smiley]

This polygon is fairly rectangular with one side having a ton of points.
Nonetheless the query point is clearly far apart from it (it's much lower
(smaller 'y' dimension).

On Wed, Jun 28, 2017 at 10:17 PM puneeta  wrote:

> Hi David,
>   Actually my polygon had too many coordinates, so i just omitted some
> while
> posting my query. Here is my complete multipolygon where the last point is
> same as the first one:
>
> 
> MULTIPOLYGON (((-86.477551331 32.490605651,
> -86.477637350 32.4903921820001, -86.478257247 32.4905655910001,
> -86.478250466 32.4905802390001, -86.478243988 32.49059368096,
> -86.47823751 32.490607122, -86.478231749 32.49061910096, -86.478224637
> 32.4906340650001, -86.478218237 32.490647541, -86.478211847
> 32.49066103595, -86.478205478 32.4906745260001, -86.47820210799989
> 32.4906816669, -86.478199132 32.4906880240001, -86.478192825
> 32.490701523, -86.478186533 32.490715047, -86.478183209 32.4907222090001,
> -86.4781802789 32.4907285690001, -86.478174063 32.4907421250001,
> -86.478167851 32.4907556540001, -86.478162558 32.49076723696,
> -86.47815905399989 32.490774513000105, -86.477551331 32.490605651)))
> 
> 
>
> Thanks,
> Puneeta
>
>
>
>
> david.w.smi...@gmail.com wrote
> > I tried your data in the "JTS TestBuilder" GUI.  Firstly, your polygon
> > isn't "closed", but that was easily fixed by repeating the first point at
> > the end.  See the attached screenshot of the GUI for what these shapes
> > look like.  The red dot (the query point) is outside of this
> > triangular-ish shape, and thus not a match.
> >
> >
> >
> >
> >> On Jun 28, 2017, at 12:33 PM, puneeta 
>
> > pverma@
>
> >  wrote:
> >>
> >> Hi David,
> >>  I did the following changes:
> >>
> >> Changed in schema.xml:
> >>
> >  >>
> >
> >>
> spatialContextFactory="org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory"
> >>   autoIndex="true"
> >>   validationRule="repairBuffer0"
> >>   distanceUnits="kilometers"
> >> useJtsMulti="false"
> >> />
> >>
> >>
> >> Added in solrconfig.xml:
> >>
> >  >>
> >class="solr.LRUCache"
> >>   size="256"
> >>   initialSize="0"
> >>   autowarmCount="100%"
> >>   regenerator="solr.NoOpRegenerator"/>
> >>
> >> My fields in the core as defined in the schema is:
> >> 
> http://lucene.472066.n3.nabble.com/file/n4343221/SolrGeoFieldDefinition.png
> ;
> >>
> >> However, I still face the same issue. No results found for a
> multipolygon
> >> search.
> >>
> >> Not sure whats happening :(
> >>
> >> Puneeta
> >>
> >>
> >>
> >>
> >>
> >>
>
> > david.w.smiley@
>
> >  wrote
> >>>
> https://lucene.apache.org/solr/guide/6_6/spatial-search.html#SpatialSearch-RptWithGeometrySpatialField
> >>> 
> https://lucene.apache.org/solr/guide/6_6/spatial-search.html#SpatialSearch-RptWithGeometrySpatialField
> ;
> >>>
> >>>
>  On Jun 28, 2017, at 11:32 AM, puneeta 
> >>
> >>> pverma@
> >>
> >>>  wrote:
> 
>  Hi David,
>  I am sorry ,I did not understand what do you mean by "I suggest using
>  RptWithGeometry field". Should leave the existing location_rpt
>  definition
>  in
>  schema.xml?
> 
> >>>
> >  >>
> >>>
> >>> class="solr.SpatialRecursivePrefixTreeFieldType"
>   geo="true" distErrPct="0.025" maxDistErr="0.001"
>  distanceUnits="kilometers" />
>  This line I have commented. Should I uncomment it?
> 
>  1."remove distErrPct and maxDistErr" -
>  2.Added usejtsMulti="false"
> 
>  I will change the  field definition as follows, try to execute and
>  report
>  back.
> 
> >>>
> >  >>
> >>>
> >>>   class="solr.SpatialRecursivePrefixTreeFieldType"
> 
> 
> >> *
> >>> jts*="org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory"
>    autoIndex="true"
>    validationRule="repairBuffer0"
>    distanceUnits="kilometers"
>    *useJtsMulti="false"*/>
> 
> 
>  The issue I am facing is that the I am not getting the search result
>  for
>  Multipolygon i.e I should get hits.Currently, the numFound = 0, It
>  should
>  find atleast 1 record as it does for a Polygon search.
> 
>  Thanks,
>  Puneeta
> 
> 
> >>
> >>> david.w.smiley@
> >>
> >>> mailto:
> >>
> >>> david.w.smiley@
> >>
> >>>  wrote
> > I suggest using RptWithGeometry field, and with that change remove
> > distErrPct and maxDistErr.  See the ref guide, and note the geometry
> > cache
> > option.
> > BTW spatialContextFactory can simply be "jts".
> >
> > If this fixes the issue, then the issue was related to grid
> > approximation.
> >
> > BTW you never quite said what it was about the results that was
> wrong.
> > Did you get hits you didn't expect (I'm guessing yes) or the inverse?
> 

Re: Polygon search query working but NOT Multipolygon

[puneeta]

Hi David,
  Actually my polygon had too many coordinates, so i just omitted some while
posting my query. Here is my complete multipolygon where the last point is
same as the first one:


MULTIPOLYGON (((-86.477551331 32.490605651,
-86.477637350 32.4903921820001, -86.478257247 32.4905655910001,
-86.478250466 32.4905802390001, -86.478243988 32.49059368096,
-86.47823751 32.490607122, -86.478231749 32.49061910096, -86.478224637
32.4906340650001, -86.478218237 32.490647541, -86.478211847
32.49066103595, -86.478205478 32.4906745260001, -86.47820210799989
32.4906816669, -86.478199132 32.4906880240001, -86.478192825
32.490701523, -86.478186533 32.490715047, -86.478183209 32.4907222090001,
-86.4781802789 32.4907285690001, -86.478174063 32.4907421250001,
-86.478167851 32.4907556540001, -86.478162558 32.49076723696,
-86.47815905399989 32.490774513000105, -86.477551331 32.490605651)))



Thanks,
Puneeta




david.w.smi...@gmail.com wrote
> I tried your data in the "JTS TestBuilder" GUI.  Firstly, your polygon
> isn't "closed", but that was easily fixed by repeating the first point at
> the end.  See the attached screenshot of the GUI for what these shapes
> look like.  The red dot (the query point) is outside of this
> triangular-ish shape, and thus not a match.
> 
> 
> 
> 
>> On Jun 28, 2017, at 12:33 PM, puneeta 

> pverma@

>  wrote:
>> 
>> Hi David,
>>  I did the following changes:
>> 
>> Changed in schema.xml:
>> 
> >
>  
>> spatialContextFactory="org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory"
>>   autoIndex="true"
>>   validationRule="repairBuffer0"
>>   distanceUnits="kilometers" 
>> useJtsMulti="false"
>> />
>> 
>> 
>> Added in solrconfig.xml:
>> 
> >
>class="solr.LRUCache"
>>   size="256"
>>   initialSize="0"
>>   autowarmCount="100%"
>>   regenerator="solr.NoOpRegenerator"/>
>> 
>> My fields in the core as defined in the schema is:
>> http://lucene.472066.n3.nabble.com/file/n4343221/SolrGeoFieldDefinition.png;
>>  
>> 
>> However, I still face the same issue. No results found for a multipolygon
>> search.
>> 
>> Not sure whats happening :(
>> 
>> Puneeta
>> 
>> 
>> 
>> 
>> 
>> 

> david.w.smiley@

>  wrote
>>> https://lucene.apache.org/solr/guide/6_6/spatial-search.html#SpatialSearch-RptWithGeometrySpatialField
>>> https://lucene.apache.org/solr/guide/6_6/spatial-search.html#SpatialSearch-RptWithGeometrySpatialField;
>>> 
>>> 
 On Jun 28, 2017, at 11:32 AM, puneeta 
>> 
>>> pverma@
>> 
>>>  wrote:
 
 Hi David,
 I am sorry ,I did not understand what do you mean by "I suggest using
 RptWithGeometry field". Should leave the existing location_rpt
 definition
 in
 schema.xml?
 
>>> 
> >
>>> 
>>> class="solr.SpatialRecursivePrefixTreeFieldType"
  geo="true" distErrPct="0.025" maxDistErr="0.001"
 distanceUnits="kilometers" />
 This line I have commented. Should I uncomment it?
 
 1."remove distErrPct and maxDistErr" - 
 2.Added usejtsMulti="false"
 
 I will change the  field definition as follows, try to execute and
 report
 back.
 
>>> 
> >
>>> 
>>>   class="solr.SpatialRecursivePrefixTreeFieldType" 
  
 
>> *
>>> jts*="org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory" 
   autoIndex="true"
   validationRule="repairBuffer0"
   distanceUnits="kilometers" 
   *useJtsMulti="false"*/> 
 
 
 The issue I am facing is that the I am not getting the search result
 for
 Multipolygon i.e I should get hits.Currently, the numFound = 0, It
 should
 find atleast 1 record as it does for a Polygon search.
 
 Thanks,
 Puneeta
 
 
>> 
>>> david.w.smiley@
>> 
>>> mailto:
>> 
>>> david.w.smiley@
>> 
>>>  wrote
> I suggest using RptWithGeometry field, and with that change remove
> distErrPct and maxDistErr.  See the ref guide, and note the geometry
> cache
> option.
> BTW spatialContextFactory can simply be "jts".
> 
> If this fixes the issue, then the issue was related to grid
> approximation.
> 
> BTW you never quite said what it was about the results that was wrong. 
> Did you get hits you didn't expect (I'm guessing yes) or the inverse?
> 
> ~ David
> 
>> On Jun 28, 2017, at 10:55 AM, puneeta 
 
> pverma@
 
>  wrote:
>> 
>> Hi David,
>> Thank you for the prompt reply. My field definition in schema.xml is
>> :
>> 
>> I commented the existing location_rpt
>> 
>> 
>> 
>> And added:
>> 
> 
>>> 
> >
>>> 
> 
> class="solr.SpatialRecursivePrefixTreeFieldType"
>> 
>> 

Not highlighting "and" and "or"?

[Walter Underwood]

Is there some special casing in the highlighter to skip query syntax words? The 
words “and” and “or” don’t get highlighted.

This is in 6.5.0.

   question
   html
   440
   fastVector
   1

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

Re: Tlogs not being deleted/truncated

[Webster Homer]

Sometimes there are subdirectories of tlog files for example this is a
directory name tlog.20170624124859032 Why do these come into existence? The
sum of the file sizes in the folders seem close to the value returned by
the CDCR action=QUEUES

On Tue, Jun 27, 2017 at 4:05 PM, Webster Homer 
wrote:

> We also have the same collections in our development and QA environments.
> In our Dev environment which is not using CDCR replication, but does have
> autoCommit set, we have 440 tlog files. The only difference in the
> configuration is that dev doesn't have the cdcr request handler configured.
> It does have the solr.CdCrUpdateLog set.
>
> 
>   ${solr.ulog.dir:}
> 
>
>
> On Tue, Jun 27, 2017 at 3:11 PM, Webster Homer 
> wrote:
>
>> It appears right how that we are  not seeing an issue with the target
>> collections, we definitely see a problem with the source collection.
>> numRecordsToKeep and maxNumLogsToKeep are set to the default values of
>> 100 and 10 respectively. We probably don't need 10 tlog files around.
>>
>>
>> On Tue, Jun 27, 2017 at 11:32 AM, Webster Homer 
>> wrote:
>>
>>> Commits were definitely not happening. We ran out of filesystem space.
>>> The admins deleted old tlogs and restartd. The collection in question was
>>> missing a lot of data. We reloaded it, and then we saw some commits. In
>>> Solrcloud they look like this:
>>> 2017-06-23 17:28:06.441 INFO  (commitScheduler-56-thread-1)
>>> [c:sial-content-citations s:shard1 r:core_node2
>>> x:sial-content-citations_shard1_replica1] o.a.s.u.DirectUpdateHandler2
>>> start commit{,optimize=false,openSearcher=true,waitSearcher=true,e
>>> xpungeDeletes=false,softCommit=true,prepareCommit=false}
>>> 2017-06-23 17:28:07.823 INFO  (commitScheduler-56-thread-1)
>>> [c:sial-content-citations s:shard1 r:core_node2
>>> x:sial-content-citations_shard1_replica1] o.a.s.s.SolrIndexSearcher
>>> Opening [Searcher@1c6a3bf1[sial-content-citations_shard1_replica1] main]
>>> 2017-06-23 17:28:07.824 INFO  (commitScheduler-56-thread-1)
>>> [c:sial-content-citations s:shard1 r:core_node2
>>> x:sial-content-citations_shard1_replica1] o.a.s.u.DirectUpdateHandler2
>>> end_commit_flush
>>> 2017-06-23 17:28:49.665 INFO  (commitScheduler-66-thread-1)
>>> [c:ehs-catalog-qmdoc s:shard2 r:core_node2 
>>> x:ehs-catalog-qmdoc_shard2_replica1]
>>> o.a.s.u.DirectUpdateHandler2 start commit{,optimize=false,openSea
>>> rcher=false,waitSearcher=true,expungeDeletes=false,softCommi
>>> t=false,prepareCommit=false}
>>> 2017-06-23 17:28:49.742 INFO  (commitScheduler-66-thread-1)
>>> [c:ehs-catalog-qmdoc s:shard2 r:core_node2 
>>> x:ehs-catalog-qmdoc_shard2_replica1]
>>> o.a.s.c.SolrDeletionPolicy SolrDeletionPolicy.onCommit: commits: num=2
>>> commit{dir=NRTCachingDirectory(MMapDirectory@/var/solr/data/
>>> ehs-catalog-qmdoc_shard2_replica1/data/index
>>> lockFactory=org.apache.lucene.store.NativeFSLockFactory@597830aa;
>>> maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_2gb,generation=3179}
>>>
>>> I have been busy and couldn't get back to this issue until now. The
>>> problem started happening again. I manually sent a commit and that seemed
>>> to help for a time. Unfortunately I don't have access to our Production
>>> solrs. we use logstash for the logs, but not all logs were being captured,
>>> the commit messages above were not.
>>>
>>>
>>> On Tue, Jun 20, 2017 at 5:34 PM, Erick Erickson >> > wrote:
>>>
 bq: Neither in our source collection nor in our target collections.

 Hmmm. You should see messages similar to the following which I just
 generated on Solr 6.2 (stand-alone I admit but that code should be the
 same):

 INFO  - 2017-06-20 21:11:55.424; [   x:techproducts]
 org.apache.solr.update.DirectUpdateHandler2; start
 commit{,optimize=false,openSearcher=false,waitSearcher=true,
 expungeDeletes=false,softCommit=false,prepareCommit=false}

 INFO  - 2017-06-20 21:11:55.425; [   x:techproducts]
 org.apache.solr.update.SolrIndexWriter; Calling setCommitData with
 IW:org.apache.solr.update.SolrIndexWriter@4862d97c

 INFO  - 2017-06-20 21:11:55.663; [   x:techproducts]
 org.apache.solr.core.SolrDeletionPolicy; SolrDeletionPolicy.onCommit:
 commits: num=2

 commit{dir=NRTCachingDirectory(MMapDirectory@/Users/Erick/ap
 ache/solrVersions/playspace/solr/example/techproducts/solr/t
 echproducts/data/index
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@3d8e7c06;
 maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_c,generation=12}

 commit{dir=NRTCachingDirectory(MMapDirectory@/Users/Erick/ap
 ache/solrVersions/playspace/solr/example/techproducts/solr/t
 echproducts/data/index
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@3d8e7c06;
 maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_d,generation=13}

 INFO  - 2017-06-20 

Re: Suggester and fuzzy/infix suggestions

[Walter Underwood]

Yes, but it is better than nothing. Don’t let the unavailable perfect solution 
keep you from implementing the available good solution.

If you want to easily use fuzzy search with edismax, check out the patch 
submitted with SOLR-629.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Jun 28, 2017, at 12:06 PM, Student 1  wrote:
> 
> I thought about that - but that does not solve the issue. If the user types
> in a misspelled word, and that word is somewhere in the middle of the
> field, that result will not be returned.
> 
> 2017-06-28 19:00 GMT+02:00 Walter Underwood :
> 
>> I set up two suggesters, one fuzzy and one analyzing infix. That gives two
>> sets of suggestions, so the client code has to merge them into one list and
>> toss duplicates.
>> 
>> They use the same weights, so I can keep the top weighted suggestions.
>> 
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>> 
>> 
>>> On Jun 28, 2017, at 9:47 AM, Student 1  wrote:
>>> 
>>> Hi,
>>> 
>>> I'm trying to implement suggestions mechanism using Solr Suggester
>>> component, that would work like this:
>>> 
>>> - look inside of the field (like AnalyzingInfixLookupFactory does) AND
>>> - allow for minor spelling mistakes (like FuzzyLookupFactory does).
>>> 
>>> Is it at all possible? It looks to me, like you can only get one
>> behaviour
>>> - either look inside the field and require strictly correct spelling, OR
>>> allow for typos but match only beginning of the field.
>>> 
>>> Regards,
>>> Piotr
>> 
>> 

Re: Suggester and fuzzy/infix suggestions

[Student 1]

I thought about that - but that does not solve the issue. If the user types
in a misspelled word, and that word is somewhere in the middle of the
field, that result will not be returned.

2017-06-28 19:00 GMT+02:00 Walter Underwood :

> I set up two suggesters, one fuzzy and one analyzing infix. That gives two
> sets of suggestions, so the client code has to merge them into one list and
> toss duplicates.
>
> They use the same weights, so I can keep the top weighted suggestions.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
>
> > On Jun 28, 2017, at 9:47 AM, Student 1  wrote:
> >
> > Hi,
> >
> > I'm trying to implement suggestions mechanism using Solr Suggester
> > component, that would work like this:
> >
> > - look inside of the field (like AnalyzingInfixLookupFactory does) AND
> > - allow for minor spelling mistakes (like FuzzyLookupFactory does).
> >
> > Is it at all possible? It looks to me, like you can only get one
> behaviour
> > - either look inside the field and require strictly correct spelling, OR
> > allow for typos but match only beginning of the field.
> >
> > Regards,
> > Piotr
>
>

Re: Spatial Search based on the amount of docs, not the distance

[David Smiley]

Deniz didn't mention document-to-document distance sort but he/she didn't say 
it wasn't that case either.

Any way, FYI at the Lucene level with LatLonPoint there is some sophisticated 
BKD search code to efficiently return the top N distance ordered documents 
(where you supply N).  Although as far as I recall, it also has no filtering 
mechanism, so if you have any other filters (keyword/time/whatever), it 
wouldn't work.

I once did this feature on an RPT index for a client and I got the open-source 
permission but I haven't gotten around to properly adding it to Solr.  I might 
approach it a bit differently now.

~ David

> On Jun 22, 2017, at 8:34 PM, Tim Casey  wrote:
> 
> deniz,
> 
> I was going to add something here.  The reason what you want is probably
> hard to do is because you are asking solr, which stores a document, to
> return documents using an attribute of document pairs.  As only a though
> exercise, if you stored record pairs as a single document, you could
> probably query it directly.  That is, if you have d1 and d2 and you are
> querying  around d1 and ordering by distance, then you could get this
> directly from a document representing a record pair.  I don't think this is
> practical, because it is an n^2 store.
> 
> Since the n^2 problem is there, people are going to suggest some heuristic
> which avoids this problem.  What Erick is suggesting is down this path.
> Query around a point and sort by distance taking the top K results.  The
> result is taking a linear slice of the n^2 distance attribute.
> 
> tim
> 
> 
> 
> On Wed, Jun 21, 2017 at 7:50 PM, Erick Erickson 
> wrote:
> 
>> Would it serve to sort by distance? True, if you matched a zillion
>> documents within a 1km radius you'd still perform the distance calcs, but
>> the result would be a manageable number.
>> 
>> I have to ask "Why to you care?". Is this an efficiency question (i.e. you
>> want to keep Solr from having to do expensive work) or is it a question of
>> having to get hits at all? It's at least possible that the solution for one
>> is not the solution for the other.
>> 
>> Best,
>> Erick
>> 
>> On Wed, Jun 21, 2017 at 5:32 PM, deniz  wrote:
>> 
>>> it is for sure possible to use d value for limiting the distance,
>> however,
>>> it
>>> might not be very efficient, as some of the coords may not have any docs
>>> around for a large value of d... so it is hard to determine a default
>> value
>>> for d.
>>> 
>>> though it sounds like havinga default d and gradual increments on its
>> value
>>> might be a work around for top K results...
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -
>>> Zeki ama calismiyor... Calissa yapar...
>>> --
>>> View this message in context: http://lucene.472066.n3.
>>> nabble.com/Spatial-Search-based-on-the-amount-of-docs-not-the-distance-
>>> tp4342108p4342258.html
>>> Sent from the Solr - User mailing list archive at Nabble.com.
>>> 
>> 

SOLR 6.6 Restrict access to specific collections

[Cody Rathgeber]

Hello,


I’m trying to create custom rules to work with the Solr  Rule Based 
Authorization Plugin. 
https://lucene.apache.org/solr/guide/6_6/rule-based-authorization-plugin.html 
 
. I have a basic security.json uploaded to zookeeper and working etc. the Issue 
i’m having is the pre-created rules apply to all collections. I found a few 
guides saying you could do something like the code below, to restrict access to 
collections to specific roles, however on newer versions of solr it doesn’t 
seem to like the syntax in the .json and can’t parse it. Anyone have any 
experience with this and can point me in the right direction?

curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
'Content-type:application/json'-d '{ 
  "set-permission": { "name":"a-custom-permission-name",
  "collection":"gettingstarted",
  "path":”/update"
  "role": "dev"
   }

Basically we are planning on having a solrcloud cluster on a privately 
accessible network clients webserver’s can hit, however we need a way to lock 
down each collection to ensure each client can only hit their own collection. 
It’s already IP restricted to the webservers.

Thanks,
Cody

Re: combined boolean operators

[Erick Erickson]

Well, the query parsers never promised to implement strict boolean
algebra. You can emulate it with careful use of parentheses.

See: https://lucidworks.com/2011/12/28/why-not-and-or-and-not/

Best,
Erick

On Wed, Jun 28, 2017 at 9:30 AM, Marco Staub  wrote:
> Hi there,
>
> I am a litte confused about combined boolean operators in the query parser. 
> For example If I search for
>
> myfield:a AND myfield:b OR myfield:c
>
> This will be parsed internal to the query
>
> +myfield:a +myfield:b myfield:c
>
> But if I change the default operator to AND (q.op=AND) I got for the same 
> origin query:
>
> +myfield:a myfield:b myfield:c
>
> Which is BTW in both cases not pure boolean algebra: A AND B OR C should be 
> (A AND B) OR C
>
> Did anybody know why the query is handled that way?
>
> Version is Solr 6.5.0, the handler ist almost the default /select handler:
>
> 
> explicit
> json
> true
> 
> 
>
> Queries:
> /select?debugQuery=on=on=myfield:a AND myfield:b OR myfield:c=json
> /select?debugQuery=on=on=AND=myfield:a AND myfield:b OR 
> myfield:c=json
>
> See parsedquery in the result. myfield should be replaceable by any fieldname 
> in the index like id.
>
> Best
> Marco

Re: Suggester and fuzzy/infix suggestions

[Walter Underwood]

I set up two suggesters, one fuzzy and one analyzing infix. That gives two sets 
of suggestions, so the client code has to merge them into one list and toss 
duplicates.

They use the same weights, so I can keep the top weighted suggestions.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Jun 28, 2017, at 9:47 AM, Student 1  wrote:
> 
> Hi,
> 
> I'm trying to implement suggestions mechanism using Solr Suggester
> component, that would work like this:
> 
> - look inside of the field (like AnalyzingInfixLookupFactory does) AND
> - allow for minor spelling mistakes (like FuzzyLookupFactory does).
> 
> Is it at all possible? It looks to me, like you can only get one behaviour
> - either look inside the field and require strictly correct spelling, OR
> allow for typos but match only beginning of the field.
> 
> Regards,
> Piotr

Suggester and fuzzy/infix suggestions

[Student 1]

Hi,

I'm trying to implement suggestions mechanism using Solr Suggester
component, that would work like this:

- look inside of the field (like AnalyzingInfixLookupFactory does) AND
- allow for minor spelling mistakes (like FuzzyLookupFactory does).

Is it at all possible? It looks to me, like you can only get one behaviour
- either look inside the field and require strictly correct spelling, OR
allow for typos but match only beginning of the field.

Regards,
Piotr

Re: Polygon search query working but NOT Multipolygon

[puneeta]

Hi David,
  I did the following changes:

Changed in schema.xml:



Added in solrconfig.xml:


My fields in the core as defined in the schema is:
 

However, I still face the same issue. No results found for a multipolygon
search.

Not sure whats happening :(

Puneeta





david.w.smi...@gmail.com wrote
> https://lucene.apache.org/solr/guide/6_6/spatial-search.html#SpatialSearch-RptWithGeometrySpatialField
> https://lucene.apache.org/solr/guide/6_6/spatial-search.html#SpatialSearch-RptWithGeometrySpatialField;
> 
> 
>> On Jun 28, 2017, at 11:32 AM, puneeta 

> pverma@

>  wrote:
>> 
>> Hi David,
>> I am sorry ,I did not understand what do you mean by "I suggest using
>> RptWithGeometry field". Should leave the existing location_rpt definition
>> in
>> schema.xml?
>> 
> >
>  class="solr.SpatialRecursivePrefixTreeFieldType"
>>   geo="true" distErrPct="0.025" maxDistErr="0.001"
>> distanceUnits="kilometers" />
>> This line I have commented. Should I uncomment it?
>> 
>> 1."remove distErrPct and maxDistErr" - 
>> 2.Added usejtsMulti="false"
>> 
>> I will change the  field definition as follows, try to execute and report
>> back.
>> 
> >
>class="solr.SpatialRecursivePrefixTreeFieldType" 
>>
>> 
*
> jts*="org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory" 
>> autoIndex="true"
>> validationRule="repairBuffer0"
>> distanceUnits="kilometers" 
>> *useJtsMulti="false"*/> 
>> 
>> 
>> The issue I am facing is that the I am not getting the search result for
>> Multipolygon i.e I should get hits.Currently, the numFound = 0, It should
>> find atleast 1 record as it does for a Polygon search.
>> 
>> Thanks,
>> Puneeta
>> 
>> 

> david.w.smiley@

>  mailto:

> david.w.smiley@

>  wrote
>>> I suggest using RptWithGeometry field, and with that change remove
>>> distErrPct and maxDistErr.  See the ref guide, and note the geometry
>>> cache
>>> option.
>>> BTW spatialContextFactory can simply be "jts".
>>> 
>>> If this fixes the issue, then the issue was related to grid
>>> approximation.
>>> 
>>> BTW you never quite said what it was about the results that was wrong. 
>>> Did you get hits you didn't expect (I'm guessing yes) or the inverse?
>>> 
>>> ~ David
>>> 
 On Jun 28, 2017, at 10:55 AM, puneeta 
>> 
>>> pverma@
>> 
>>>  wrote:
 
 Hi David,
 Thank you for the prompt reply. My field definition in schema.xml is :
 
 I commented the existing location_rpt
 
 
 
 And added:
 
>>> 
> >
>>> 
>>> class="solr.SpatialRecursivePrefixTreeFieldType"
 
 spatialContextFactory="org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory"
  autoIndex="true"
  validationRule="repairBuffer0"
  distErrPct="0.025"
  maxDistErr="0.001"
  distanceUnits="kilometers" />
 
 My Solr version is 6.2.1
 
 Thanks,
 Puneeta
 
 
 
 
 --
 View this message in context:
 http://lucene.472066.n3.nabble.com/Polygon-search-query-working-but-NOT-Multipolygon-tp4343143p4343162.html
 Sent from the Solr - User mailing list archive at Nabble.com.
>> 
>> 
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://lucene.472066.n3.nabble.com/Polygon-search-query-working-but-NOT-Multipolygon-tp4343143p4343184.html
>> http://lucene.472066.n3.nabble.com/Polygon-search-query-working-but-NOT-Multipolygon-tp4343143p4343184.html;
>> Sent from the Solr - User mailing list archive at Nabble.com
>> http://nabble.com/;.





--
View this message in context: 
http://lucene.472066.n3.nabble.com/Polygon-search-query-working-but-NOT-Multipolygon-tp4343143p4343221.html
Sent from the Solr - User mailing list archive at Nabble.com.

combined boolean operators

[Marco Staub]

Hi there,

I am a litte confused about combined boolean operators in the query parser. For 
example If I search for

myfield:a AND myfield:b OR myfield:c

This will be parsed internal to the query

+myfield:a +myfield:b myfield:c

But if I change the default operator to AND (q.op=AND) I got for the same 
origin query:

+myfield:a myfield:b myfield:c

Which is BTW in both cases not pure boolean algebra: A AND B OR C should be (A 
AND B) OR C

Did anybody know why the query is handled that way?

Version is Solr 6.5.0, the handler ist almost the default /select handler:


explicit
json
true



Queries:
/select?debugQuery=on=on=myfield:a AND myfield:b OR myfield:c=json
/select?debugQuery=on=on=AND=myfield:a AND myfield:b OR 
myfield:c=json

See parsedquery in the result. myfield should be replaceable by any fieldname 
in the index like id.

Best
Marco

Re: Apache 4.9.1 - trouble trying to use complex phrase query parser.

[Stefan Matheis]

If you'd include the actual error message you get .. it might easier to try
and help?

-Stefan

On Jun 28, 2017 6:24 PM, "Michael Craven"  wrote:

> Hi -
>
> I am trying to use the complex phrase query parser on my Drupal
> installation. Our core is sore 4.9.1, so I thought it should be no problem.
> Search works fine when I use a local parameter to do a search of type
> lucene, dismax, or edismax, (a la {!lucene} etc.), but when I try to do a
> search of type complex phrase, I get an error. Does anyone know why that
> might be? Is this maybe a Drupal specific problem? We are running Drupal
> 7.56.
>
> Thanks
>
> -M

Apache 4.9.1 - trouble trying to use complex phrase query parser.

[Michael Craven]

Hi - 

I am trying to use the complex phrase query parser on my Drupal installation. 
Our core is sore 4.9.1, so I thought it should be no problem. Search works fine 
when I use a local parameter to do a search of type lucene, dismax, or edismax, 
(a la {!lucene} etc.), but when I try to do a search of type complex phrase, I 
get an error. Does anyone know why that might be? Is this maybe a Drupal 
specific problem? We are running Drupal 7.56.

Thanks

-M

RE: Solr 5.5 - spatial intersects query returns results outside of search box

[Leila Gonzales]

Will do. Thanks for the tip!

-Original Message-
From: David Smiley [mailto:david.w.smi...@gmail.com]
Sent: Wednesday, June 28, 2017 8:38 AM
To: solr-user@lucene.apache.org
Subject: Re: Solr 5.5 - spatial intersects query returns results outside
of search box

No prob.

BTW you may want to investigate use of BBoxField or
RptWithGeometrySpatialField; both are also more accurate... but vanilla
RPT may be just fine (fastest).


> On Jun 28, 2017, at 11:32 AM, Leila Gonzales  wrote:
>
> Thanks David! I fixed the coordinates and put some error checking in
> my Solr indexing script to trap for this type of coordinate mismatch.
>
> -Original Message-
> From: David Smiley [mailto:david.w.smi...@gmail.com]
> Sent: Wednesday, June 28, 2017 8:21 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Solr 5.5 - spatial intersects query returns results
> outside of search box
>
>
>> On Jun 27, 2017, at 3:28 AM, Leila Gonzales  wrote:
>>
>> {
>>
>>   "id": "5230",
>>
>>   "location_geo":
>>
>
["ENVELOPE(-75.0,-75.939723,39.3597224,38.289722)"
> ]
>>
>> }
>
> This is an unusual rectangle.  Remember this is minX, maxX, maxY, minY.
> Thus this rectangle wraps the entire globe except for nearly a degree.
> It matches your query rectangle.

Re: master slave replication taking time

[Erick Erickson]

How long it takes to copy the entire index from one machine to another
over your network. Solr can't go any faster than your network can
support. Consider SolrCloud if you need something closer to NRT.

Best,
Erick

On Tue, Jun 27, 2017 at 11:31 PM, Midas A  wrote:
> Hi,
>
> we have around 2000 documents and our master to slave replication is
> taking time  upto 20 second.
>
> What should i check ?

Re: Using asterik(*) with unicode characters.

[Erick Erickson]

There's a long blog on wildcards here:
https://lucidworks.com/2011/11/29/whats-with-lowercasing-wildcard-multiterm-queries-in-solr/

The gist is that when you are analyzing a token, if the analysis chain
splits a token into more than one part then wildcards are impossible
to get right. So any "MultiTermAware" filter will barf if you ask it
to emit more than one token when doing wildcard searches. For filters
that are _not_ "MultiTermAware", they're just skipped in the query
analysis chain.

That leaves the question of why your query chain seems to emit two
tokens for  MöllerGruppen but not MollerGruppen. I think it's because
you have preserveOriginal set to true in the query analysis chain
here:
 

So this entry emits both
MöllerGruppen and MollerGruppen
for the input
MöllerGruppen
but not for
MollerGruppen
since MollerGruppen doesn't need any folding. This violates this
constraint imposed by ASCIIFoldingFilterFactory being
"MultiTermAware", which means if it emits two tokens it barfs.

You do not need to set "preserveOriginal='true' " in your _query_
chain since your indexing chain puts both the folded and un-folded
versions in the index at the same position.

So I think if you set perserveOriginal to false (again, in the _query_
analysis chain, leave it true in the index analysis chain) you'll be
OK. Your queries will also be somewhat faster.

Best,
Erick

On Wed, Jun 28, 2017 at 6:25 AM, Preeti Bhat  wrote:
> Hi All,
>
> I have a requirement where the user can give an Unicode or ascii character as 
> input but expects same result.
>
> For example: MöllerGruppen AS vs MollerGruppen AS should give out same result.
>
> I am able to get this done using  class="solr.ASCIIFoldingFilterFactory" preserveOriginal="true"/>, but due to 
> some reason when it try to do MöllerGruppen* I am getting the below message.
>
> ""metadata":[
>   "error-class","org.apache.solr.common.SolrException",
>   "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"analyzer returned too many terms for multiTerm term: 
> MöllerGruppen",
> "code":400}}
> "
>
> It works for MollerGruppen* though.
>
> Could someone please advise on this.
>
> Below is the fieldtype of this field.
>
> 
> 
> 
>   
>   
>preserveOriginal="true"/>
>   
>ignoreCase="true"/>
>generateWordParts="1" splitOnCaseChange="0" catenateWords="1" 
> splitOnNumerics="0" stemEnglishPossessive="0" preserveOriginal="1"/>
> 
> 
> 
>   
>   
>preserveOriginal="true"/>
>   
>ignoreCase="true"/>
>generateWordParts="1" splitOnCaseChange="0" catenateWords="1" 
> splitOnNumerics="0" stemEnglishPossessive="0" preserveOriginal="1"/>
> 
>   
>
>
>
> Thanks and Regards,
> Preeti
>
>
>
> NOTICE TO RECIPIENTS: This communication may contain confidential and/or 
> privileged information. If you are not the intended recipient (or have 
> received this communication in error) please notify the sender and 
> it-supp...@shoregrp.com immediately, and destroy this communication. Any 
> unauthorized copying, disclosure or distribution of the material in this 
> communication is strictly forbidden. Any views or opinions presented in this 
> email are solely those of the author and do not necessarily represent those 
> of the company. Finally, the recipient should check this email and any 
> attachments for the presence of viruses. The company accepts no liability for 
> any damage caused by any virus transmitted by this email.
>
>

Re: Polygon search query working but NOT Multipolygon

[David Smiley]

https://lucene.apache.org/solr/guide/6_6/spatial-search.html#SpatialSearch-RptWithGeometrySpatialField
 



> On Jun 28, 2017, at 11:32 AM, puneeta  wrote:
> 
> Hi David,
> I am sorry ,I did not understand what do you mean by "I suggest using
> RptWithGeometry field". Should leave the existing location_rpt definition in
> schema.xml?
>  class="solr.SpatialRecursivePrefixTreeFieldType"
>   geo="true" distErrPct="0.025" maxDistErr="0.001"
> distanceUnits="kilometers" />
> This line I have commented. Should I uncomment it?
> 
> 1."remove distErrPct and maxDistErr" - 
> 2.Added usejtsMulti="false"
> 
> I will change the  field definition as follows, try to execute and report
> back.
>class="solr.SpatialRecursivePrefixTreeFieldType" 
> 
> jts*="org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory" 
>  autoIndex="true"
>  validationRule="repairBuffer0"
>  distanceUnits="kilometers" 
>  *useJtsMulti="false"*/> 
> 
> 
> The issue I am facing is that the I am not getting the search result for
> Multipolygon i.e I should get hits.Currently, the numFound = 0, It should
> find atleast 1 record as it does for a Polygon search.
> 
> Thanks,
> Puneeta
> 
> david.w.smi...@gmail.com  wrote
>> I suggest using RptWithGeometry field, and with that change remove
>> distErrPct and maxDistErr.  See the ref guide, and note the geometry cache
>> option.
>> BTW spatialContextFactory can simply be "jts".
>> 
>> If this fixes the issue, then the issue was related to grid approximation.
>> 
>> BTW you never quite said what it was about the results that was wrong. 
>> Did you get hits you didn't expect (I'm guessing yes) or the inverse?
>> 
>> ~ David
>> 
>>> On Jun 28, 2017, at 10:55 AM, puneeta 
> 
>> pverma@
> 
>>  wrote:
>>> 
>>> Hi David,
>>> Thank you for the prompt reply. My field definition in schema.xml is :
>>> 
>>> I commented the existing location_rpt
>>> 
>>> 
>>> 
>>> And added:
>>> 
>> >> 
>> class="solr.SpatialRecursivePrefixTreeFieldType"
>>> 
>>> spatialContextFactory="org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory"
>>>  autoIndex="true"
>>>  validationRule="repairBuffer0"
>>>  distErrPct="0.025"
>>>  maxDistErr="0.001"
>>>  distanceUnits="kilometers" />
>>> 
>>> My Solr version is 6.2.1
>>> 
>>> Thanks,
>>> Puneeta
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>>> http://lucene.472066.n3.nabble.com/Polygon-search-query-working-but-NOT-Multipolygon-tp4343143p4343162.html
>>> Sent from the Solr - User mailing list archive at Nabble.com.
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://lucene.472066.n3.nabble.com/Polygon-search-query-working-but-NOT-Multipolygon-tp4343143p4343184.html
>  
> 
> Sent from the Solr - User mailing list archive at Nabble.com 
> .

Re: Solr 5.5 - spatial intersects query returns results outside of search box

[David Smiley]

No prob.

BTW you may want to investigate use of BBoxField or 
RptWithGeometrySpatialField; both are also more accurate... but vanilla RPT may 
be just fine (fastest).


> On Jun 28, 2017, at 11:32 AM, Leila Gonzales  wrote:
> 
> Thanks David! I fixed the coordinates and put some error checking in my
> Solr indexing script to trap for this type of coordinate mismatch.
> 
> -Original Message-
> From: David Smiley [mailto:david.w.smi...@gmail.com]
> Sent: Wednesday, June 28, 2017 8:21 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Solr 5.5 - spatial intersects query returns results outside
> of search box
> 
> 
>> On Jun 27, 2017, at 3:28 AM, Leila Gonzales  wrote:
>> 
>> {
>> 
>>   "id": "5230",
>> 
>>   "location_geo":
>> 
> ["ENVELOPE(-75.0,-75.939723,39.3597224,38.289722)"
> ]
>> 
>> }
> 
> This is an unusual rectangle.  Remember this is minX, maxX, maxY, minY.
> Thus this rectangle wraps the entire globe except for nearly a degree.  It
> matches your query rectangle.

Re: Polygon search query working but NOT Multipolygon

[puneeta]

Hi David,
 I am sorry ,I did not understand what do you mean by "I suggest using
RptWithGeometry field". Should leave the existing location_rpt definition in
schema.xml?

This line I have commented. Should I uncomment it?

1."remove distErrPct and maxDistErr" - 
2.Added usejtsMulti="false"

I will change the  field definition as follows, try to execute and report
back.
jts*="org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory" 
   autoIndex="true"
   validationRule="repairBuffer0"
   distanceUnits="kilometers" 
   *useJtsMulti="false"*/> 


The issue I am facing is that the I am not getting the search result for
Multipolygon i.e I should get hits.Currently, the numFound = 0, It should
find atleast 1 record as it does for a Polygon search.

Thanks,
Puneeta

david.w.smi...@gmail.com wrote
> I suggest using RptWithGeometry field, and with that change remove
> distErrPct and maxDistErr.  See the ref guide, and note the geometry cache
> option.
> BTW spatialContextFactory can simply be "jts".
> 
> If this fixes the issue, then the issue was related to grid approximation.
> 
> BTW you never quite said what it was about the results that was wrong. 
> Did you get hits you didn't expect (I'm guessing yes) or the inverse?
> 
> ~ David
> 
>> On Jun 28, 2017, at 10:55 AM, puneeta 

> pverma@

>  wrote:
>> 
>> Hi David,
>> Thank you for the prompt reply. My field definition in schema.xml is :
>> 
>> I commented the existing location_rpt
>> 
>> 
>> 
>> And added:
>> 
> >
>  class="solr.SpatialRecursivePrefixTreeFieldType"
>> 
>> spatialContextFactory="org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory"
>>   autoIndex="true"
>>   validationRule="repairBuffer0"
>>   distErrPct="0.025"
>>   maxDistErr="0.001"
>>   distanceUnits="kilometers" />
>> 
>> My Solr version is 6.2.1
>> 
>> Thanks,
>> Puneeta
>> 
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://lucene.472066.n3.nabble.com/Polygon-search-query-working-but-NOT-Multipolygon-tp4343143p4343162.html
>> Sent from the Solr - User mailing list archive at Nabble.com.





--
View this message in context: 
http://lucene.472066.n3.nabble.com/Polygon-search-query-working-but-NOT-Multipolygon-tp4343143p4343184.html
Sent from the Solr - User mailing list archive at Nabble.com.

RE: Solr 5.5 - spatial intersects query returns results outside of search box

[Leila Gonzales]

Thanks David! I fixed the coordinates and put some error checking in my
Solr indexing script to trap for this type of coordinate mismatch.

-Original Message-
From: David Smiley [mailto:david.w.smi...@gmail.com]
Sent: Wednesday, June 28, 2017 8:21 AM
To: solr-user@lucene.apache.org
Subject: Re: Solr 5.5 - spatial intersects query returns results outside
of search box


> On Jun 27, 2017, at 3:28 AM, Leila Gonzales  wrote:
>
> {
>
>"id": "5230",
>
>"location_geo":
>
["ENVELOPE(-75.0,-75.939723,39.3597224,38.289722)"
]
>
>  }

This is an unusual rectangle.  Remember this is minX, maxX, maxY, minY.
Thus this rectangle wraps the entire globe except for nearly a degree.  It
matches your query rectangle.

Re: Solr 5.5 - spatial intersects query returns results outside of search box

[David Smiley]

> On Jun 27, 2017, at 3:28 AM, Leila Gonzales  wrote:
> 
> {
> 
>"id": "5230",
> 
>"location_geo":
> ["ENVELOPE(-75.0,-75.939723,39.3597224,38.289722)"]
> 
>  }

This is an unusual rectangle.  Remember this is minX, maxX, maxY, minY.  Thus 
this rectangle wraps the entire globe except for nearly a degree.  It matches 
your query rectangle.

Re: Polygon search query working but NOT Multipolygon

[David Smiley]

I suggest using RptWithGeometry field, and with that change remove distErrPct 
and maxDistErr.  See the ref guide, and note the geometry cache option.
BTW spatialContextFactory can simply be "jts".

If this fixes the issue, then the issue was related to grid approximation.

BTW you never quite said what it was about the results that was wrong.  Did you 
get hits you didn't expect (I'm guessing yes) or the inverse?

~ David

> On Jun 28, 2017, at 10:55 AM, puneeta  wrote:
> 
> Hi David,
> Thank you for the prompt reply. My field definition in schema.xml is :
> 
> I commented the existing location_rpt
> 
> 
> 
> And added:
>  class="solr.SpatialRecursivePrefixTreeFieldType"
> 
> spatialContextFactory="org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory"
>   autoIndex="true"
>   validationRule="repairBuffer0"
>   distErrPct="0.025"
>   maxDistErr="0.001"
>   distanceUnits="kilometers" />
> 
> My Solr version is 6.2.1
> 
> Thanks,
> Puneeta
> 
> 
> 
> 
> --
> View this message in context: 
> http://lucene.472066.n3.nabble.com/Polygon-search-query-working-but-NOT-Multipolygon-tp4343143p4343162.html
> Sent from the Solr - User mailing list archive at Nabble.com.

Re: Polygon search query working but NOT Multipolygon

[puneeta]

Hi David,
 Thank you for the prompt reply. My field definition in schema.xml is :

I commented the existing location_rpt



And added:


My Solr version is 6.2.1

Thanks,
Puneeta




--
View this message in context: 
http://lucene.472066.n3.nabble.com/Polygon-search-query-working-but-NOT-Multipolygon-tp4343143p4343162.html
Sent from the Solr - User mailing list archive at Nabble.com.

Boost(bq) with Block Join Query Praser

[Ratna]

Hi all,

We are having Nested Documents. We want similar kind of  function like
'bq'(Edismax) with Block Join Query parser.  Can you please provide some
inputs  to achieve boost within result set based on some attribute in Solr. 



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Boost-bq-with-Block-Join-Query-Praser-tp4343156.html
Sent from the Solr - User mailing list archive at Nabble.com.

Using asterik(*) with unicode characters.

[Preeti Bhat]

Hi All,

I have a requirement where the user can give an Unicode or ascii character as 
input but expects same result.

For example: MöllerGruppen AS vs MollerGruppen AS should give out same result.

I am able to get this done using , but due to some reason when it try to do 
MöllerGruppen* I am getting the below message.

""metadata":[
  "error-class","org.apache.solr.common.SolrException",
  "root-error-class","org.apache.solr.common.SolrException"],
"msg":"analyzer returned too many terms for multiTerm term: MöllerGruppen",
"code":400}}
"

It works for MollerGruppen* though.

Could someone please advise on this.

Below is the fieldtype of this field.




  
  
  
  
  
  



  
  
  
  
  
  

  



Thanks and Regards,
Preeti



NOTICE TO RECIPIENTS: This communication may contain confidential and/or 
privileged information. If you are not the intended recipient (or have received 
this communication in error) please notify the sender and 
it-supp...@shoregrp.com immediately, and destroy this communication. Any 
unauthorized copying, disclosure or distribution of the material in this 
communication is strictly forbidden. Any views or opinions presented in this 
email are solely those of the author and do not necessarily represent those of 
the company. Finally, the recipient should check this email and any attachments 
for the presence of viruses. The company accepts no liability for any damage 
caused by any virus transmitted by this email.

Re: Polygon search query working but NOT Multipolygon

[David Smiley]

Hi Puneeta,

So what does your field type definition look like?  I'd imagine you're using 
RptWithGeometrySpatialField.  And what is your Solr version?

BTW note the settings here 
https://locationtech.github.io/spatial4j/apidocs/org/locationtech/spatial4j/context/jts/JtsSpatialContextFactory.html
 

  are reflected as attributes on the field type, thus you can set say 
useJtsMulti="false" to change the 'multi implementation.

~ David

> On Jun 28, 2017, at 6:44 AM, puneeta  wrote:
> 
> Hi,
> I am new to Solr Geospatial data and have set up JTS within solr. I have
> geo spatial data with Multipolygons. I am passing the coordinates and trying
> to find out which multipolygon contains those coordinates.However, The
> search query is working fine if I insert the data as a polygon. The same is
> not working if my data is inserted as a Multipolygon. I am unable to figure
> out what am I missing. Can anyone suggest where am I going wrong?
> 
> Data as Polygon:
> { "parcel_id":"6",
>"geo":["POLYGON((-86.452970463 32.449739005, 
>  -86.452889912 32.4494390510001, 
>  -86.453365379 32.44942802195, 
>  -86.453514854 32.44942453595))"]
> }
> 
> Data as Multipolygon:
> 
> { "parcel_id":"6",
>"geo":["MULTIPOLYGON(((-86.452970463 32.449739005, 
>  -86.452889912 32.4494390510001, 
>  -86.453365379 32.44942802195, 
>  -86.453514854 32.44942453595)))"]
> }
> 
> My search query:
> fq=geo:"Intersects(-86.453097892 32.449735102)"
> 
> This device surely lies between the polygon (My polygon coordinates are many
> more in the actual data. To reduce the size here I have omited few of the
> coordinates)
> 
> The query is returning only the polygon data. The multipolygon search is not
> happening.
> 
> Any help is highly appreciated.
> 
> Thanks in Advance,
> Puneeta
> 
> 
> 
> --
> View this message in context: 
> http://lucene.472066.n3.nabble.com/Polygon-search-query-working-but-NOT-Multipolygon-tp4343143.html
> Sent from the Solr - User mailing list archive at Nabble.com.

Polygon search query working but NOT Multipolygon

[puneeta]

Hi,
 I am new to Solr Geospatial data and have set up JTS within solr. I have
geo spatial data with Multipolygons. I am passing the coordinates and trying
to find out which multipolygon contains those coordinates.However, The
search query is working fine if I insert the data as a polygon. The same is
not working if my data is inserted as a Multipolygon. I am unable to figure
out what am I missing. Can anyone suggest where am I going wrong?

Data as Polygon:
 { "parcel_id":"6",
"geo":["POLYGON((-86.452970463 32.449739005, 
  -86.452889912 32.4494390510001, 
  -86.453365379 32.44942802195, 
  -86.453514854 32.44942453595))"]
}

Data as Multipolygon:

 { "parcel_id":"6",
"geo":["MULTIPOLYGON(((-86.452970463 32.449739005, 
  -86.452889912 32.4494390510001, 
  -86.453365379 32.44942802195, 
  -86.453514854 32.44942453595)))"]
}

My search query:
fq=geo:"Intersects(-86.453097892 32.449735102)"

This device surely lies between the polygon (My polygon coordinates are many
more in the actual data. To reduce the size here I have omited few of the
coordinates)

The query is returning only the polygon data. The multipolygon search is not
happening.

Any help is highly appreciated.

Thanks in Advance,
Puneeta



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Polygon-search-query-working-but-NOT-Multipolygon-tp4343143.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Dynamic fields vs parent child

[Rick Leir]

Saurabh

Maybe you need two fields. The first field is named "keyName" and the 
second is "keyValue". Give that a try, though searching with AND may be 
a challenge.


Otherwise, use one field named "whatever" containing "key-value", 
assuming '-' never appears in keys or values. Search for an exact match.


cheers -- Rick


On 2017-06-27 03:56 PM, Susheel Kumar wrote:

Do you have any close count of how many max dynamic fields you may have
(1k, 2k or 3k etc.). In one of our index we have a total around 2K dynamic
fields across all documents.

My suggestion would be to try out dynamic fields for the use case you are
describing and do some real performance test.

Thanks,
Susheel

On Tue, Jun 27, 2017 at 3:01 PM, Saurabh Sethi 
wrote:


We have key-value pairs that need to be searchable. We are looking for best
approach, both in terms of indexing (fast as well as space efficient) as
well as retrieval (fast search).

Right now, the two approaches that we have are: Nested docs or dynamic
fields (myField_*_time:some date)

The number of dynamic fields would definitely be > 1k.

We wanted to get an idea which of these approaches work best or if there a
third approach which is better than nested and dynamic fields.

On Tue, Jun 27, 2017 at 5:39 AM, Susheel Kumar 
wrote:


Can you describe your use case in terms of what business functionality

you

are looking to achieve.

Thanks,
Susheel

On Mon, Jun 26, 2017 at 4:26 PM, Saurabh Sethi <

saurabh.se...@sendgrid.com

wrote:


Number of dynamic fields will be in thousands (millions of users +
thousands of events shared between subsets of users).

We also thought about indexing in one field with value being
fieldname_fieldvalue. Since we support range queries for dates and

numbers,

it won't work out of box.

On Mon, Jun 26, 2017 at 1:05 PM, Erick Erickson <

erickerick...@gmail.com

wrote:


How many distinct fields do you expect across _all_ documents? That
is, if doc1 has 10 dynamic fields and doc2 has 10 dynamic fields,

will

there be exactly 10 fields total or more than 10 when you consider
both documents?

100s of fields total across all documents is a tractable problem.
thousands of dynamic fields total is going to be a problem.

One technique that people do use is to index one field with a prefix
rather than N dynamic fields. So you have something like
dyn1_val1
dyn1_val2
dyn4_val67

Only really works with string fields of course.

Best,
Erick

On Mon, Jun 26, 2017 at 10:11 AM, Saurabh Sethi
 wrote:

We have two requirements:

1. Indexing and storing event id and its timestamp.
2. Indexing and storing custom field name and value. The fields can

be

of

any type, but for now lets say they are of types string, date and

number.

The events and custom fields for any solr document can easily be in
hundreds.

We are looking at two different approaches to handle these

scenarios:

1. *Dynamic fields* - Have the fields name start with a particular

pattern

like for string, the pattern could be like str_* and for event

could

be

eventid_*
2. *Parent/child fields* - This seems to be an overkill for our use

case

since it's more for hierarchical data. Also, the parent and all its
children need to be reindexed on update which defeats the purpose -

we

are

now reindexing multiple docs instead of one with dynamic fields.

But

it

allows us to store custom field name along with its value unlike

dynamic

fields where we will have to map user supplied custom field to some

other

name based on type.

Has anyone handled similar scenarios with Solr? If so, which

approach

would

you recommend based on your experience?

We are using solr 6.6

Thanks,
Saurabh



--
Saurabh Sethi
Principal Engineer I | Engineering




--
Saurabh Sethi
Principal Engineer I | Engineering

master slave replication taking time

[Midas A]

Hi,

we have around 2000 documents and our master to slave replication is
taking time  upto 20 second.

What should i check ?