from:"David Smiley \(JIRA\)"

[jira] [Commented] (LUCENE-4342) Issues with prefix tree's Distance Error Percentage

2012-09-04 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447823#comment-13447823
 ] 

David Smiley commented on LUCENE-4342:
--

Committed to 4x (r1380740) and trunk (r1380739)

 Issues with prefix tree's Distance Error Percentage 
 

 Key: LUCENE-4342
 URL: https://issues.apache.org/jira/browse/LUCENE-4342
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Affects Versions: 4.0-ALPHA, 4.0-BETA
Reporter: Itamar Syn-Hershko
Assignee: David Smiley
 Fix For: 4.0

 Attachments: 
 LUCENE-4342_errant_+1_in_spatial_prefix_tree_factory_getLevelForDistance().patch,
  
 LUCENE-4342_fix_distance_precision_lookup_for_prefix_trees,_and_modify_the_default_algorit.patch,
  unnamed.patch


 See attached patch for a failing test
 Basically, it's a simple point and radius scenario that works great as long 
 as args.setDistPrecision(0.0); is called. Once the default precision is used 
 (2.5%), it doesn't work as expected.
 The distance between the 2 points in the patch is 35.75 KM. Taking into 
 account the 2.5% error the effective radius without false negatives/positives 
 should be around 34.8 KM. This test fails with a radius of 33 KM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4186) Lucene spatial's distErrPct is treated as a fraction, not a percent.

2012-09-05 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley updated LUCENE-4186:
-

Attachment: LUCENE-4186_distErrPct_upgrade.patch

This patch does a lot of things:
* SpatialArgs.toString()'s logic was moved to SpatialArgsParser as
writeSpatialArgs(args) since it looks so close to the parsed format and I'd
like to see it parsed and written in the same class.
* SpatialArgs.toString() fixes the bug in displaying the error percent that
Itamar noticed.
* Standardizes distErrPct terminology in variables and method names. Despite
the pct it's actually a fraction [0 to 0.5].
* Refactored out the logic that takes a shape and distErrPct and determines an
actual distance. It was moved from SpatialPrefixTree to SpatialArgs as a static
method calcDistanceFromErrPct(...). I don't particularly love it at
SpatialArgs but I can't think of a better place.
* Instead of SpatialArgs.distErrPct defaulting to 0.025 it defaults to null.
Now the Strategy's own distErrPct (which defaults to 0.025) is supplied to
args.resolveDistErr(...) so it can see if the args overrides the one in
strategy or not.
* SpatialArgs gains a distErr field, parsed from SpatialArgsParser. This is
an alternative means that a search request can specify the distance in a more
direct way.

One thing I didn't do, is move the distErrPct getter setter up from
PrefixTreeStrategy to the base SpatialStrategy. Given more recent discussions
about the SpatialStrategy's role, I'm torn on wether it should have options
that only one strategy will use, given what we have now.

Lucene spatial's distErrPct is treated as a fraction, not a percent.
--

Key: LUCENE-4186
URL: https://issues.apache.org/jira/browse/LUCENE-4186
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Priority: Critical
Fix For: 4.0

Attachments: LUCENE-4186_distErrPct_upgrade.patch

The distance-error-percent of a query shape in Lucene spatial is, in a
nutshell, the percent of the shape's area that is an error epsilon when
considering search detail at its edges. The default is 2.5%, for reference.
However, as configured, it is read in as a fraction:
{code:xml}
fieldType name=location_2d_trie
class=solr.SpatialRecursivePrefixTreeFieldType
distErrPct=0.025 maxDetailDist=0.001 /
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4186) Lucene spatial's distErrPct is treated as a fraction, not a percent.

2012-09-05 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448784#comment-13448784
]

David Smiley commented on LUCENE-4186:
--

bq. +1 Do we validate somewhere that the values are between 0 and 0.5?

Yes.

bq. If I understand correctly, your motivation for doing this is so in the
default scenario (when no pct is defined) you have the same value at both index
time and query time, correct?

Yes.

bq. I'm starting to wonder whether it makes sense to allow the value to be set
per request. Having the same value at both index and query time seems ideal so
perhaps we should force the value, whether it be the pct or absolute value, be
provided at construction of the Strategy.

IMO it's quite useful to have the request specifically indicate either
distErrPct or distErr directly. I think it would be completely unworkable to
have no query-time override and fix the percentage on the strategy. It'd be
nice if this could be done at index time too but I'm not sure how it would fit
into the API. Maybe an overloaded createIndexableFields(shape,distErr)?

bq. So can the user now provide either the the distErr or distErrPct and if
they provide the later, it is converted to the former seamlessly? Or must the
user do the conversion themselves? I'm +1 for the first option.

Yeah, it's seamlessly converted when the strategy calls
args.resolveDistErr(...). The user definitely does not do any conversion
themselves.

Lucene spatial's distErrPct is treated as a fraction, not a percent.
--

Attachments: LUCENE-4186_distErrPct_upgrade.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4351) Upgrade Spatial4j to 0.3

2012-09-05 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448968#comment-13448968
 ] 

David Smiley commented on LUCENE-4351:
--

Thanks Scott.
I committed to trunk in 4 commits: 1381230, 34, 58, 79.  And all these merged 
to 4x branch in commit 1381280.

There was a test failure reported by Jenkins for 
TestRecursivePrefixTreeStrategy.geohashRecursiveRandom().  I marked it @Ignored 
right now but will fix whatever the problem is and then I will close.

 Upgrade Spatial4j to 0.3
 

 Key: LUCENE-4351
 URL: https://issues.apache.org/jira/browse/LUCENE-4351
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0

 Attachments: LUCENE-4351_Spatial4j_0_3.patch, 
 LUCENE-4351_Spatial4j_0_3.patch


 This version of Spatial4j has various API level improvements.  It features 
 dateline wrap for polygons.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4186) Lucene spatial's distErrPct is treated as a fraction, not a percent.

2012-09-06 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450317#comment-13450317
 ] 

David Smiley commented on LUCENE-4186:
--

After some interesting discussion in chat, proliferating SpatialArgs here is 
not the way to go.  Instead, PrefixTreeStrategy can be overloaded to take the 
distErr.

The subject of this issue is also now wrong, and I'll change it.  Even though 
distErrPct is technically input as a fraction instead of a percent, it'll stay 
that way.

 Lucene spatial's distErrPct is treated as a fraction, not a percent.
 --

 Key: LUCENE-4186
 URL: https://issues.apache.org/jira/browse/LUCENE-4186
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Priority: Critical
 Fix For: 4.0

 Attachments: LUCENE-4186_distErrPct_upgrade.patch


 The distance-error-percent of a query shape in Lucene spatial is, in a 
 nutshell, the percent of the shape's area that is an error epsilon when 
 considering search detail at its edges.  The default is 2.5%, for reference.  
 However, as configured, it is read in as a fraction:
 {code:xml}
 fieldType name=location_2d_trie 
 class=solr.SpatialRecursivePrefixTreeFieldType
distErrPct=0.025 maxDetailDist=0.001 /
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4186) Overhaul Lucene spatial's distErrPct

2012-09-06 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-4186:
-

Summary: Overhaul Lucene spatial's distErrPct  (was: Lucene spatial's 
distErrPct is treated as a fraction, not a percent.)

 Overhaul Lucene spatial's distErrPct
 --

 Key: LUCENE-4186
 URL: https://issues.apache.org/jira/browse/LUCENE-4186
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Priority: Critical
 Fix For: 4.0

 Attachments: LUCENE-4186_distErrPct_upgrade.patch


 The distance-error-percent of a query shape in Lucene spatial is, in a 
 nutshell, the percent of the shape's area that is an error epsilon when 
 considering search detail at its edges.  The default is 2.5%, for reference.  
 However, as configured, it is read in as a fraction:
 {code:xml}
 fieldType name=location_2d_trie 
 class=solr.SpatialRecursivePrefixTreeFieldType
distErrPct=0.025 maxDetailDist=0.001 /
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4186) Overhaul Lucene spatial's distErrPct

2012-09-06 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-4186:
-

Attachment: LUCENE-4186_distErrPct_upgrade.patch

I updated the patch to add a 
PrefixTreeStrategy.createIndexedFields(shape,distErr) specialization, and 
accounted for the Spatial4j 0.3 update.

I plan to commit this sometime tomorrow.

 Overhaul Lucene spatial's distErrPct
 --

 Key: LUCENE-4186
 URL: https://issues.apache.org/jira/browse/LUCENE-4186
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Priority: Critical
 Fix For: 4.0

 Attachments: LUCENE-4186_distErrPct_upgrade.patch, 
 LUCENE-4186_distErrPct_upgrade.patch


 The distance-error-percent of a query shape in Lucene spatial is, in a 
 nutshell, the percent of the shape's area that is an error epsilon when 
 considering search detail at its edges.  The default is 2.5%, for reference.  
 However, as configured, it is read in as a fraction:
 {code:xml}
 fieldType name=location_2d_trie 
 class=solr.SpatialRecursivePrefixTreeFieldType
distErrPct=0.025 maxDetailDist=0.001 /
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3312) Break out StorableField from IndexableField

2012-09-07 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13451238#comment-13451238
 ] 

David Smiley commented on LUCENE-3312:
--

Uwe, can you please explain why you changed 
SpatialStrategy.createIndexableFields to return Field[] instead of 
IndexableField[]?  As its name suggests and as the javadocs go to some lengths 
to clarify, createIndexableFields is for indexed data and not storing it.  
Field implements StorableField.

 Break out StorableField from IndexableField
 ---

 Key: LUCENE-3312
 URL: https://issues.apache.org/jira/browse/LUCENE-3312
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/index
Reporter: Michael McCandless
Assignee: Nikola Tankovic
  Labels: gsoc2012, lucene-gsoc-12
 Fix For: 5.0

 Attachments: LUCENE-3312-DocumentIterators-uwe.patch, 
 lucene-3312-patch-01.patch, lucene-3312-patch-02.patch, 
 lucene-3312-patch-03.patch, lucene-3312-patch-04.patch, 
 lucene-3312-patch-05.patch, lucene-3312-patch-06.patch, 
 lucene-3312-patch-07.patch, lucene-3312-patch-08.patch, 
 lucene-3312-patch-09.patch, lucene-3312-patch-10.patch, 
 lucene-3312-patch-11.patch, lucene-3312-patch-12a.patch, 
 lucene-3312-patch-12.patch, lucene-3312-patch-13.patch, 
 lucene-3312-patch-14.patch, LUCENE-3312-reintegration.patch, 
 LUCENE-3312-reintegration.patch


 In the field type branch we have strongly decoupled
 Document/Field/FieldType impl from the indexer, by having only a
 narrow API (IndexableField) passed to IndexWriter.  This frees apps up
 use their own documents instead of the user-space impls we provide
 in oal.document.
 Similarly, with LUCENE-3309, we've done the same thing on the
 doc/field retrieval side (from IndexReader), with the
 StoredFieldsVisitor.
 But, maybe we should break out StorableField from IndexableField,
 such that when you index a doc you provide two Iterables -- one for the
 IndexableFields and one for the StorableFields.  Either can be null.
 One downside is possible perf hit for fields that are both indexed 
 stored (ie, we visit them twice, lookup their name in a hash twice,
 etc.).  But the upside is a cleaner separation of concerns in API

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-4186) Overhaul Lucene spatial's distErrPct

2012-09-07 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved LUCENE-4186.
--

Resolution: Fixed

Committed to trunk r1382231 and 4x r1382235.

 Overhaul Lucene spatial's distErrPct
 --

 Key: LUCENE-4186
 URL: https://issues.apache.org/jira/browse/LUCENE-4186
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Priority: Critical
 Fix For: 4.0

 Attachments: LUCENE-4186_distErrPct_upgrade.patch, 
 LUCENE-4186_distErrPct_upgrade.patch


 The distance-error-percent of a query shape in Lucene spatial is, in a 
 nutshell, the percent of the shape's area that is an error epsilon when 
 considering search detail at its edges.  The default is 2.5%, for reference.  
 However, as configured, it is read in as a fraction:
 {code:xml}
 fieldType name=location_2d_trie 
 class=solr.SpatialRecursivePrefixTreeFieldType
distErrPct=0.025 maxDetailDist=0.001 /
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-4351) Upgrade Spatial4j to 0.3

2012-09-08 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved LUCENE-4351.
--

Resolution: Fixed

I fixed the edge case in the test (both branches) and removed the @Ignore 
annotation.  Marking as closed.

 Upgrade Spatial4j to 0.3
 

 Key: LUCENE-4351
 URL: https://issues.apache.org/jira/browse/LUCENE-4351
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0

 Attachments: LUCENE-4351_Spatial4j_0_3.patch, 
 LUCENE-4351_Spatial4j_0_3.patch


 This version of Spatial4j has various API level improvements.  It features 
 dateline wrap for polygons.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4208) Spatial distance relevancy should use score of 1/distance

2012-09-08 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13451462#comment-13451462
]

David Smiley commented on LUCENE-4208:
--

I have some in-progress code I need to finish, then post as a patch.

I think the most important thing is for the strategies to expose the distance
as a ValueSource. This is the case currently with PrefixTreeStrategy and
TwoDoublesStrategy. With this, you can do what you want -- inverse reciprocal
distance or whatever. By default, I'd like a Query's score to be something
like that and this is what this issue is about, but even without it you could
do something like:
{code}
new FilteredQuery(new FunctionQuery(myValueSource),
spatialStrategy.makeFilter(...))
{code}

Spatial distance relevancy should use score of 1/distance
-

Key: LUCENE-4208
URL: https://issues.apache.org/jira/browse/LUCENE-4208
Project: Lucene - Core
Issue Type: New Feature
Components: modules/spatial
Reporter: David Smiley
Fix For: 4.0

The SpatialStrategy.makeQuery() at the moment uses the distance as the score
(although some strategies -- TwoDoubles if I recall might not do anything
which would be a bug). The distance is a poor value to use as the score
because the score should be related to relevancy, and the distance itself is
inversely related to that. A score of 1/distance would be nice. Another
alternative is earthCircumference/2 - distance, although I like 1/distance
better. Maybe use a different constant than 1.
Credit: this is Chris Male's idea.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3304) Add Solr support for the new Lucene spatial module

2012-09-11 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley updated SOLR-3304:
---

Attachment: SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch

Thanks for finding and fixing that bug Andy. Your fix wasn't quite right though
since the getStrategy() method you refactored synchronized on a parameter
(pointless) instead of the field. I fixed this.

This new patch makes that and various other changes:
* synchronized with the latest source tree (e.g. Spatial4j 0.3)
** This means distances are now degrees based (0-180 for circle radius) not
kilometers
* removed ignoreIncompatibleGeometry option (see LUCENE-4173)
* Use the input string as the stored value that is returned. So if you give
lat,lon then that's what you get back, in whatever number of decimal places
you chose.
* added prefixGridScanLevel performance tuning option to
SpatialRecursivePrefixTreeFieldType (simply exposed it from the strategy)
* keep distErrPct as a fraction (no change)

It would be nice to have a kilometer unit option but that isn't easily done
until Spatial4j's shape reader gets to be more flexible. That can wait.

That needScore local-param hack (see SOLR-2883) is unfortunate, as Solr can't
get a Filter from a field type. I'm tempted to change the default to 'false'
as leaving it at true' triggers large RAM requirements and slow-downs for
SpatialRecursivePrefixTreeFieldType. This could be an opportunity to specify
what the score should be, come to think of it. Instead of needScore=false,
maybe score=none (default) or score=distance or score=recipDistance or
something like that.

The TwoDoubles strategy needs more attention and tests in Lucene spatial, but I
don't want that to hold up this patch. Shall I remove the adapter or let it
get committed but don't advertise it until it's more worthy?

Add Solr support for the new Lucene spatial module
--

Key: SOLR-3304
URL: https://issues.apache.org/jira/browse/SOLR-3304
Project: Solr
Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Bill Bell
Assignee: David Smiley
Labels: spatial
Attachments: SOLR-3304_Solr_fields_for_Lucene_spatial_module
(fieldName in Strategy) - indexableFields.patch,
SOLR-3304_Solr_fields_for_Lucene_spatial_module (fieldName in
Strategy).patch, SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch,
SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch,
SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch,
SOLR-3304-strategy-getter-fixed.patch

Get the Solr spatial module integrated with the lucene spatial module.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4197) Small improvements to Lucene Spatial Module for v4

2012-09-11 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453133#comment-13453133
 ] 

David Smiley commented on LUCENE-4197:
--

committed removal of PrefixCellsTokenizer

 Small improvements to Lucene Spatial Module for v4
 --

 Key: LUCENE-4197
 URL: https://issues.apache.org/jira/browse/LUCENE-4197
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
 Fix For: 4.0

 Attachments: LUCENE-4197_rename_CachedDistanceValueSource.patch, 
 LUCENE-4197_SpatialArgs_doesn_t_need_overloaded_toString()_with_a_ctx_param_.patch,
  SpatialArgs-_remove_unused_min_and_max_params.patch


 This issue is to capture small changes to the Lucene spatial module that 
 don't deserve their own issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-4373) BBoxStrategy should support query shapes of any type

2012-09-11 Thread David Smiley (JIRA)

David Smiley created LUCENE-4373:


 Summary: BBoxStrategy should support query shapes of any type
 Key: LUCENE-4373
 URL: https://issues.apache.org/jira/browse/LUCENE-4373
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Priority: Minor


It's great that BBoxStrategy has sophisticated shape area similarity based on 
bounding box, but I think that doesn't have to preclude having a 
non-rectangular query shape.  The bbox to bbox query implemented already is 
probably pretty pretty fast as can work by numeric range queries, but I'd like 
this to be the first stage of which the 2nd is a FieldCache based comparison to 
the query shape if it's not a rectangle.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-4374) Spatial- rename vector.TwoDoublesStrategy to vector.PointVectorStrategy

2012-09-11 Thread David Smiley (JIRA)

David Smiley created LUCENE-4374:


 Summary: Spatial- rename vector.TwoDoublesStrategy to 
vector.PointVectorStrategy
 Key: LUCENE-4374
 URL: https://issues.apache.org/jira/browse/LUCENE-4374
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
 Fix For: 4.0


TwoDoubles isn't necessarily appropriate since it could be two floats, once it 
is enhanced to make that configurable.  I like PointVector because it's clear 
it indexes points.  Eventually I could imagine a CircleVectorStrategy in the 
same package.

This does suggest BBoxStrategy should be RectVectorStrategy in the vector 
package.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4173) Remove IgnoreIncompatibleGeometry for SpatialStrategys

2012-09-11 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley updated LUCENE-4173:
-

Attachment:
LUCENE-4173_remove_ignoreIncompatibleGeometry,_fail_when_given_the_exact_shape_needed.patch

This patch removes ignoreIncompatibleGeometry and modified the strategies to
fail when given a shape that isn't the precise shape used -- no coalescing.
BBox TwoDoubles were both doing coalescing (e.g. shape.getBoundingBox()).
PrefixTree can handle anything so change there.

I'll commit this pending your +1 Chris.

An enum for FAIL, COALESCE, or IGNORE can be done in another issue if desired.

Remove IgnoreIncompatibleGeometry for SpatialStrategys
--

Key: LUCENE-4173
URL: https://issues.apache.org/jira/browse/LUCENE-4173
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial
Reporter: Chris Male
Assignee: David Smiley
Attachments: LUCENE-4173.patch,
LUCENE-4173_remove_ignoreIncompatibleGeometry,_fail_when_given_the_exact_shape_needed.patch

Silently not indexing anything for a Shape is not okay. Users should get an
Exception and then they can decide how to proceed.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-4375) Spatial BBoxIntersects and BBoxWithin are used incorrectly

2012-09-11 Thread David Smiley (JIRA)

David Smiley created LUCENE-4375:


 Summary: Spatial BBoxIntersects and BBoxWithin are used incorrectly
 Key: LUCENE-4375
 URL: https://issues.apache.org/jira/browse/LUCENE-4375
 Project: Lucene - Core
  Issue Type: Bug
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.1


SpatialOperation has two special BBoxIntersects and BBoxWithin choices.  I 
assumed these where the bounding boxes of the query shape but [~ryantxu] 
informed me these are supposed to be for the *indexed shape*.  There is no 
strategy in Lucene spatial that could use this but there is one externally -- 
JtsGeoStrategy.  Javadocs should be added to clarify, and various places like 
SpatialArgs.getShape() should be fixed to not use it incorrectly.

This does remove a feature from the Solr adapters side; the test there will 
need to change.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-4173) Remove IgnoreIncompatibleGeometry for SpatialStrategys

2012-09-11 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453312#comment-13453312
]

David Smiley edited comment on LUCENE-4173 at 9/12/12 8:38 AM:
---

I'll commit this pending your +1 [~cmale].

An enum for FAIL, COALESCE, IGNORE can be done in another issue if desired.

was (Author: dsmiley):
This patch removes ignoreIncompatibleGeometry and modified the strategies
to fail when given a shape that isn't the precise shape used -- no coalescing.
BBox TwoDoubles were both doing coalescing (e.g. shape.getBoundingBox()).
PrefixTree can handle anything so change there.

I'll commit this pending your +1 Chris.

An enum for FAIL, COALESCE, or IGNORE can be done in another issue if desired.

Remove IgnoreIncompatibleGeometry for SpatialStrategys
--

Silently not indexing anything for a Shape is not okay. Users should get an
Exception and then they can decide how to proceed.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4375) Spatial BBoxIntersects and BBoxWithin are used incorrectly

2012-09-11 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-4375:
-

Fix Version/s: (was: 4.1)
   4.0

 Spatial BBoxIntersects and BBoxWithin are used incorrectly
 --

 Key: LUCENE-4375
 URL: https://issues.apache.org/jira/browse/LUCENE-4375
 Project: Lucene - Core
  Issue Type: Bug
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0


 SpatialOperation has two special BBoxIntersects and BBoxWithin choices.  I 
 assumed these where the bounding boxes of the query shape but [~ryantxu] 
 informed me these are supposed to be for the *indexed shape*.  There is no 
 strategy in Lucene spatial that could use this but there is one externally -- 
 JtsGeoStrategy.  Javadocs should be added to clarify, and various places like 
 SpatialArgs.getShape() should be fixed to not use it incorrectly.
 This does remove a feature from the Solr adapters side; the test there will 
 need to change.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4375) Spatial BBoxIntersects and BBoxWithin are used incorrectly

2012-09-11 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-4375:
-

Attachment: 
LUCENE-4375_Fix_use_of_BBoxWithin_BBoxIntersects_and_IsWithin.patch

This patch addresses the BBoxWithin and BBoxIntersects misuse.

I also noticed problematic use of IsWithin by PrefixTreeStrategy.  A 
PrefixTreeStrategy can index all shapes, not just points, so it can't be sure 
if IsWithin is supported.  It seemed simple enough to remove support for it but 
in order to make the tests pass I had to change various test references to 
IsWithin and make it Intersects, like renaming cities-IsWithin-BBox.txt to 
use Intersects in its name and content.  Perhaps it wouldn't be too much of a 
hack for this strategy to have a pointOnly boolean which has the side-effect of 
making IsWithin synonymous with Intersects?

 Spatial BBoxIntersects and BBoxWithin are used incorrectly
 --

 Key: LUCENE-4375
 URL: https://issues.apache.org/jira/browse/LUCENE-4375
 Project: Lucene - Core
  Issue Type: Bug
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0

 Attachments: 
 LUCENE-4375_Fix_use_of_BBoxWithin_BBoxIntersects_and_IsWithin.patch


 SpatialOperation has two special BBoxIntersects and BBoxWithin choices.  I 
 assumed these where the bounding boxes of the query shape but [~ryantxu] 
 informed me these are supposed to be for the *indexed shape*.  There is no 
 strategy in Lucene spatial that could use this but there is one externally -- 
 JtsGeoStrategy.  Javadocs should be added to clarify, and various places like 
 SpatialArgs.getShape() should be fixed to not use it incorrectly.
 This does remove a feature from the Solr adapters side; the test there will 
 need to change.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4208) Spatial distance relevancy should use score of 1/distance

2012-09-11 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453692#comment-13453692
]

David Smiley commented on LUCENE-4208:
--

This being said, something relatively simple should be done to advance this
issue for v4 (and I'll do the work now). It comes down to what is the score of
makeQuery()? The strategies are doing different things right now. Here are 3
options I can think of:
# Standardize on the reciprocal distance using some specific formula like
c/(d+c) where c is 1/10th the distance to the nearest query shape edge.
# Documented loosely to allow any reasonable shape similarity so that it will
at least sort sensibly (this precludes returning the distance directly).
# Add a ValueSource parameter to makeQuery(). This allows the caller to pick
something. If null is supplied then you get a ConstantScoreQuery. A
convenience method on Strategy can be provided to return a ValueSource of the
reciprocal distance formula if the caller wants to use that.

The #3 the ValueSource parameter seems appealing to me but then I remember why
makeQuery() exists instead of letting the user combine the distance valueSource
makeFilter. If the filter requires the valueSource (such as a [working]
TwoDoubles given a query shape other than a rect), then the valueSource might
be invoked twice: first for matching and second for the score. One idea to
alter option #3 is to make the argument an implementation of a single-method
interface that accepts the distance valueSource and returns a valueSource for
the score.

Spatial distance relevancy should use score of 1/distance
-

Key: LUCENE-4208
URL: https://issues.apache.org/jira/browse/LUCENE-4208
Project: Lucene - Core
Issue Type: New Feature
Components: modules/spatial
Reporter: David Smiley
Fix For: 4.0

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-4375) Spatial BBoxIntersects and BBoxWithin are used incorrectly

2012-09-11 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved LUCENE-4375.
--

Resolution: Fixed

Committed in r1383773 and r1383783.

 Spatial BBoxIntersects and BBoxWithin are used incorrectly
 --

 Key: LUCENE-4375
 URL: https://issues.apache.org/jira/browse/LUCENE-4375
 Project: Lucene - Core
  Issue Type: Bug
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0

 Attachments: 
 LUCENE-4375_Fix_use_of_BBoxWithin_BBoxIntersects_and_IsWithin.patch


 SpatialOperation has two special BBoxIntersects and BBoxWithin choices.  I 
 assumed these where the bounding boxes of the query shape but [~ryantxu] 
 informed me these are supposed to be for the *indexed shape*.  There is no 
 strategy in Lucene spatial that could use this but there is one externally -- 
 JtsGeoStrategy.  Javadocs should be added to clarify, and various places like 
 SpatialArgs.getShape() should be fixed to not use it incorrectly.
 This does remove a feature from the Solr adapters side; the test there will 
 need to change.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4173) Remove IgnoreIncompatibleGeometry for SpatialStrategys

2012-09-11 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-4173:
-

Fix Version/s: 4.0

 Remove IgnoreIncompatibleGeometry for SpatialStrategys
 --

 Key: LUCENE-4173
 URL: https://issues.apache.org/jira/browse/LUCENE-4173
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Reporter: Chris Male
Assignee: David Smiley
 Fix For: 4.0

 Attachments: LUCENE-4173.patch, 
 LUCENE-4173_remove_ignoreIncompatibleGeometry,_fail_when_given_the_exact_shape_needed.patch


 Silently not indexing anything for a Shape is not okay.  Users should get an 
 Exception and then they can decide how to proceed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4208) Spatial distance relevancy should use score of 1/distance

2012-09-11 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453743#comment-13453743
]

David Smiley commented on LUCENE-4208:
--

If we standardize on ConstantScoreQuery then it's dubious if makeQuery() should
even exist -- just use makeFilter(). If the user code wants a Query then it
can wrap the Filter. It could first detect if the Filter is a
QueryWrapperFilter and if so grab the Query object from that. This algorithm
could even be the default implementation in SpatialStrategy.

Spatial distance relevancy should use score of 1/distance
-

Key: LUCENE-4208
URL: https://issues.apache.org/jira/browse/LUCENE-4208
Project: Lucene - Core
Issue Type: New Feature
Components: modules/spatial
Reporter: David Smiley
Fix For: 4.0

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4373) BBoxStrategy should support query shapes of any type

2012-09-12 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454036#comment-13454036
 ] 

David Smiley commented on LUCENE-4373:
--

As part of this, I think a makeValueSource() might be modified to alter the 
area similarity to consider the query shape's percentage of the bbox that it 
fills.  Perhaps something like this:
{code:java}
  public ValueSource makeValueSource(SpatialArgs args) {
Shape shape = args.getShape();
double queryPowerFactor = 1;
if (!(shape instanceof Rectangle)) {
  double queryBBoxArea = shape.getBoundingBox().getArea(ctx);
  double queryArea = shape.getArea(ctx);
  if (queryBBoxArea != 0)
queryPowerFactor = queryArea / queryBBoxArea;
}
return new BBoxSimilarityValueSource(
this, new AreaSimilarity(shape.getBoundingBox(), queryPower * 
queryPowerFactor, targetPower));
  }
{code}


 BBoxStrategy should support query shapes of any type
 

 Key: LUCENE-4373
 URL: https://issues.apache.org/jira/browse/LUCENE-4373
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Priority: Minor

 It's great that BBoxStrategy has sophisticated shape area similarity based on 
 bounding box, but I think that doesn't have to preclude having a 
 non-rectangular query shape.  The bbox to bbox query implemented already is 
 probably pretty pretty fast as can work by numeric range queries, but I'd 
 like this to be the first stage of which the 2nd is a FieldCache based 
 comparison to the query shape if it's not a rectangle.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4173) Remove IgnoreIncompatibleGeometry for SpatialStrategys

2012-09-12 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-4173:
-

Attachment: 
LUCENE-4173_remove_IgnoreIncompatibleGeometry,_fail_when_given_the_exact_shape_needed.patch

Updated the patch:
* renamed the test method with the underscore to be 
convertShapeFromGetDocuments instead
* In BBoxStrategy.makeValueSource, I moved my TODO bbox shape similarity idea 
to a comment on a JIRA issue.  And I modified this makeValueSource to fail if a 
rectangle is not given, instead of coalescing via getBoundingBox().

 Remove IgnoreIncompatibleGeometry for SpatialStrategys
 --

 Key: LUCENE-4173
 URL: https://issues.apache.org/jira/browse/LUCENE-4173
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Reporter: Chris Male
Assignee: David Smiley
 Fix For: 4.0

 Attachments: LUCENE-4173.patch, 
 LUCENE-4173_remove_ignoreIncompatibleGeometry,_fail_when_given_the_exact_shape_needed.patch,
  
 LUCENE-4173_remove_IgnoreIncompatibleGeometry,_fail_when_given_the_exact_shape_needed.patch


 Silently not indexing anything for a Shape is not okay.  Users should get an 
 Exception and then they can decide how to proceed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-4173) Remove IgnoreIncompatibleGeometry for SpatialStrategys

2012-09-12 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved LUCENE-4173.
--

Resolution: Fixed

I received Chris's blessing on these changes in chat and I committed now.

Trunk: r1384026, 4x: r1384028



 Remove IgnoreIncompatibleGeometry for SpatialStrategys
 --

 Key: LUCENE-4173
 URL: https://issues.apache.org/jira/browse/LUCENE-4173
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Reporter: Chris Male
Assignee: David Smiley
 Fix For: 4.0

 Attachments: LUCENE-4173.patch, 
 LUCENE-4173_remove_ignoreIncompatibleGeometry,_fail_when_given_the_exact_shape_needed.patch,
  
 LUCENE-4173_remove_IgnoreIncompatibleGeometry,_fail_when_given_the_exact_shape_needed.patch


 Silently not indexing anything for a Shape is not okay.  Users should get an 
 Exception and then they can decide how to proceed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4208) Spatial distance relevancy should use score of 1/distance

2012-09-12 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley updated LUCENE-4208:
-

Attachment:
LUCENE-4208_makeQuery_return_ConstantScoreQuery_and_remake_TwoDoublesStrategy.patch

This patch is the start of something I hope to finish tonight. makeValueSource
is makeDistanceValueSource to make abundantly clear. TwoDoubles is getting
overhauled to support the dateline and any query shape--should probably go into
another issue.

Spatial distance relevancy should use score of 1/distance
-

Key: LUCENE-4208
URL: https://issues.apache.org/jira/browse/LUCENE-4208
Project: Lucene - Core
Issue Type: New Feature
Components: modules/spatial
Reporter: David Smiley
Fix For: 4.0

Attachments:
LUCENE-4208_makeQuery_return_ConstantScoreQuery_and_remake_TwoDoublesStrategy.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2154) Spatial support for MultiValued fields

2012-09-13 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13455117#comment-13455117
 ] 

David Smiley commented on SOLR-2154:


This issue and the one for polygons can be closed once the Solr adapters are 
committed SOLR-3304.

 Spatial support for MultiValued fields
 --

 Key: SOLR-2154
 URL: https://issues.apache.org/jira/browse/SOLR-2154
 Project: Solr
  Issue Type: New Feature
  Components: Build
Affects Versions: 4.0-ALPHA
Reporter: Bill Bell
 Fix For: 4.1


 Is this an issue - it appears to work ?
 This appears to work on LatLon Spatial fields. It appears to find the right 
 lat long... Is this supposed to work?
 I read that this does not work on solr.PointType, but it appears to work on 
 LatLonType.
  fieldType name=location class=solr.PointType dimension=2 
 subFieldSuffix=_d/
 field name=store type=location indexed=true stored=true 
 multiValued=true/
 Trying a few queries and I can get either of the 2 points.
 {code}
 http://localhost:8983/solr/core2/select?fl=*,scoreqf=namesearchpf=namesearchstart=0rows=10q=billqt=standardpt=41.9244,-87.6473d=10.9344fq={!sfilt%20fl=store_lat_lon}sort=hsin(6371,true,store_lat_lon,vector(41.9244,-87.6473))+asc,+score+descdebugQuery=on
 1 result.
 http://10.0.1.37:8983/solr/core2/select?fl=*,scoreqf=namesearchpf=namesearchstart=0rows=10q=billqt=standardpt=47.7651,-122.362d=10.9344fq={!sfilt%20fl=store_lat_lon}sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+descdebugQuery=on
 2 results.
 {code}
 {code}
 schema.xml:
 fieldType name=latLon class=solr.LatLonType subFieldSuffix=_latLon/
  field name=store_lat_lon type=latLon indexed=true stored=true 
 multiValued=true/
  
 sample.xml to import:
 add
   doc
 field name=address2300 North Childrens Plaza/field
 field name=id1/field
 field name=store_lat_lon41.9244,-87.6473/field
 field name=store_lat_lon47.7651,-122.362/field
 field name=zipcode60614/field
   /doc
   doc
 field name=address357 North West Richmond Beach Road/field
 field name=id2/field
 field name=store_lat_lon48.7651,-122.362/field
 field name=zipcode98177/field
   /doc
   doc
 field name=address7555 North Overfield Road/field
 field name=id3/field
 field name=store_lat_lon32.948,-111.653/field
 field name=zipcode85294/field
   /doc
 /add
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4208) Spatial distance relevancy should use score of 1/distance

2012-09-13 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley updated LUCENE-4208:
-

Attachment:
LUCENE-4208_makeQuery_return_ConstantScoreQuery,_standardize_makeDistanceValueSource_behav.patch

Patch with these changes:
* makeValueSource is makeDistanceValueSource to make abundantly clear. And it
takes Point instead of SpatialArgs.
* Standardized behavior of makeDistanceValueSource across the 3 strategies,
including null value behavior (it's '180' if geo, Double.MAX_VALUE otherwise).
* Tests for makeDistanceValueSource in DistanceStrategyTest
* Added final method SpatialStrategy.makeRecipDistanceValueSource(queryShape)
including tested it. This addresses the title of this JIRA issue.

I'll put off overhauling TwoDoubles into another JIRA issue. I've already done
some work for that.

Spatial distance relevancy should use score of 1/distance
-

Key: LUCENE-4208
URL: https://issues.apache.org/jira/browse/LUCENE-4208
Project: Lucene - Core
Issue Type: New Feature
Components: modules/spatial
Reporter: David Smiley
Fix For: 4.0

Attachments:
LUCENE-4208_makeQuery_return_ConstantScoreQuery_and_remake_TwoDoublesStrategy.patch,

LUCENE-4208_makeQuery_return_ConstantScoreQuery,_standardize_makeDistanceValueSource_behav.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3304) Add Solr support for the new Lucene spatial module

2012-09-13 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13455542#comment-13455542
 ] 

David Smiley commented on SOLR-3304:


RE StorableField -- small details like that I work out at commit time.  I 
develop against trunk and then the 4x backport has been trivial.

 Add Solr support for the new Lucene spatial module
 --

 Key: SOLR-3304
 URL: https://issues.apache.org/jira/browse/SOLR-3304
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Bill Bell
Assignee: David Smiley
  Labels: spatial
 Attachments: SOLR-3304_Solr_fields_for_Lucene_spatial_module 
 (fieldName in Strategy) - indexableFields.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module (fieldName in 
 Strategy).patch, SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304-strategy-getter-fixed.patch


 Get the Solr spatial module integrated with the lucene spatial module.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4208) Spatial distance relevancy should use score of 1/distance

2012-09-13 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley updated LUCENE-4208:
-

Attachment:
LUCENE-4208_makeQuery_return_ConstantScoreQuery,_standardize_makeDistanceValueSource_behav.patch

Here's an updated patch. To avoid the danger of two methods being implemented
in terms of each other, I made makeFilter abstract again.

Oddly IntelliJ put the files in the patch in a different order, so you can't
diff the patches across each other to see my changes; ah well.

I'm looking forward to seeing this committed, pending a +1.

Spatial distance relevancy should use score of 1/distance
-

Key: LUCENE-4208
URL: https://issues.apache.org/jira/browse/LUCENE-4208
Project: Lucene - Core
Issue Type: New Feature
Components: modules/spatial
Reporter: David Smiley
Fix For: 4.0

Attachments:
LUCENE-4208_makeQuery_return_ConstantScoreQuery_and_remake_TwoDoublesStrategy.patch,

LUCENE-4208_makeQuery_return_ConstantScoreQuery,_standardize_makeDistanceValueSource_behav.patch,

LUCENE-4208_makeQuery_return_ConstantScoreQuery,_standardize_makeDistanceValueSource_behav.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4208) Spatial distance relevancy should use score of 1/distance

2012-09-14 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13455788#comment-13455788
 ] 

David Smiley commented on LUCENE-4208:
--

Here are my proposed updates to the javadocs:

makeDistanceValueSource:
{code}
  /**
   * Make a ValueSource returning the distance between the center of the
   * indexed shape and {@code queryPoint}.  If there are multiple indexed shapes
   * then the closest one is chosen.
   */
{code}

makeRecipDistanceValueSource:
{code}
  /**
   * Returns a ValueSource with values ranging from 1 to 0, depending inversely
   * to the distance from {@link 
#makeDistanceValueSource(com.spatial4j.core.shape.Point)}.
   * The formula is codec/(d + c)/code where 'd' is the distance and 'c' is
   * one tenth the distance to the farthest edge from the center. Thus the
   * scores will be 1 for indexed points at the center of the query shape and as
   * low as ~0.1 at its furthest edges.
   */
  public final ValueSource makeRecipDistanceValueSource(Shape queryShape) {
{code}

 Spatial distance relevancy should use score of 1/distance
 -

 Key: LUCENE-4208
 URL: https://issues.apache.org/jira/browse/LUCENE-4208
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: David Smiley
 Fix For: 4.0

 Attachments: 
 LUCENE-4208_makeQuery_return_ConstantScoreQuery_and_remake_TwoDoublesStrategy.patch,
  
 LUCENE-4208_makeQuery_return_ConstantScoreQuery,_standardize_makeDistanceValueSource_behav.patch,
  
 LUCENE-4208_makeQuery_return_ConstantScoreQuery,_standardize_makeDistanceValueSource_behav.patch


 The SpatialStrategy.makeQuery() at the moment uses the distance as the score 
 (although some strategies -- TwoDoubles if I recall might not do anything 
 which would be a bug).  The distance is a poor value to use as the score 
 because the score should be related to relevancy, and the distance itself is 
 inversely related to that.  A score of 1/distance would be nice.  Another 
 alternative is earthCircumference/2 - distance, although I like 1/distance 
 better.  Maybe use a different constant than 1.
 Credit: this is Chris Male's idea.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-4388) ShapeMatcher and ShapeValues

2012-09-14 Thread David Smiley (JIRA)

David Smiley created LUCENE-4388:


 Summary: ShapeMatcher and ShapeValues
 Key: LUCENE-4388
 URL: https://issues.apache.org/jira/browse/LUCENE-4388
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: David Smiley


This patch provides two key interfaces: ShapeMatcher and ShapeValues.  The 
ShapeMatcher concept is borrowed from [~ryantxu]'s JtsGeoStrategy which has a 
similar GeometryTester.  ShapeValues is basically a ValueSource/FunctionValues 
for shapes.  This isn't working; I didn't modify any existing classes.

I haven't completely thought this through but a SpatialStrategy might expose a 
makeShapeValues(IndexReader) and/or makeCenterShapeValues(IndexReader) (the 
latter is the center points of indexed data).  A generic Distance ValueSource 
could easily be implemented in terms of makeCenterShapeValues().  And a 
strategy could support any query shape simply by implementing makeShapeValues().

I've been thinking about how the API handles strategies supporting indexing 
multiple shapes and I wonder if that could happen simply via a new 
MultiShapeShape.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (LUCENE-4208) Spatial distance relevancy should use score of 1/distance

2012-09-14 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley reassigned LUCENE-4208:


Assignee: David Smiley

 Spatial distance relevancy should use score of 1/distance
 -

 Key: LUCENE-4208
 URL: https://issues.apache.org/jira/browse/LUCENE-4208
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0

 Attachments: 
 LUCENE-4208_makeQuery_return_ConstantScoreQuery_and_remake_TwoDoublesStrategy.patch,
  
 LUCENE-4208_makeQuery_return_ConstantScoreQuery,_standardize_makeDistanceValueSource_behav.patch,
  
 LUCENE-4208_makeQuery_return_ConstantScoreQuery,_standardize_makeDistanceValueSource_behav.patch


 The SpatialStrategy.makeQuery() at the moment uses the distance as the score 
 (although some strategies -- TwoDoubles if I recall might not do anything 
 which would be a bug).  The distance is a poor value to use as the score 
 because the score should be related to relevancy, and the distance itself is 
 inversely related to that.  A score of 1/distance would be nice.  Another 
 alternative is earthCircumference/2 - distance, although I like 1/distance 
 better.  Maybe use a different constant than 1.
 Credit: this is Chris Male's idea.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3304) Add Solr support for the new Lucene spatial module

2012-09-14 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated SOLR-3304:
---

Fix Version/s: 4.0

 Add Solr support for the new Lucene spatial module
 --

 Key: SOLR-3304
 URL: https://issues.apache.org/jira/browse/SOLR-3304
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Bill Bell
Assignee: David Smiley
  Labels: spatial
 Fix For: 4.0

 Attachments: SOLR-3304_Solr_fields_for_Lucene_spatial_module 
 (fieldName in Strategy) - indexableFields.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module (fieldName in 
 Strategy).patch, SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304-strategy-getter-fixed.patch


 Get the Solr spatial module integrated with the lucene spatial module.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3304) Add Solr support for the new Lucene spatial module

2012-09-14 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated SOLR-3304:
---

Priority: Critical  (was: Major)

 Add Solr support for the new Lucene spatial module
 --

 Key: SOLR-3304
 URL: https://issues.apache.org/jira/browse/SOLR-3304
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Bill Bell
Assignee: David Smiley
Priority: Critical
  Labels: spatial
 Fix For: 4.0

 Attachments: SOLR-3304_Solr_fields_for_Lucene_spatial_module 
 (fieldName in Strategy) - indexableFields.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module (fieldName in 
 Strategy).patch, SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304-strategy-getter-fixed.patch


 Get the Solr spatial module integrated with the lucene spatial module.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4388) ShapeMatcher and ShapeValues

2012-09-14 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley updated LUCENE-4388:
-

Attachment: LUCENE-4388_ShapeValues_and_ShapeMatcher.patch

ShapeMatcher and ShapeValues

Key: LUCENE-4388
URL: https://issues.apache.org/jira/browse/LUCENE-4388
Project: Lucene - Core
Issue Type: New Feature
Components: modules/spatial
Reporter: David Smiley
Attachments: LUCENE-4388_ShapeValues_and_ShapeMatcher.patch

This patch provides two key interfaces: ShapeMatcher and ShapeValues. The
ShapeMatcher concept is borrowed from [~ryantxu]'s JtsGeoStrategy which has a
similar GeometryTester. ShapeValues is basically a
ValueSource/FunctionValues for shapes. This isn't working; I didn't modify
any existing classes.
I haven't completely thought this through but a SpatialStrategy might expose
a makeShapeValues(IndexReader) and/or makeCenterShapeValues(IndexReader) (the
latter is the center points of indexed data). A generic Distance ValueSource
could easily be implemented in terms of makeCenterShapeValues(). And a
strategy could support any query shape simply by implementing
makeShapeValues().
I've been thinking about how the API handles strategies supporting indexing
multiple shapes and I wonder if that could happen simply via a new
MultiShapeShape.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-4389) Fix TwoDoubles dateline support

2012-09-14 Thread David Smiley (JIRA)

David Smiley created LUCENE-4389:


 Summary: Fix TwoDoubles dateline support
 Key: LUCENE-4389
 URL: https://issues.apache.org/jira/browse/LUCENE-4389
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
 Fix For: 4.0


The dateline support can easily be fixed.  After this, the TwoDoublesStrategy 
might not be particularly useful but at least it won't be buggy if you stay 
with Rectangle query shapes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (LUCENE-4389) Fix TwoDoubles dateline support

2012-09-14 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley reassigned LUCENE-4389:


Assignee: David Smiley

 Fix TwoDoubles dateline support
 ---

 Key: LUCENE-4389
 URL: https://issues.apache.org/jira/browse/LUCENE-4389
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0


 The dateline support can easily be fixed.  After this, the TwoDoublesStrategy 
 might not be particularly useful but at least it won't be buggy if you stay 
 with Rectangle query shapes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4389) Fix TwoDoubles dateline support

2012-09-14 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-4389:
-

Attachment: LUCENE-4389 Support dateline for TwoDoubles.patch

This patch includes the dateline fix but some other code that I'll remove or 
change in makeFilter() -- it doesn't compile.  I really need to see LUCENE-4208 
fixed first.  Then I can also add tests or enable existing tests to use this 
one.

 Fix TwoDoubles dateline support
 ---

 Key: LUCENE-4389
 URL: https://issues.apache.org/jira/browse/LUCENE-4389
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0

 Attachments: LUCENE-4389 Support dateline for TwoDoubles.patch


 The dateline support can easily be fixed.  After this, the TwoDoublesStrategy 
 might not be particularly useful but at least it won't be buggy if you stay 
 with Rectangle query shapes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4389) Fix TwoDoubles dateline support

2012-09-14 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-4389:
-

Attachment: LUCENE-4389_Support_dateline_and_circles_for_TwoDoubles.patch

Here's a working patch. It depends on LUCENE-4208 being applied already.  The 
dateline is fixed *and* it _brings back circle query shape support_.  Circle 
support had been removed temporarily in LUCENE-4208 and it's working now.  FYI 
TwoDoublesStrategy is primarily tested by PortedSolr3Test at the moment.

 Fix TwoDoubles dateline support
 ---

 Key: LUCENE-4389
 URL: https://issues.apache.org/jira/browse/LUCENE-4389
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0

 Attachments: 
 LUCENE-4389_Support_dateline_and_circles_for_TwoDoubles.patch, LUCENE-4389 
 Support dateline for TwoDoubles.patch


 The dateline support can easily be fixed.  After this, the TwoDoublesStrategy 
 might not be particularly useful but at least it won't be buggy if you stay 
 with Rectangle query shapes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3304) Add Solr support for the new Lucene spatial module

2012-09-14 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated SOLR-3304:
---

Attachment: SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch

Here is an updated patch.  It depends on LUCENE-4208 (makeDistanceValueSource) 
and LUCENE-4389 (TwoDoubles dateline and circle) being applied.
Notes:
* TwoDoublesStrategy is a decent strategy now, due to LUCENE-4389 and tests in 
that issue and this one.
* The 'needScore' local-param is gone, replaced by 'score'.  'score' can be set 
to 'none' (the default) to use a constant of 1, or 'distance' to use the 
distance, or 'recipDistance' to use the reciprocal distance.  If you want to 
sort then use 'distance' (ascending) and if you want to boost relevancy by 
distance then I recommend 'recipDistance'.

 Add Solr support for the new Lucene spatial module
 --

 Key: SOLR-3304
 URL: https://issues.apache.org/jira/browse/SOLR-3304
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Bill Bell
Assignee: David Smiley
Priority: Critical
  Labels: spatial
 Fix For: 4.0

 Attachments: SOLR-3304_Solr_fields_for_Lucene_spatial_module 
 (fieldName in Strategy) - indexableFields.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module (fieldName in 
 Strategy).patch, SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304-strategy-getter-fixed.patch


 Get the Solr spatial module integrated with the lucene spatial module.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3304) Add Solr support for the new Lucene spatial module

2012-09-14 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456188#comment-13456188
 ] 

David Smiley commented on SOLR-3304:


Hi Rob Purdy.  I don't have time to explain this query as I write this but 
peruse this example query which does just about everything:

http://localhost:8983/solr/select?q=*%3A*wt=xmlfq={!%20v=$sq}sq=store:%22Intersects%28Circle%2854.729696,-98.525391%20d=10%29%29%22debugQuery=onsort=query%28$sortsq%29+ascfl=id,store,score,distdeg:query%28$sortsq%29sortsq={!%20score=distance%20v=$sq}

I'll update the wiki within the next few days, hopefully.

 Add Solr support for the new Lucene spatial module
 --

 Key: SOLR-3304
 URL: https://issues.apache.org/jira/browse/SOLR-3304
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Bill Bell
Assignee: David Smiley
Priority: Critical
  Labels: spatial
 Fix For: 4.0

 Attachments: SOLR-3304_Solr_fields_for_Lucene_spatial_module 
 (fieldName in Strategy) - indexableFields.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module (fieldName in 
 Strategy).patch, SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304-strategy-getter-fixed.patch


 Get the Solr spatial module integrated with the lucene spatial module.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-2255) local params are not parsed in facet.pivot parameter

2012-09-14 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley reassigned SOLR-2255:
--

Assignee: David Smiley

 local params are not parsed in facet.pivot parameter
 

 Key: SOLR-2255
 URL: https://issues.apache.org/jira/browse/SOLR-2255
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0-ALPHA
Reporter: Julien Lirochon
Assignee: David Smiley

 ...facet=truefacet.pivot={!ex=category}category_id,subcategory_idfq={!tag=category}category_id=42
 generates the following error : undefined field {!ex=category}category_id
 If you filter on subcategory_id, the facet.pivot result will contain only 
 results from this subcategory. It's a loss of function since you can't alter 
 this behavior with local params.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-4208) Spatial distance relevancy should use score of 1/distance

2012-09-15 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley resolved LUCENE-4208.
--

Resolution: Fixed

Chris thinks its good and I made the commit. trunk: r1385074 + 89, and 4x:
r1385122

Spatial distance relevancy should use score of 1/distance
-

Key: LUCENE-4208
URL: https://issues.apache.org/jira/browse/LUCENE-4208
Project: Lucene - Core
Issue Type: New Feature
Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Fix For: 4.0

Attachments:
LUCENE-4208_makeQuery_return_ConstantScoreQuery_and_remake_TwoDoublesStrategy.patch,

LUCENE-4208_makeQuery_return_ConstantScoreQuery,_standardize_makeDistanceValueSource_behav.patch,

LUCENE-4208_makeQuery_return_ConstantScoreQuery,_standardize_makeDistanceValueSource_behav.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-4389) Fix TwoDoubles dateline support

2012-09-15 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved LUCENE-4389.
--

Resolution: Fixed

Committed to trunk r1385130 and 4x r1385131

 Fix TwoDoubles dateline support
 ---

 Key: LUCENE-4389
 URL: https://issues.apache.org/jira/browse/LUCENE-4389
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0

 Attachments: 
 LUCENE-4389_Support_dateline_and_circles_for_TwoDoubles.patch, LUCENE-4389 
 Support dateline for TwoDoubles.patch


 The dateline support can easily be fixed.  After this, the TwoDoublesStrategy 
 might not be particularly useful but at least it won't be buggy if you stay 
 with Rectangle query shapes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3304) Add Solr support for the new Lucene spatial module

2012-09-15 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456448#comment-13456448
 ] 

David Smiley commented on SOLR-3304:


The two issues this depends on are finally closed.  I plan on committing this 
one tomorrow to allow more time for feedback.

 Add Solr support for the new Lucene spatial module
 --

 Key: SOLR-3304
 URL: https://issues.apache.org/jira/browse/SOLR-3304
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Bill Bell
Assignee: David Smiley
Priority: Critical
  Labels: spatial
 Fix For: 4.0

 Attachments: SOLR-3304_Solr_fields_for_Lucene_spatial_module 
 (fieldName in Strategy) - indexableFields.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module (fieldName in 
 Strategy).patch, SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304-strategy-getter-fixed.patch


 Get the Solr spatial module integrated with the lucene spatial module.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4384) add top-level 'ant precommit'

2012-09-15 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456449#comment-13456449
 ] 

David Smiley commented on LUCENE-4384:
--

Awesome; thanks guys!  This should reduce some failures in my commits lately :-P

 add top-level 'ant precommit'
 -

 Key: LUCENE-4384
 URL: https://issues.apache.org/jira/browse/LUCENE-4384
 Project: Lucene - Core
  Issue Type: Task
  Components: general/build
Reporter: Robert Muir
 Fix For: 5.0, 4.0

 Attachments: LUCENE-4384.patch, LUCENE-4384.patch


 We have a lot more checks in the build:
 If we added 'ant precommit' it would make it easier to run all the 
 (reasonably fast) checks beforehand... and save some typing.
 So I think we can just add precommit which is:
 * check-svn-working-copy (looks for un-added files, wrong eol-style)
 * validate (nocommit/author checks, license headers, 3rd party licenses, 
 forbidden apis)
 * javadocs-lint (javadocs + missing/broken links checks)
 * test

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4388) ShapeMatcher and ShapeValues

2012-09-16 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456751#comment-13456751
]

David Smiley commented on LUCENE-4388:
--

bq. I am little worried that this could encourage consumers, whether they be
other Strategy impls or something else, to use un-inverted index structures
instead of inverted and subsequently suffer in performance and in memory
consumption.

The only solution there is documentation -- e.g. javadocs. Some features
basically require these memory structures; it's hard to avoid them.

{quote}
bq. And a strategy could support any query shape simply by implementing
makeShapeValues().

I don't understand this. Can you elaborate?
{quote}

The reasoning is similar to how a standard DistanceValueSource could then
exist. For a makeFilter / makeQuery, there could be a standard ShapeFilter
that consults makeShapeValues to intersect with the query shape. Of course, it
should be preceded by a bbox filter or something similar.

RE MultiShape:
bq. or whether it should change per Document and then force the consumer to
check

I'm not sure what you mean. But a problem with the other approach (forcing
MultiShape for createFields) is that it would make Solr support difficult,
perhaps requiring a UpdateRequestProcessor to join separate field values into
one. But even putting that aside, I don't think use of a MultiShape needs to
be *forced*, but it should be supported by the Strategy if it declares that it
handles multi-valued shapes.

ShapeMatcher and ShapeValues

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-3304) Add Solr support for the new Lucene spatial module

2012-09-16 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved SOLR-3304.


Resolution: Fixed

I made the return type of the AbstractSpatialFieldType.createField() be 
covariant and return Field, so as to be the same between both branches.

Committed to trunk  4x.  

 Add Solr support for the new Lucene spatial module
 --

 Key: SOLR-3304
 URL: https://issues.apache.org/jira/browse/SOLR-3304
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Bill Bell
Assignee: David Smiley
Priority: Critical
  Labels: spatial
 Fix For: 4.0

 Attachments: SOLR-3304_Solr_fields_for_Lucene_spatial_module 
 (fieldName in Strategy) - indexableFields.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module (fieldName in 
 Strategy).patch, SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304-strategy-getter-fixed.patch


 Get the Solr spatial module integrated with the lucene spatial module.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3304) Add Solr support for the new Lucene spatial module

2012-09-16 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456767#comment-13456767
 ] 

David Smiley commented on SOLR-3304:


The CHANGES.txt was just added as follows:
{noformat}
* SOLR-3304: Added Solr adapters for Lucene 4's new spatial module.  With
  SpatialRecursivePrefixTreeFieldType (location_rpt in example schema), it is
  possible to index a variable number of points per document (and sort on them),
  index not just points but any Spatial4j supported shape such as polygons, and
  to query on these shapes too.  Polygons requires adding JTS to the classpath.
  (David Smiley)
{noformat}

 Add Solr support for the new Lucene spatial module
 --

 Key: SOLR-3304
 URL: https://issues.apache.org/jira/browse/SOLR-3304
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Bill Bell
Assignee: David Smiley
Priority: Critical
  Labels: spatial
 Fix For: 4.0

 Attachments: SOLR-3304_Solr_fields_for_Lucene_spatial_module 
 (fieldName in Strategy) - indexableFields.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module (fieldName in 
 Strategy).patch, SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, 
 SOLR-3304-strategy-getter-fixed.patch


 Get the Solr spatial module integrated with the lucene spatial module.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-2154) Spatial support for MultiValued fields

2012-09-16 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved SOLR-2154.


   Resolution: Fixed
Fix Version/s: (was: 4.1)
   4.0
 Assignee: David Smiley

SOLR-3304 is committed, and consequently there is now multi-value index 
support.  I'm resolving this issue.

 Spatial support for MultiValued fields
 --

 Key: SOLR-2154
 URL: https://issues.apache.org/jira/browse/SOLR-2154
 Project: Solr
  Issue Type: New Feature
  Components: Build
Affects Versions: 4.0-ALPHA
Reporter: Bill Bell
Assignee: David Smiley
 Fix For: 4.0


 Is this an issue - it appears to work ?
 This appears to work on LatLon Spatial fields. It appears to find the right 
 lat long... Is this supposed to work?
 I read that this does not work on solr.PointType, but it appears to work on 
 LatLonType.
  fieldType name=location class=solr.PointType dimension=2 
 subFieldSuffix=_d/
 field name=store type=location indexed=true stored=true 
 multiValued=true/
 Trying a few queries and I can get either of the 2 points.
 {code}
 http://localhost:8983/solr/core2/select?fl=*,scoreqf=namesearchpf=namesearchstart=0rows=10q=billqt=standardpt=41.9244,-87.6473d=10.9344fq={!sfilt%20fl=store_lat_lon}sort=hsin(6371,true,store_lat_lon,vector(41.9244,-87.6473))+asc,+score+descdebugQuery=on
 1 result.
 http://10.0.1.37:8983/solr/core2/select?fl=*,scoreqf=namesearchpf=namesearchstart=0rows=10q=billqt=standardpt=47.7651,-122.362d=10.9344fq={!sfilt%20fl=store_lat_lon}sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+descdebugQuery=on
 2 results.
 {code}
 {code}
 schema.xml:
 fieldType name=latLon class=solr.LatLonType subFieldSuffix=_latLon/
  field name=store_lat_lon type=latLon indexed=true stored=true 
 multiValued=true/
  
 sample.xml to import:
 add
   doc
 field name=address2300 North Childrens Plaza/field
 field name=id1/field
 field name=store_lat_lon41.9244,-87.6473/field
 field name=store_lat_lon47.7651,-122.362/field
 field name=zipcode60614/field
   /doc
   doc
 field name=address357 North West Richmond Beach Road/field
 field name=id2/field
 field name=store_lat_lon48.7651,-122.362/field
 field name=zipcode98177/field
   /doc
   doc
 field name=address7555 North Overfield Road/field
 field name=id3/field
 field name=store_lat_lon32.948,-111.653/field
 field name=zipcode85294/field
   /doc
 /add
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-2268) Add support for Point in Polygon searches

2012-09-16 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley resolved SOLR-2268.

Resolution: Fixed
Fix Version/s: 4.0
Assignee: David Smiley (was: Grant Ingersoll)

SOLR-3304 is committed, and consequently there is now polygon support; I'm
closing this issue.

Polygons and various other shapes are implemented by
[Spatial4j|https://github.com/spatial4j/spatial4j] (ASL licensed lib) used by
the new Lucene 4 spatial module. Points, rectangles, and circles are
implemented directly by Spatial4j whereas JTS is used for polygons and other
shapes supported in the WKT format. Spatial4j wraps JTS to add geospatial
awareness -- notably dateline wrap. Pole wrap is not yet supported. The new
SpatialRecursivePrefixTreeFieldType added to Solr can index any Spatial4j shape
and query by them as well.

I've got a preliminary wiki page on this but I need to update it and see how to
integrate this content with the rest of the wiki.
http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4

Add support for Point in Polygon searches
-

Key: SOLR-2268
URL: https://issues.apache.org/jira/browse/SOLR-2268
Project: Solr
Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: David Smiley
Fix For: 4.0

Attachments: SOLR-2268.patch

In spatial applications, it is common to ask whether a point is inside of a
polygon. Solr could support two forms of this:
# A field contains a polygon and the user supplies a point. If it does, the
doc is returned.
# A document contains a point and the user supplies a polygon. If the point
is in the polygon, return the document
With both of these case, it would be good to support the negative assertion,
too.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2155) Geospatial search using geohash prefixes

2012-09-17 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456974#comment-13456974
]

David Smiley commented on SOLR-2155:

{panel:title=announcement}
SOLR-3304 was just committed to Solr 4. If you are using SOLR-2155 in Solr 3,
then you don't need to worry about patching Solr in Solr 4 or anything to get
the same functionality (and more). The field type is
SpatialRecursivePrefixTreeFieldType which defaults to geospatial use with
geohashes. It also has a distErrPct option which specifies the precision of
the shape which speeds things up some.
{panel}

Geospatial search using geohash prefixes

Key: SOLR-2155
URL: https://issues.apache.org/jira/browse/SOLR-2155
Project: Solr
Issue Type: Improvement
Reporter: David Smiley
Assignee: David Smiley
Attachments: GeoHashPrefixFilter.patch, GeoHashPrefixFilter.patch,
GeoHashPrefixFilter.patch, Solr2155-1.0.2-project.zip,
Solr2155-1.0.3-project.zip, Solr2155-1.0.4-project.zip,
Solr2155-for-1.0.2-3.x-port.patch,
SOLR-2155_GeoHashPrefixFilter_with_sorting_no_poly.patch, SOLR.2155.p3.patch,
SOLR.2155.p3tests.patch

{panel:title=NOTICE} The status of this issue is a plugin for Solr 3.x
located here: https://github.com/dsmiley/SOLR-2155. Look at the introductory
readme and download the plugin .jar file. Lucene 4's new spatial module is
largely based on this code. The Solr 4 glue for it should come very soon but
as of this writing it's hosted temporarily at https://github.com/spatial4j.
For more information on using SOLR-2155 with Solr 3, see
http://wiki.apache.org/solr/SpatialSearch#SOLR-2155 This JIRA issue is
closed because it won't be committed in its current form.
{panel}
There currently isn't a solution in Solr for doing geospatial filtering on
documents that have a variable number of points. This scenario occurs when
there is location extraction (i.e. via a gazateer) occurring on free text.
None, one, or many geospatial locations might be extracted from any given
document and users want to limit their search results to those occurring in a
user-specified area.
I've implemented this by furthering the GeoHash based work in Lucene/Solr
with a geohash prefix based filter. A geohash refers to a lat-lon box on the
earth. Each successive character added further subdivides the box into a 4x8
(or 8x4 depending on the even/odd length of the geohash) grid. The first
step in this scheme is figuring out which geohash grid squares cover the
user's search query. I've added various extra methods to GeoHashUtils (and
added tests) to assist in this purpose. The next step is an actual Lucene
Filter, GeoHashPrefixFilter, that uses these geohash prefixes in
TermsEnum.seek() to skip to relevant grid squares in the index. Once a
matching geohash grid is found, the points therein are compared against the
user's query to see if it matches. I created an abstraction GeoShape
extended by subclasses named PointDistance... and CartesianBox to support
different queried shapes so that the filter need not care about these details.
This work was presented at LuceneRevolution in Boston on October 8th.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2255) local params are not parsed in facet.pivot parameter

2012-09-17 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated SOLR-2255:
---

Issue Type: New Feature  (was: Bug)

 local params are not parsed in facet.pivot parameter
 

 Key: SOLR-2255
 URL: https://issues.apache.org/jira/browse/SOLR-2255
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Julien Lirochon
Assignee: David Smiley

 ...facet=truefacet.pivot={!ex=category}category_id,subcategory_idfq={!tag=category}category_id=42
 generates the following error : undefined field {!ex=category}category_id
 If you filter on subcategory_id, the facet.pivot result will contain only 
 results from this subcategory. It's a loss of function since you can't alter 
 this behavior with local params.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-3849) ScriptEngineTest failure RE system properties and ThreadLeakError

2012-09-17 Thread David Smiley (JIRA)

David Smiley created SOLR-3849:
--

 Summary: ScriptEngineTest failure RE system properties and 
ThreadLeakError
 Key: SOLR-3849
 URL: https://issues.apache.org/jira/browse/SOLR-3849
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 5.0
 Environment: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07 
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
Reporter: David Smiley
Assignee: Hoss Man


100% reproducible for me:
solr$ ant test  -Dtestcase=ScriptEngineTest

{noformat}
[junit4:junit4] JUnit4 says hi! Master seed: E62CC5FBAC2CEFA4
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.solr.update.processor.ScriptEngineTest
[junit4:junit4] OK  0.17s | ScriptEngineTest.testPut
[junit4:junit4] OK  0.02s | ScriptEngineTest.testEvalReader
[junit4:junit4] IGNOR/A 0.10s | ScriptEngineTest.testJRuby
[junit4:junit4] Assumption #1: got: [null], expected: each not null
[junit4:junit4] OK  0.01s | ScriptEngineTest.testEvalText
[junit4:junit4] OK  0.01s | ScriptEngineTest.testGetEngineByExtension
[junit4:junit4] OK  0.01s | ScriptEngineTest.testGetEngineByName
[junit4:junit4]   2 -9 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING Will 
linger awaiting termination of 2 leaked thread(s).
[junit4:junit4]   2 20163 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1 
thread leaked from SUITE scope at 
org.apache.solr.update.processor.ScriptEngineTest: 
[junit4:junit4]   2   1) Thread[id=11, name=AppKit Thread, state=RUNNABLE, 
group=main]
[junit4:junit4]   2at (empty stack)
[junit4:junit4]   2 20164 T9 ccr.ThreadLeakControl.tryToInterruptAll Starting 
to interrupt leaked threads:
[junit4:junit4]   2   1) Thread[id=11, name=AppKit Thread, state=RUNNABLE, 
group=main]
[junit4:junit4]   2 23172 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE 
There are still zombie threads that couldn't be terminated:
[junit4:junit4]   2   1) Thread[id=11, name=AppKit Thread, state=RUNNABLE, 
group=main]
[junit4:junit4]   2at (empty stack)
[junit4:junit4]   2 NOTE: test params are: codec=SimpleText, 
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=es_PR, 
timezone=America/Edmonton
[junit4:junit4]   2 NOTE: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07 
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
[junit4:junit4]   2 NOTE: All tests run in this JVM: [ScriptEngineTest]
[junit4:junit4]   2 NOTE: reproduce with: ant test  
-Dtestcase=ScriptEngineTest -Dtests.seed=E62CC5FBAC2CEFA4 -Dtests.slow=true 
-Dtests.locale=es_PR -Dtests.timezone=America/Edmonton 
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR   0.00s | ScriptEngineTest (suite) 
[junit4:junit4] Throwable #1: java.lang.AssertionError: System properties 
invariant violated.
[junit4:junit4] New keys:
[junit4:junit4]   sun.awt.enableExtraMouseButtons=true
[junit4:junit4]   sun.font.fontmanager=sun.font.CFontManager
[junit4:junit4] 
[junit4:junit4]at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:66)
[junit4:junit4]at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4]at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4]at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4]at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4]at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4]at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4]at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4]at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4]at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4]at java.lang.Thread.run(Thread.java:722)
[junit4:junit4] Throwable #2: 
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.update.processor.ScriptEngineTest: 
[junit4:junit4]1) Thread[id=11, name=AppKit Thread, state=RUNNABLE, 
group=main]
[junit4:junit4] at (empty stack)
[junit4:junit4]at 
__randomizedtesting.SeedInfo.seed([E62CC5FBAC2CEFA4]:0)
[junit4:junit4] Throwable #3: 
com.carrotsearch.randomizedtesting.ThreadLeakError: There

[jira] [Updated] (SOLR-2255) local params are not parsed in facet.pivot parameter

2012-09-17 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated SOLR-2255:
---

Attachment: SOLR-2255_local-param_support_for_pivot_faceting.patch

Attached is a patch developed against trunk.  It'll probably apply cleanly 
against 4x but I haven't tried yet.

Adding this feature was awkward because of the nature of the PivotFacetHelper 
and SimpleFacet classes.  The core of the problem is that PivotFacetHelper 
needs to invoke SimpleFacet.parseParams() somehow but that method is package 
access.  And the variables it sets are package access as well.  It is invoked 
indirectly via getFacetFieldCounts() but PivotFacetHelper sidesteps that method 
and calls getTermCounts() so that the pivot code can split on commas.  
PivotFacetHelper was oddly (IMO) declared as a thread-safe class (it has no 
state) and there is a shared instance of it in FacetComponent but its not clear 
why; it's a trivial class.  It has an extension hook getFacetImplementation() 
with a default impl that simply instantiates a new SimpleFacet instance.  Yet I 
found no case of this method being overridden, and it doesn't seem like an 
extension point worth keeping.  It's not clear that the SimpleFacet behemoth 
was designed to be substituted/extended.

Whatever I did would be somewhat disruptive to the relationship between these 
classes so I took a stab at it any way.  In my patch, PivotFacetHelper extends 
SimpleFacet and is instantiated similarly in FacetComponent.  I removed the 
dubious getFacetImplementation() method in favor of simply referencing the 
current instance this.  This also made it possible to remove some parameters 
(which was getting a little out of control) since they are inherited fields 
now.  I changed package access to protected to parseParams() and the fields it 
sets.  I also decided to do a refactor rename there of docs to docsOrig and 
base to docs so that it's more clear what's going on there.  It's not clear 
to me if references in this class to docsOrig is an undiscovered bug or not.

The test demonstrates a filter query exclusion as well as key to add the data 
to the response using a different name.  I noticed there is a threads 
performance tuning option that should now work too.

 local params are not parsed in facet.pivot parameter
 

 Key: SOLR-2255
 URL: https://issues.apache.org/jira/browse/SOLR-2255
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Julien Lirochon
Assignee: David Smiley
 Attachments: SOLR-2255_local-param_support_for_pivot_faceting.patch


 ...facet=truefacet.pivot={!ex=category}category_id,subcategory_idfq={!tag=category}category_id=42
 generates the following error : undefined field {!ex=category}category_id
 If you filter on subcategory_id, the facet.pivot result will contain only 
 results from this subcategory. It's a loss of function since you can't alter 
 this behavior with local params.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3849) ScriptEngineTest failure RE system properties and ThreadLeakError

2012-09-18 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457869#comment-13457869
 ] 

David Smiley commented on SOLR-3849:


Patch worked!

 ScriptEngineTest failure RE system properties and ThreadLeakError
 -

 Key: SOLR-3849
 URL: https://issues.apache.org/jira/browse/SOLR-3849
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 5.0
 Environment: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07 
 (64-bit)/cpus=4,threads=1,free=65764312,total=85065728
Reporter: David Smiley
Assignee: Dawid Weiss
 Attachments: SOLR-3849.patch


 100% reproducible for me:
 solr$ ant test  -Dtestcase=ScriptEngineTest
 {noformat}
 [junit4:junit4] JUnit4 says hi! Master seed: E62CC5FBAC2CEFA4
 [junit4:junit4] Executing 1 suite with 1 JVM.
 [junit4:junit4] 
 [junit4:junit4] Suite: org.apache.solr.update.processor.ScriptEngineTest
 [junit4:junit4] OK  0.17s | ScriptEngineTest.testPut
 [junit4:junit4] OK  0.02s | ScriptEngineTest.testEvalReader
 [junit4:junit4] IGNOR/A 0.10s | ScriptEngineTest.testJRuby
 [junit4:junit4] Assumption #1: got: [null], expected: each not null
 [junit4:junit4] OK  0.01s | ScriptEngineTest.testEvalText
 [junit4:junit4] OK  0.01s | ScriptEngineTest.testGetEngineByExtension
 [junit4:junit4] OK  0.01s | ScriptEngineTest.testGetEngineByName
 [junit4:junit4]   2 -9 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING 
 Will linger awaiting termination of 2 leaked thread(s).
 [junit4:junit4]   2 20163 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1 
 thread leaked from SUITE scope at 
 org.apache.solr.update.processor.ScriptEngineTest: 
 [junit4:junit4]   2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE, 
 group=main]
 [junit4:junit4]   2  at (empty stack)
 [junit4:junit4]   2 20164 T9 ccr.ThreadLeakControl.tryToInterruptAll 
 Starting to interrupt leaked threads:
 [junit4:junit4]   2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE, 
 group=main]
 [junit4:junit4]   2 23172 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE 
 There are still zombie threads that couldn't be terminated:
 [junit4:junit4]   2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE, 
 group=main]
 [junit4:junit4]   2  at (empty stack)
 [junit4:junit4]   2 NOTE: test params are: codec=SimpleText, 
 sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=es_PR, 
 timezone=America/Edmonton
 [junit4:junit4]   2 NOTE: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07 
 (64-bit)/cpus=4,threads=1,free=65764312,total=85065728
 [junit4:junit4]   2 NOTE: All tests run in this JVM: [ScriptEngineTest]
 [junit4:junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=ScriptEngineTest -Dtests.seed=E62CC5FBAC2CEFA4 -Dtests.slow=true 
 -Dtests.locale=es_PR -Dtests.timezone=America/Edmonton 
 -Dtests.file.encoding=UTF-8
 [junit4:junit4] ERROR   0.00s | ScriptEngineTest (suite) 
 [junit4:junit4] Throwable #1: java.lang.AssertionError: System 
 properties invariant violated.
 [junit4:junit4] New keys:
 [junit4:junit4]   sun.awt.enableExtraMouseButtons=true
 [junit4:junit4]   sun.font.fontmanager=sun.font.CFontManager
 [junit4:junit4] 
 [junit4:junit4]  at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:66)
 [junit4:junit4]  at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 [junit4:junit4]  at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 [junit4:junit4]  at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 [junit4:junit4]  at 
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
 [junit4:junit4]  at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 [junit4:junit4]  at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 [junit4:junit4]  at 
 org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
 [junit4:junit4]  at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 [junit4:junit4]  at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 [junit4:junit4]  at java.lang.Thread.run(Thread.java:722)
 [junit4:junit4] Throwable #2: 
 com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from 
 SUITE scope at

[jira] [Commented] (SOLR-3230) Performance improvement for geofilt by doing a bbox approximation and then Filter

2012-09-18 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457967#comment-13457967
 ] 

David Smiley commented on SOLR-3230:


FYI, FWIW the new SpatialTwoDoubles does a bbox range query approximation and 
then does the distance calculation for a circle query shape after.  I'm 
referring to the Solr adapter to a corresponding Lucene 4 spatial strategy 
class.  Looking through the comments above, it seems another option I didn't 
consider was doing the bbox range on the fieldcache (so-called frange style).

 Performance improvement for geofilt by doing a bbox approximation and then 
 Filter
 -

 Key: SOLR-3230
 URL: https://issues.apache.org/jira/browse/SOLR-3230
 Project: Solr
  Issue Type: Improvement
Reporter: Bill Bell
Assignee: Yonik Seeley
 Fix For: 4.0

 Attachments: SOLR-3230-3.patch, SOLR-3230.patch


 This changes {!geofilt} to use a bounding box and then does a accurate filter.
 See attachment

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4175) Include BBox Spatial Strategy

2012-09-18 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458050#comment-13458050
 ] 

David Smiley commented on LUCENE-4175:
--

The BBoxStrategy is tested insofar as search filtering and returning the 
standard center-point distance as a ValueSource.  But it contains a lot of code 
pertaining to an area overlap similarity as a ValueSource (very cool stuff) but 
that isn't tested at all, and that's my only concern.  If we want to be 
cautious about avoiding releasing untested code, then I suggest back-porting 
BBoxStrategy to 4x (pretty easy) but not the AreaSimilarity class.  The 
reference to it in BBoxStrategy is the method 
makeBBoxAreaSimilarityValueSource() which can be commented out in trunk.

Sound good?

 Include BBox Spatial Strategy
 -

 Key: LUCENE-4175
 URL: https://issues.apache.org/jira/browse/LUCENE-4175
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Ryan McKinley
Assignee: Ryan McKinley
 Attachments: LUCENE-4175-bbox-strategy.patch


 This is an approach to indexing bounding boxes using 4 numeric fields 
 (xmin,ymin,xmax,ymax) and a flag to say if it crosses the dateline.
 This is a modification from the Apache 2.0 code from the ESRI Geoportal:
 http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-4175) Include BBox Spatial Strategy

2012-09-18 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458050#comment-13458050
 ] 

David Smiley edited comment on LUCENE-4175 at 9/19/12 5:52 AM:
---

The BBoxStrategy is tested insofar as search filtering and returning the 
standard center-point distance as a ValueSource.  But it contains a lot of code 
pertaining to an area overlap similarity as a ValueSource (very cool stuff) but 
that isn't tested at all, and that's my only concern.  If we want to be 
cautious about avoiding releasing untested code, then I suggest back-porting 
BBoxStrategy to 4x (pretty easy) but not the AreaSimilarity class.  The 
reference to it in BBoxStrategy is the method 
makeBBoxAreaSimilarityValueSource() which can be commented out in 4x.

Sound good?

  was (Author: dsmiley):
The BBoxStrategy is tested insofar as search filtering and returning the 
standard center-point distance as a ValueSource.  But it contains a lot of code 
pertaining to an area overlap similarity as a ValueSource (very cool stuff) but 
that isn't tested at all, and that's my only concern.  If we want to be 
cautious about avoiding releasing untested code, then I suggest back-porting 
BBoxStrategy to 4x (pretty easy) but not the AreaSimilarity class.  The 
reference to it in BBoxStrategy is the method 
makeBBoxAreaSimilarityValueSource() which can be commented out in trunk.

Sound good?
  
 Include BBox Spatial Strategy
 -

 Key: LUCENE-4175
 URL: https://issues.apache.org/jira/browse/LUCENE-4175
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Ryan McKinley
Assignee: Ryan McKinley
 Attachments: LUCENE-4175-bbox-strategy.patch


 This is an approach to indexing bounding boxes using 4 numeric fields 
 (xmin,ymin,xmax,ymax) and a flag to say if it crosses the dateline.
 This is a modification from the Apache 2.0 code from the ESRI Geoportal:
 http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2255) local params are not parsed in facet.pivot parameter

2012-09-19 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated SOLR-2255:
---

Attachment: SOLR-2255_local-param_support_for_pivot_faceting.patch

This is a small update to the patch to update it for a recent change.  FYI this 
works on 4x too.

Any comments from the likes of Yonik, Hoss, Ryan, or Erik  (those involved in 
the underlying code)?

 local params are not parsed in facet.pivot parameter
 

 Key: SOLR-2255
 URL: https://issues.apache.org/jira/browse/SOLR-2255
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Julien Lirochon
Assignee: David Smiley
 Attachments: SOLR-2255_local-param_support_for_pivot_faceting.patch, 
 SOLR-2255_local-param_support_for_pivot_faceting.patch


 ...facet=truefacet.pivot={!ex=category}category_id,subcategory_idfq={!tag=category}category_id=42
 generates the following error : undefined field {!ex=category}category_id
 If you filter on subcategory_id, the facet.pivot result will contain only 
 results from this subcategory. It's a loss of function since you can't alter 
 this behavior with local params.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4412) Reconsider FunctionValues / ValueSource API

2012-09-20 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13460206#comment-13460206
 ] 

David Smiley commented on LUCENE-4412:
--

I raised my concerns about MultiValueSource and the related array access 
methods on FunctionValues.  Nobody responded.
http://lucene.472066.n3.nabble.com/MultiValueSource-FunctionValues-and-multi-value-support-td4003362.html

 Reconsider FunctionValues / ValueSource API
 ---

 Key: LUCENE-4412
 URL: https://issues.apache.org/jira/browse/LUCENE-4412
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/other
Reporter: Chris Male
 Fix For: 5.0


 When documenting a lot of these classes today I found myself confused and it 
 isn't the first time with this API.  
 I think we need to step back and reassess what we want from this API, what 
 use cases its designed to meet, and redesign it from the ground up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-4167) Remove the use of SpatialOperation

2012-09-20 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley resolved LUCENE-4167.
--

Resolution: Won't Fix

Remove the use of SpatialOperation
--

Key: LUCENE-4167
URL: https://issues.apache.org/jira/browse/LUCENE-4167
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial
Reporter: Chris Male
Attachments:
LUCENE-4167_migrate_com_spatial4j_core_query_to_Lucene_spatial.patch,
LUCENE-4167_migrate_com_spatial4j_core_query_to_Lucene_spatial.patch,
LUCENE-4167.patch

Looking at the code in TwoDoublesStrategy I noticed
SpatialOperations.BBoxWithin vs isWithin which confused me. Looking over the
other Strategys I see that really only isWithin and Intersects is supported.
Only TwoDoublesStrategy supports IsDisjointTo. The remainder of
SpatialOperations are not supported.
I don't think we should use SpatialOperation as this stage since it is not
clear what Operations are supported by what Strategys, many Operations are
not supported, and the code for handling the Operations is usually the same.
We can spin off the code for TwoDoublesStrategy's IsDisjointTo support into a
different Strategy.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4197) Small improvements to Lucene Spatial Module for v4

2012-09-21 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-4197:
-

Attachment: LUCENE-4413_better_spatial_exception_handling.patch

 Small improvements to Lucene Spatial Module for v4
 --

 Key: LUCENE-4197
 URL: https://issues.apache.org/jira/browse/LUCENE-4197
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
 Fix For: 4.1

 Attachments: LUCENE-4197_rename_CachedDistanceValueSource.patch, 
 LUCENE-4197_SpatialArgs_doesn_t_need_overloaded_toString()_with_a_ctx_param_.patch,
  LUCENE-4413_better_spatial_exception_handling.patch, 
 SpatialArgs-_remove_unused_min_and_max_params.patch


 This issue is to capture small changes to the Lucene spatial module that 
 don't deserve their own issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-3864) Spatial maxDetailDist doesn't follow degrees standardization

2012-09-21 Thread David Smiley (JIRA)

David Smiley created SOLR-3864:
--

 Summary: Spatial maxDetailDist doesn't follow degrees 
standardization
 Key: SOLR-3864
 URL: https://issues.apache.org/jira/browse/SOLR-3864
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Reporter: David Smiley
Assignee: David Smiley


Technically this bug is in Lucene spatial but it's on a factory that is only 
really used by the Solr adapter, plus I added a mandatory attribute so I 
decided to file it here.

The maxDetailDist attribute on SpatialRecursivePrefixTreeFieldType is 
interpreted as kilometers for a geospatial context.  However, for this first 
release of spatial, all distances are standardized on degrees.  Of course I 
want to support kilometers but not inconsistently and there isn't time for that 
right now.  Because this is likely to be a common problem of interpreting 
distances for this field, I decided to add a mandatory attribute units which 
must be degrees.  When kilometers is supported then it will be added.

Furthermore, the name maxDetailDist as a name isn't so great. As part of some 
renames related to this sort of thing a month back I overlooked this one.  I 
think maxDistErr is better and more consistent with attributes such as 
distErr you can put in shape query.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3864) Spatial maxDetailDist doesn't follow degrees standardization

2012-09-21 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley updated SOLR-3864:
---

Attachment:
SOLR-3864_maxDetailDist_-__maxDistErr,_and_make_units=_degrees__mandatory.patch

Spatial maxDetailDist doesn't follow degrees standardization

Key: SOLR-3864
URL: https://issues.apache.org/jira/browse/SOLR-3864
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Reporter: David Smiley
Assignee: David Smiley
Attachments:
SOLR-3864_maxDetailDist_-__maxDistErr,_and_make_units=_degrees__mandatory.patch

Technically this bug is in Lucene spatial but it's on a factory that is only
really used by the Solr adapter, plus I added a mandatory attribute so I
decided to file it here.
The maxDetailDist attribute on SpatialRecursivePrefixTreeFieldType is
interpreted as kilometers for a geospatial context. However, for this first
release of spatial, all distances are standardized on degrees. Of course I
want to support kilometers but not inconsistently and there isn't time for
that right now. Because this is likely to be a common problem of
interpreting distances for this field, I decided to add a mandatory attribute
units which must be degrees. When kilometers is supported then it will
be added.
Furthermore, the name maxDetailDist as a name isn't so great. As part of
some renames related to this sort of thing a month back I overlooked this
one. I think maxDistErr is better and more consistent with attributes such
as distErr you can put in shape query.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3864) Spatial maxDetailDist doesn't follow degrees standardization

2012-09-21 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13460791#comment-13460791
]

David Smiley commented on SOLR-3864:

I plan to commit this tonight to 4x.

Spatial maxDetailDist doesn't follow degrees standardization

Key: SOLR-3864
URL: https://issues.apache.org/jira/browse/SOLR-3864
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Reporter: David Smiley
Assignee: David Smiley
Fix For: 4.0

Attachments:
SOLR-3864_maxDetailDist_-__maxDistErr,_and_make_units=_degrees__mandatory.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3864) Spatial maxDetailDist doesn't follow degrees standardization

2012-09-21 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley updated SOLR-3864:
---

Fix Version/s: 4.0

Spatial maxDetailDist doesn't follow degrees standardization

Key: SOLR-3864
URL: https://issues.apache.org/jira/browse/SOLR-3864
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Reporter: David Smiley
Assignee: David Smiley
Fix For: 4.0

Attachments:
SOLR-3864_maxDetailDist_-__maxDistErr,_and_make_units=_degrees__mandatory.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-3864) Spatial maxDetailDist doesn't follow degrees standardization

2012-09-22 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley resolved SOLR-3864.

Resolution: Fixed
Fix Version/s: (was: 4.1)
4.0

Committed to trunk, 4x, and 4.0 branches.

Spatial maxDetailDist doesn't follow degrees standardization

Key: SOLR-3864
URL: https://issues.apache.org/jira/browse/SOLR-3864
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Reporter: David Smiley
Assignee: David Smiley
Fix For: 4.0

Attachments:
SOLR-3864_maxDetailDist_-__maxDistErr,_and_make_units=_degrees__mandatory.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-4413) Better use of exceptions in spatial

2012-09-22 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley resolved LUCENE-4413.
--

Resolution: Fixed
Fix Version/s: 4.0
Assignee: David Smiley

Woops; forgot to attach the the patch. Here's the ViewVC URL to the commit:
http://svn.apache.org/viewvc?view=revisionrevision=1388872

Committed to trunk, 4x, and 4.0 branches

Better use of exceptions in spatial
---

Key: LUCENE-4413
URL: https://issues.apache.org/jira/browse/LUCENE-4413
Project: Lucene - Core
Issue Type: Improvement
Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Priority: Minor
Fix For: 4.0

Spatial4j's InvalidShapeException is supposed to be for shape strings that
won't parse or invalid coordinates. TwoDoublesStrategy is using it
incorrectly to indicate the strategy doesn't support the shape.
Perhaps UnsupportedOperationException is more fitting. I kind of prefer it
just slightly over IllegalArgumentException because I think of it here as
the strategy not supporting that shape.
The biggest point here is consistency across the strategies.
FYI for context there's also UnsupportedSpatialOperation, an Exception that
doesn't follow the naming convention but I'm ok with that. Its c'tor
mandates its association with an instance of SpatialOperation. So if a
strategy doesn't support an operation then it's got a special exception just
for that, but not also true for shape? Seems lopsided to me. I think my
preference is for this exception to be UnsupportedSpatialArgument that isn't
locked to either the shape or operation.
The attached patch doesn't go as far as UnsupportedSpatialArgument but it at
least bring consistent behavior.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (LUCENE-4374) Spatial- rename vector.TwoDoublesStrategy to vector.PointVectorStrategy

2012-09-22 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley reassigned LUCENE-4374:


Assignee: David Smiley

 Spatial- rename vector.TwoDoublesStrategy to vector.PointVectorStrategy
 ---

 Key: LUCENE-4374
 URL: https://issues.apache.org/jira/browse/LUCENE-4374
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.1

 Attachments: LUCENE-4374_Rename_TwoDoubles_to_PointVector.patch


 TwoDoubles isn't necessarily appropriate since it could be two floats, once 
 it is enhanced to make that configurable.  I like PointVector because it's 
 clear it indexes points.  Eventually I could imagine a CircleVectorStrategy 
 in the same package.
 This does suggest BBoxStrategy should be RectVectorStrategy in the vector 
 package.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4374) Spatial- rename vector.TwoDoublesStrategy to vector.PointVectorStrategy

2012-09-22 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-4374:
-

Attachment: LUCENE-4374_Rename_TwoDoubles_to_PointVector.patch

I already received Chris's +1 privately so I will commit shortly.

 Spatial- rename vector.TwoDoublesStrategy to vector.PointVectorStrategy
 ---

 Key: LUCENE-4374
 URL: https://issues.apache.org/jira/browse/LUCENE-4374
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.1

 Attachments: LUCENE-4374_Rename_TwoDoubles_to_PointVector.patch


 TwoDoubles isn't necessarily appropriate since it could be two floats, once 
 it is enhanced to make that configurable.  I like PointVector because it's 
 clear it indexes points.  Eventually I could imagine a CircleVectorStrategy 
 in the same package.
 This does suggest BBoxStrategy should be RectVectorStrategy in the vector 
 package.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-4374) Spatial- rename vector.TwoDoublesStrategy to vector.PointVectorStrategy

2012-09-22 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved LUCENE-4374.
--

   Resolution: Fixed
Fix Version/s: (was: 4.1)
   4.0

There was one breaking problem of pointVector instead of pointVector in the 
patch I fixed.

Committed to trunk, 4x, and 4.0 branches.

 Spatial- rename vector.TwoDoublesStrategy to vector.PointVectorStrategy
 ---

 Key: LUCENE-4374
 URL: https://issues.apache.org/jira/browse/LUCENE-4374
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0

 Attachments: LUCENE-4374_Rename_TwoDoubles_to_PointVector.patch


 TwoDoubles isn't necessarily appropriate since it could be two floats, once 
 it is enhanced to make that configurable.  I like PointVector because it's 
 clear it indexes points.  Eventually I could imagine a CircleVectorStrategy 
 in the same package.
 This does suggest BBoxStrategy should be RectVectorStrategy in the vector 
 package.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-4418) Improve RecursivePrefixTreeFilter's performance heuristic tunables

2012-09-23 Thread David Smiley (JIRA)

David Smiley created LUCENE-4418:


 Summary: Improve RecursivePrefixTreeFilter's performance heuristic 
tunables
 Key: LUCENE-4418
 URL: https://issues.apache.org/jira/browse/LUCENE-4418
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Priority: Minor


RecursivePrefixTreeFilter recursively decomposes grid cells until it gets to a 
threshold grid level (e.g. 4 away from max levels), at which point it does a 
brute force scan because it's faster once the number of terms is smaller.  So 
if max levels is 10, then if the threshold is 4 then it will switch to scanning 
at 6.  Ideally, the filter would know exactly how many terms there are in that 
grid -- i.e. given a hi  lo term, determine how many indexed terms are 
in-between without actually iterating to find out.  

Instead, it could use the # docs that a grid cell has as a heuristic.  It's not 
perfect but I think its much better because it's dynamic based on density of 
actual indexed data.  It's not perfect because many documents could refer to 
the same indexed point, or few documents with multi-valued data could refer to 
many indexed points.

Before I do this, I need to re-invigorate my testing efforts so I can come up 
with a default threshold.  And it's also dependent on things like query shape 
complexity. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2255) local params are not parsed in facet.pivot parameter

2012-09-23 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461469#comment-13461469
 ] 

David Smiley commented on SOLR-2255:


Thanks for your examination Yonik.  I plan to commit this to the 4x branch 
Monday, and it should eventually show up in v4.1.  For the changes.txt entry 
I'll say this:

SOLR-2255: Enhanced pivot faceting to use local-params in the same way that 
regular field value faceting can.  This means support for excluding a filter 
query, using a different output key, and specifying 'threads' to do 
facet.method=fcs concurrently.  PivotFacetHelper now extends SimpleFacet and 
the getFacetImplementation() extension hook was removed.  (dsmiley)

 local params are not parsed in facet.pivot parameter
 

 Key: SOLR-2255
 URL: https://issues.apache.org/jira/browse/SOLR-2255
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Julien Lirochon
Assignee: David Smiley
 Attachments: SOLR-2255_local-param_support_for_pivot_faceting.patch, 
 SOLR-2255_local-param_support_for_pivot_faceting.patch


 ...facet=truefacet.pivot={!ex=category}category_id,subcategory_idfq={!tag=category}category_id=42
 generates the following error : undefined field {!ex=category}category_id
 If you filter on subcategory_id, the facet.pivot result will contain only 
 results from this subcategory. It's a loss of function since you can't alter 
 this behavior with local params.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-4419) Test RecursivePrefixTree indexing non-point data

2012-09-23 Thread David Smiley (JIRA)

David Smiley created LUCENE-4419:


 Summary: Test RecursivePrefixTree indexing non-point data
 Key: LUCENE-4419
 URL: https://issues.apache.org/jira/browse/LUCENE-4419
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley


RecursivePrefixTreeFilter was modified in ~July 2011 to support spatial 
filtering of non-point indexed shapes.  It seems to work when playing with the 
capability but it isn't tested.  It really needs to be as this is a major 
feature.

I imagine an approach in which some randomly generated rectangles are indexed 
and then a randomly generated rectangle is queried.  The right answer can be 
calculated brute-force and then compared with the filter.  In order to deal 
with shape imprecision, the randomly generated shapes could be generated to fit 
a course grid (e.g. round everything to a 1 degree interval).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2255) local params are not parsed in facet.pivot parameter

2012-09-23 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461512#comment-13461512
 ] 

David Smiley commented on SOLR-2255:


Yonik, so are you proposing the whole thing be committed to 4.0 or just the 
SimpleFacets changes?

If the whole patch doesn't make it into 4.0, I propose that a deprecation 
warning to PivotFacetHelper.getFacetImplementation() being added to 4.0.

 local params are not parsed in facet.pivot parameter
 

 Key: SOLR-2255
 URL: https://issues.apache.org/jira/browse/SOLR-2255
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Julien Lirochon
Assignee: David Smiley
 Attachments: SOLR-2255_local-param_support_for_pivot_faceting.patch, 
 SOLR-2255_local-param_support_for_pivot_faceting.patch


 ...facet=truefacet.pivot={!ex=category}category_id,subcategory_idfq={!tag=category}category_id=42
 generates the following error : undefined field {!ex=category}category_id
 If you filter on subcategory_id, the facet.pivot result will contain only 
 results from this subcategory. It's a loss of function since you can't alter 
 this behavior with local params.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4419) Test RecursivePrefixTree indexing non-point data

2012-09-23 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461561#comment-13461561
]

David Smiley commented on LUCENE-4419:
--

I'm all for what you suggest -- a test that could be used by multiple
strategies. We're doing that already in fact in PortedSolr3Test. And the
StrategyTestCase has methods that facilitate using test files of sample data,
which is used by several tests such as TestPointVectorStrategy.

bq. I really don't see the benefit of randomly generating Shapes.

I could have sworn you told me we should add that to the Spatial4j todo list.

I like randomized tests because it can catch errors that a static test simply
didn't test for. This helped out tremendously when I worked out the bugs in
Circle-Rectangle intersection in Spatial4j.

Test RecursivePrefixTree indexing non-point data

Key: LUCENE-4419
URL: https://issues.apache.org/jira/browse/LUCENE-4419
Project: Lucene - Core
Issue Type: Improvement
Components: modules/spatial
Reporter: David Smiley

RecursivePrefixTreeFilter was modified in ~July 2011 to support spatial
filtering of non-point indexed shapes. It seems to work when playing with
the capability but it isn't tested. It really needs to be as this is a major
feature.
I imagine an approach in which some randomly generated rectangles are indexed
and then a randomly generated rectangle is queried. The right answer can be
calculated brute-force and then compared with the filter. In order to deal
with shape imprecision, the randomly generated shapes could be generated to
fit a course grid (e.g. round everything to a 1 degree interval).

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-4421) TermsFilter should use TermsEnum.seekExact not seekCeil

2012-09-24 Thread David Smiley (JIRA)

David Smiley created LUCENE-4421:


 Summary: TermsFilter should use TermsEnum.seekExact not seekCeil
 Key: LUCENE-4421
 URL: https://issues.apache.org/jira/browse/LUCENE-4421
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: David Smiley
Priority: Minor


TermsFilter line 82 is:

   if (termsEnum.seekCeil(br) == TermsEnum.SeekStatus.FOUND) {

I expected use of seekExact(...) since the Filter shouldn't need to
potentially advance to the one after.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-2255) local params are not parsed in facet.pivot parameter

2012-09-24 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved SOLR-2255.


   Resolution: Fixed
Fix Version/s: 4.1

Too late for 4.0, but I did get a @Deprecated annotation in there this morning. 
 It'll make it due to the respin.

I committed to trunk  4.1.

 local params are not parsed in facet.pivot parameter
 

 Key: SOLR-2255
 URL: https://issues.apache.org/jira/browse/SOLR-2255
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Julien Lirochon
Assignee: David Smiley
 Fix For: 4.1

 Attachments: SOLR-2255_local-param_support_for_pivot_faceting.patch, 
 SOLR-2255_local-param_support_for_pivot_faceting.patch


 ...facet=truefacet.pivot={!ex=category}category_id,subcategory_idfq={!tag=category}category_id=42
 generates the following error : undefined field {!ex=category}category_id
 If you filter on subcategory_id, the facet.pivot result will contain only 
 results from this subcategory. It's a loss of function since you can't alter 
 this behavior with local params.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2255) local params are not parsed in facet.pivot parameter

2012-09-24 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462423#comment-13462423
 ] 

David Smiley commented on SOLR-2255:


It was filed as a bug but I considered it a lack of a feature, and I changed 
the issue accordingly.  It's debatable.  I think the changes are relatively 
safe to the Solr codebase, but I have a suspicion that Ryan or Erik added that 
getFacetImplementation() that I removed and simply didn't notice my comments 
here to speak up about its merits.  But more importantly I want to be very 
judicious about what goes into a release branch.

 local params are not parsed in facet.pivot parameter
 

 Key: SOLR-2255
 URL: https://issues.apache.org/jira/browse/SOLR-2255
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Julien Lirochon
Assignee: David Smiley
 Fix For: 4.1

 Attachments: SOLR-2255_local-param_support_for_pivot_faceting.patch, 
 SOLR-2255_local-param_support_for_pivot_faceting.patch


 ...facet=truefacet.pivot={!ex=category}category_id,subcategory_idfq={!tag=category}category_id=42
 generates the following error : undefined field {!ex=category}category_id
 If you filter on subcategory_id, the facet.pivot result will contain only 
 results from this subcategory. It's a loss of function since you can't alter 
 this behavior with local params.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (LUCENE-4421) TermsFilter should use TermsEnum.seekExact not seekCeil

2012-09-24 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley reassigned LUCENE-4421:


Assignee: David Smiley

 TermsFilter should use TermsEnum.seekExact not seekCeil
 ---

 Key: LUCENE-4421
 URL: https://issues.apache.org/jira/browse/LUCENE-4421
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: David Smiley
Assignee: David Smiley
Priority: Minor

 TermsFilter line 82 is:
if (termsEnum.seekCeil(br) == TermsEnum.SeekStatus.FOUND) {
 I expected use of seekExact(...) since the Filter shouldn't need to
 potentially advance to the one after.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-4421) TermsFilter should use TermsEnum.seekExact not seekCeil

2012-09-24 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved LUCENE-4421.
--

   Resolution: Fixed
Fix Version/s: 4.1

Here's the one-liner change:
if (termsEnum.seekExact(br,true)) {

I figured useCache=true -- it's not documented on what cache is used but it 
seems most callers pass true.  Maybe someone other than me who can document it 
will eventually do so.

Committed to trunk  4x.

 TermsFilter should use TermsEnum.seekExact not seekCeil
 ---

 Key: LUCENE-4421
 URL: https://issues.apache.org/jira/browse/LUCENE-4421
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: David Smiley
Assignee: David Smiley
Priority: Minor
 Fix For: 4.1


 TermsFilter line 82 is:
if (termsEnum.seekCeil(br) == TermsEnum.SeekStatus.FOUND) {
 I expected use of seekExact(...) since the Filter shouldn't need to
 potentially advance to the one after.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-4444) SpatialArgsParser should let the context parse the shape string

2012-09-28 Thread David Smiley (JIRA)

David Smiley created LUCENE-:


 Summary: SpatialArgsParser should let the context parse the shape 
string
 Key: LUCENE-
 URL: https://issues.apache.org/jira/browse/LUCENE-
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley


SpatialArgsParser is not letting the SpatialContext read the shape string (via 
readShape(); instead it's using new 
SpatialArgsParser(ctx).readShape(...shapestring...).  For the standard 
SpatialContext there is no difference.  But the JTS extension has its own which 
parses WKT for polygon support, etc.

Quick fix of course but this really sucks if 4.0 won't have the ability to plug 
in alternative shapes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-4444) SpatialArgsParser should let the context parse the shape string

2012-09-28 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved LUCENE-.
--

   Resolution: Fixed
Fix Version/s: 4.1

Committed to trunk in r1391628  4x in r1391629.

 SpatialArgsParser should let the context parse the shape string
 ---

 Key: LUCENE-
 URL: https://issues.apache.org/jira/browse/LUCENE-
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.1

 Attachments: 
 LUCENE-_Use_SpatialContext_to_read_shape_strings.patch


 SpatialArgsParser is not letting the SpatialContext read the shape string 
 (via readShape(); instead it's using new 
 SpatialArgsParser(ctx).readShape(...shapestring...).  For the standard 
 SpatialContext there is no difference.  But the JTS extension has its own 
 which parses WKT for polygon support, etc.
 Quick fix of course but this really sucks if 4.0 won't have the ability to 
 plug in alternative shapes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4444) SpatialArgsParser should let the context parse the shape string

2012-10-01 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-:
-

Fix Version/s: (was: 4.1)
   4.0

I committed to 4.0 in r1392506  since 4.0 is being re-spun and this is fairly 
important.

http://lucene.472066.n3.nabble.com/VOTE-release-4-0-take-two-tp4010808p4011255.html

 SpatialArgsParser should let the context parse the shape string
 ---

 Key: LUCENE-
 URL: https://issues.apache.org/jira/browse/LUCENE-
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0

 Attachments: 
 LUCENE-_Use_SpatialContext_to_read_shape_strings.patch


 SpatialArgsParser is not letting the SpatialContext read the shape string 
 (via readShape(); instead it's using new 
 SpatialArgsParser(ctx).readShape(...shapestring...).  For the standard 
 SpatialContext there is no difference.  But the JTS extension has its own 
 which parses WKT for polygon support, etc.
 Quick fix of course but this really sucks if 4.0 won't have the ability to 
 plug in alternative shapes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-3913) SimplePostTool optimize does a redundant commit

2012-10-04 Thread David Smiley (JIRA)

David Smiley created SOLR-3913:
--

 Summary: SimplePostTool optimize does a redundant commit
 Key: SOLR-3913
 URL: https://issues.apache.org/jira/browse/SOLR-3913
 Project: Solr
  Issue Type: Improvement
  Components: scripts and tools
Reporter: David Smiley
Priority: Minor


At the end of SimplePostTool.execute() there is:
{code}
if (commit)   commit();
if (optimize) optimize();
{code}
Each of these calls involves a separate request to Solr.  The thing is, an 
optimize internally commits, and so the logic should forgo committing is 
optimize is true.

And as an aside, I think the 1kb pipe() buffer on line 893 is too small; it 
should be around 8kb (8192) bytes which is the same value as 
BufferedInputStream's default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4285) Improve FST API usability for mere mortals

2012-10-05 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470555#comment-13470555
 ] 

David Smiley commented on LUCENE-4285:
--

I just found out that an FST builder.finish() returns null if there's no input 
basically.  That is bad API design; it should return an FST with nothing init.  
For now I have to have littered null checks.

 Improve FST API usability for mere mortals
 --

 Key: LUCENE-4285
 URL: https://issues.apache.org/jira/browse/LUCENE-4285
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/FSTs
Reporter: David Smiley

 FST technology is something that has brought amazing advances to Lucene, yet 
 the API is hard to use for the vast majority of users like me.  I know that 
 performance of FSTs is really important, but surely a lot can be done without 
 sacrificing that.
 (comments will hold specific ideas and problems)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4285) Improve FST API usability for mere mortals

2012-10-06 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471081#comment-13471081
 ] 

David Smiley commented on LUCENE-4285:
--

I admit checked exceptions would have alerted me to my bug, but that doesn't 
make the API any nicer -- I still need null checks littered through my FST user 
code now.  I don't know the FST internals but I'd be surprised to hear that 
adding support for an empty FST adds appreciable overhead.  If this overhead 
we're discussing is a simple conditional check, then this is net-zero since as 
it is I need these null checks on my end of the API due to my FST being 
potentially null.

 Improve FST API usability for mere mortals
 --

 Key: LUCENE-4285
 URL: https://issues.apache.org/jira/browse/LUCENE-4285
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/FSTs
Reporter: David Smiley

 FST technology is something that has brought amazing advances to Lucene, yet 
 the API is hard to use for the vast majority of users like me.  I know that 
 performance of FSTs is really important, but surely a lot can be done without 
 sacrificing that.
 (comments will hold specific ideas and problems)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3221) Make Shard handler threadpool configurable

2012-10-10 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13473791#comment-13473791
 ] 

David Smiley commented on SOLR-3221:


Greg, I heard you intend to add a small patch to flip Solr 4's default on this 
feature?  I was picking Erick since forever and he pawned it off on you.

 Make Shard handler threadpool configurable
 --

 Key: SOLR-3221
 URL: https://issues.apache.org/jira/browse/SOLR-3221
 Project: Solr
  Issue Type: Improvement
Affects Versions: 3.6, 4.0-ALPHA
Reporter: Greg Bowyer
Assignee: Erick Erickson
  Labels: distributed, http, shard
 Fix For: 3.6, 4.0-ALPHA

 Attachments: SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, 
 SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, 
 SOLR-3221-3x_branch.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, 
 SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch


 From profiling of monitor contention, as well as observations of the
 95th and 99th response times for nodes that perform distributed search
 (or ‟aggregator‟ nodes) it would appear that the HttpShardHandler code
 currently does a suboptimal job of managing outgoing shard level
 requests.
 Presently the code contained within lucene 3.5's SearchHandler and
 Lucene trunk / 3x's ShardHandlerFactory create arbitrary threads in
 order to service distributed search requests. This is done presently to
 limit the size of the threadpool such that it does not consume resources
 in deployment configurations that do not use distributed search.
 This unfortunately has two impacts on the response time if the node
 coordinating the distribution is under high load.
 The usage of the MaxConnectionsPerHost configuration option results in
 aggressive activity on semaphores within HttpCommons, it has been
 observed that the aggregator can have a response time far greater than
 that of the searchers. The above monitor contention would appear to
 suggest that in some cases its possible for liveness issues to occur and
 for simple queries to be starved of resources simply due to a lack of
 attention from the viewpoint of context switching.
 With, as mentioned above the http commons connection being hotly
 contended
 The fair, queue based configuration eliminates this, at the cost of
 throughput.
 This patch aims to make the threadpool largely configurable allowing for
 those using solr to choose the throughput vs latency balance they
 desire.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-3942) Cannot use geodist() function with edismax

2012-10-14 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley reassigned SOLR-3942:
--

Assignee: David Smiley

 Cannot use geodist() function with edismax
 --

 Key: SOLR-3942
 URL: https://issues.apache.org/jira/browse/SOLR-3942
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: Windows Server 2008 R2, Windows 7
Reporter: Shane Andrade
Assignee: David Smiley
Priority: Critical

 Using the spatial example from the wiki when boosting with edismax:
 http://localhost:8983/solr/select?defType=edismaxq.alt=*:*fq={!geofilt}sfield=storept=45.15,-93.85d=50boost=recip(geodist(),2,200,20)sort=score%20desc
 Produces the following error:
 lst name=error
 str name=msg
 org.apache.lucene.queryparser.classic.ParseException: Spatial field must 
 implement 
 MultiValueSource:store{type=geohash,properties=indexed,stored,omitTermFreqAndPositions}
 /str
 int name=code400/int
 /lst
 When the defType is changed to dismax, the query works as expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3942) Cannot use geodist() function with edismax

2012-10-14 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13475954#comment-13475954
 ] 

David Smiley commented on SOLR-3942:


I ran your query against Solr 4.0 and got no error.  At first I got 0 results, 
then I indexed the xml example docs, and then I got 6 results.

 Cannot use geodist() function with edismax
 --

 Key: SOLR-3942
 URL: https://issues.apache.org/jira/browse/SOLR-3942
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: Windows Server 2008 R2, Windows 7
Reporter: Shane Andrade
Assignee: David Smiley
Priority: Critical

 Using the spatial example from the wiki when boosting with edismax:
 http://localhost:8983/solr/select?defType=edismaxq.alt=*:*fq={!geofilt}sfield=storept=45.15,-93.85d=50boost=recip(geodist(),2,200,20)sort=score%20desc
 Produces the following error:
 lst name=error
 str name=msg
 org.apache.lucene.queryparser.classic.ParseException: Spatial field must 
 implement 
 MultiValueSource:store{type=geohash,properties=indexed,stored,omitTermFreqAndPositions}
 /str
 int name=code400/int
 /lst
 When the defType is changed to dismax, the query works as expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (LUCENE-4464) Intersects spatial query returns polygons it shouldn't

2012-10-15 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley reassigned LUCENE-4464:


Assignee: David Smiley

 Intersects spatial query returns polygons it shouldn't
 

 Key: LUCENE-4464
 URL: https://issues.apache.org/jira/browse/LUCENE-4464
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Affects Versions: 3.6.1
 Environment: linux and windows
Reporter: solr-user
Assignee: David Smiley
Priority: Critical
  Labels: solr, spatial, spatialsearch

 full description, including sample schema and data, can be found at 
 http://lucene.472066.n3.nabble.com/quot-Intersects-quot-spatial-query-returns-polygons-it-shouldn-t-td4008646.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4464) Intersects spatial query returns polygons it shouldn't

2012-10-15 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476690#comment-13476690
 ] 

David Smiley commented on LUCENE-4464:
--

I'm starting to diagnose this. One problem I see is that the 1st polygon has a 
self-intersection. I got this error when trying to generate a KML file 
depicting the geohash rectangles via the Solr-Spatial-Sandbox spatial-demo:

com.spatial4j.core.exception.InvalidShapeException: Ring Self-intersection at 
or near point (-92.81473397710002, 45.20993823293909, NaN)
at com.spatial4j.core.shape.jts.JtsGeometry.init(JtsGeometry.java:90)
at 
com.spatial4j.core.io.JtsShapeReadWriter.readShape(JtsShapeReadWriter.java:93)
at 
com.spatial4j.core.context.SpatialContext.readShape(SpatialContext.java:195)
at 
com.spatial4j.demo.servlet.GridInfoServlet.doPost(GridInfoServlet.java:113)

I also got this error when trying validating the polygon via the JTS 
TestBuilder (a GUI); I attached a screenshot.  It's very strange that I'm 
seeing this error yet you are not; you wouldn't have been able to index it 
without getting this error.



 Intersects spatial query returns polygons it shouldn't
 

 Key: LUCENE-4464
 URL: https://issues.apache.org/jira/browse/LUCENE-4464
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Affects Versions: 3.6.1
 Environment: linux and windows
Reporter: solr-user
Assignee: David Smiley
Priority: Critical
  Labels: solr, spatial, spatialsearch
 Attachments: LUCENE-4464 self intersect.png


 full description, including sample schema and data, can be found at 
 http://lucene.472066.n3.nabble.com/quot-Intersects-quot-spatial-query-returns-polygons-it-shouldn-t-td4008646.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4464) Intersects spatial query returns polygons it shouldn't

2012-10-15 Thread David Smiley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-4464:
-

Attachment: LUCENE-4464 self intersect.png

 Intersects spatial query returns polygons it shouldn't
 

 Key: LUCENE-4464
 URL: https://issues.apache.org/jira/browse/LUCENE-4464
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Affects Versions: 3.6.1
 Environment: linux and windows
Reporter: solr-user
Assignee: David Smiley
Priority: Critical
  Labels: solr, spatial, spatialsearch
 Attachments: LUCENE-4464 self intersect.png


 full description, including sample schema and data, can be found at 
 http://lucene.472066.n3.nabble.com/quot-Intersects-quot-spatial-query-returns-polygons-it-shouldn-t-td4008646.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4464) Intersects spatial query returns polygons it shouldn't

2012-10-15 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476703#comment-13476703
 ] 

David Smiley commented on LUCENE-4464:
--

Oh, I know why you didn't get that error.  You're using an older version of 
Spatial4j back when it was a portion of LSP.  And back then, JtsGeometry didn't 
ask JTS to validate the geometry but it does now.

 Intersects spatial query returns polygons it shouldn't
 

 Key: LUCENE-4464
 URL: https://issues.apache.org/jira/browse/LUCENE-4464
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Affects Versions: 3.6.1
 Environment: linux and windows
Reporter: solr-user
Assignee: David Smiley
Priority: Critical
  Labels: solr, spatial, spatialsearch
 Attachments: LUCENE-4464 self intersect.png


 full description, including sample schema and data, can be found at 
 http://lucene.472066.n3.nabble.com/quot-Intersects-quot-spatial-query-returns-polygons-it-shouldn-t-td4008646.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4464) Intersects spatial query returns polygons it shouldn't

2012-10-15 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley updated LUCENE-4464:
-

Attachment: LUCENE-4464_polygon_almost_touch_test.patch
LUCENE-4464 google maps geohashes.png

I attached another screenshot of Google Earth with KML loaded for the 1st
indexed polygon and for the query shape. It shows the lines almost touch but
not quite -- showing ~28.4 meters in-between. The KML files were generated via
the spatial-demo app, with 0.01 distErrPct. I was able to load the indexed
polygon my adjusting the data near the self-intersection error.

I also attached a new test and I was not able to reproduce the problem you
report, even with the default 2.5% distErrPct. I had to raise it to about 6%
until I saw a false intersection. The fact that you see an intersection and I
don't could very well be related to small improvements in the interpretation of
distErrPct / distErr / maxDistErr that were done a couple months ago.

I'm going to commit this patch tomorrow. It does an assume call to check if
JTS is on the classpath. The test has no compile-time dependencies on JTS,
just runtime.

Intersects spatial query returns polygons it shouldn't

Key: LUCENE-4464
URL: https://issues.apache.org/jira/browse/LUCENE-4464
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial
Affects Versions: 3.6.1
Environment: linux and windows
Reporter: solr-user
Assignee: David Smiley
Priority: Critical
Labels: solr, spatial, spatialsearch
Attachments: LUCENE-4464 google maps geohashes.png,
LUCENE-4464_polygon_almost_touch_test.patch, LUCENE-4464 self intersect.png

full description, including sample schema and data, can be found at
http://lucene.472066.n3.nabble.com/quot-Intersects-quot-spatial-query-returns-polygons-it-shouldn-t-td4008646.html

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3954) Option to have updateHandler and DIH skip updateLog

2012-10-16 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13477333#comment-13477333
 ] 

David Smiley commented on SOLR-3954:


FWIW I've seen the updateLog grow to huge sizes for my bulk import.  I commit 
at the end (of course) no soft commits or auto commits in-between.  The 
updateLog is a hinderance during bulk imports.

 Option to have updateHandler and DIH skip updateLog
 ---

 Key: SOLR-3954
 URL: https://issues.apache.org/jira/browse/SOLR-3954
 Project: Solr
  Issue Type: Improvement
  Components: update
Affects Versions: 4.0
Reporter: Shawn Heisey
 Fix For: 4.1


 The updateLog feature makes updates take longer, likely because of the I/O 
 time required to write the additional information to disk.  It may take as 
 much as three times as long for the indexing portion of the process.  I'm not 
 sure whether it affects the time to commit, but I would imagine that the 
 difference there is small or zero.  When doing incremental updates/deletes on 
 an existing index, the time lag is probably very small and unimportant.
 When doing a full reindex (which may happen via DIH), especially if this is 
 done in a build core that is then swapped with a live core, this performance 
 hit is unacceptable.  It seems to make the import take about three times as 
 long.
 An option to have an update skip the updateLog would be very useful for these 
 situations.  It should have a method in SolrJ and be exposed in DIH as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

< 1 2 3 4 5 6 7 8 9 10 >

301 - 400 of 5659 matches

Mail list logo