from:"Chris Male \(JIRA\)"

[jira] Commented: (LUCENE-2395) Add a scoring DistanceQuery that does not need caches and separate filters

2010-04-15 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2395:

This will replace the work I was doing on improving the DistanceFilter and the
DistanceSortSource. Instead we will have a proper DistanceQuery where the
sorting is done through the existing sorting by score functionality in Lucene.
The CartesianShapeFilter will then be able to be used as a Filter with the new
Query.

This also addresses the current problems with caching calculated distances and
means that Spatial will work with per segment.

Add a scoring DistanceQuery that does not need caches and separate filters
--

Key: LUCENE-2395
URL: https://issues.apache.org/jira/browse/LUCENE-2395
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/spatial
Reporter: Uwe Schindler
Fix For: 3.1

In a chat with Chris Male and my own ideas when implemnting for PANGAEA, I
thought about the broken distance query in contrib. It lacks the folloing
features:
- It needs a query for the encldoing bbox (which is constant score)
- It needs a separate filter for filtering out distances
- It has no scoring, so if somebody wants to sort by distance, he needs to
use the custom sort. For that to work, spatial caches distance calculation
(which is borken for multi-segment search)
The idea is now to combine all three things into one query, but customizeable:
We first thought about extending CustomScoreQuery and calculate the distance
from FieldCache in the customScore method and return a score of 1 for
distance=0, score=0 on the max distance and score0 for farer hits, that are
in the bounding box but not in the distance circle. To filter out such
negative scores, we would need to override the scorer in CustomScoreQuery
which is priate.
My proposal is now to use a very stripped down CustomScoreQuery (but not
extend it) that does call a method getDistance(docId) in its scorer's advance
and nextDoc that calculates the distance for the current doc. It stores this
distance also in the scorer. If the distance maxDistance it throws away the
hit and calls nextDoc() again. The score() method will reurn per default
weight.value*(maxDistance - distance)/maxDistance and uses the precalculated
distance. So the distance is only calculated one time in nextDoc()/advance().
To be able to plug in custom scoring, the following methods in the query can
be overridden:
- float getDistanceScore(double distance) - returns per default: (maxDistance
- distance)/maxDistance; allows score customization
- DocIdSet getBoundingBoxDocIdSet(Reader, LatLng sw, LatLng ne) - returns an
DocIdSet for the bounding box. Per default it returns e.g. the docIdSet of a
NRF or a cartesian tier filter. You can even plug in any other DocIdSet, e.g.
wrap a Query with QueryWrapperFilter
- support a setter for the GeoDistanceCalculator that is used by the scorer
to get the distance.
This query is almost finished in my head, it just needs coding :-)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (LUCENE-1930) Scale moderator not in line with sinusoidal projector

2010-04-05 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-1930:


Nicolas,

Is this patch contained in one of your other issues?  If so, I'd like to close 
this one up to prevent confusion.

 Scale moderator not in line with sinusoidal projector
 -

 Key: LUCENE-1930
 URL: https://issues.apache.org/jira/browse/LUCENE-1930
 Project: Lucene - Java
  Issue Type: Bug
  Components: contrib/spatial
Affects Versions: 2.9, 2.9.1, 3.0
Reporter: Nicolas Helleringer
Assignee: Chris Male
 Attachments: LUCENE-1930.patch


 Current implementation in spatial Lucene does :
 public double getTierBoxId (double latitude, double longitude) {
   double[] coords = projector.coords(latitude, longitude);
   double id = getBoxId(coords[0]) + (getBoxId(coords[1]) / 
 tierVerticalPosDivider);
   return id ;
 }
 private double getBoxId (double coord){
   return Math.floor(coord / (idd / this.tierLength));
 }
 with
 Double idd = new Double(180);
 in the CartesianTierPlotter constructor.
 But current Sinusoidal Projector set and used in initialisation of 
 CartesianTierPlotter does :
 public double[] coords(double latitude, double longitude) {
   double rlat = Math.toRadians(latitude);
   double rlong = Math.toRadians(longitude);
   double nlat = rlong * Math.cos(rlat);
   double r[] = {nlat, rlong};
 return r;
 }
 Thus we moderate with idd = 180 a coord that is in a Radian space.
 Things to do :
 1°) fix idd to : double idd= PI;
 2°) Move idd definition to IProjector interface : The coord space should 
 belong to the projector doing the job. Change the code from CTP to use that 
 new interface.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Assigned: (LUCENE-1930) Scale moderator not in line with sinusoidal projector

2010-04-05 Thread Chris Male (JIRA)


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

Chris Male reassigned LUCENE-1930:
--

Assignee: Chris Male

 Scale moderator not in line with sinusoidal projector
 -

 Key: LUCENE-1930
 URL: https://issues.apache.org/jira/browse/LUCENE-1930
 Project: Lucene - Java
  Issue Type: Bug
  Components: contrib/spatial
Affects Versions: 2.9, 2.9.1, 3.0
Reporter: Nicolas Helleringer
Assignee: Chris Male
 Attachments: LUCENE-1930.patch


 Current implementation in spatial Lucene does :
 public double getTierBoxId (double latitude, double longitude) {
   double[] coords = projector.coords(latitude, longitude);
   double id = getBoxId(coords[0]) + (getBoxId(coords[1]) / 
 tierVerticalPosDivider);
   return id ;
 }
 private double getBoxId (double coord){
   return Math.floor(coord / (idd / this.tierLength));
 }
 with
 Double idd = new Double(180);
 in the CartesianTierPlotter constructor.
 But current Sinusoidal Projector set and used in initialisation of 
 CartesianTierPlotter does :
 public double[] coords(double latitude, double longitude) {
   double rlat = Math.toRadians(latitude);
   double rlong = Math.toRadians(longitude);
   double nlat = rlong * Math.cos(rlat);
   double r[] = {nlat, rlong};
 return r;
 }
 Thus we moderate with idd = 180 a coord that is in a Radian space.
 Things to do :
 1°) fix idd to : double idd= PI;
 2°) Move idd definition to IProjector interface : The coord space should 
 belong to the projector doing the job. Change the code from CTP to use that 
 new interface.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-1777) Error on distance query where miles 1.0

2010-04-05 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-1777:


Nicolas,

Can you just confirm this was fixed in LUCENE-1504? If so, I'll close this up

 Error on distance query where miles  1.0
 -

 Key: LUCENE-1777
 URL: https://issues.apache.org/jira/browse/LUCENE-1777
 Project: Lucene - Java
  Issue Type: Bug
  Components: contrib/spatial
Affects Versions: 2.9
Reporter: Glen Stampoultzis
Assignee: Chris Male
 Attachments: LUCENE-1777.patch


 If miles is under 1.0 distance query will break.
 To reproduce modify the file
 http://svn.apache.org/viewvc/lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java?revision=794721
 And set the line:
 final double miles = 6.0;
 to 
 final double miles = 0.5;

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Assigned: (LUCENE-1777) Error on distance query where miles 1.0

2010-04-05 Thread Chris Male (JIRA)


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

Chris Male reassigned LUCENE-1777:
--

Assignee: Chris Male

 Error on distance query where miles  1.0
 -

 Key: LUCENE-1777
 URL: https://issues.apache.org/jira/browse/LUCENE-1777
 Project: Lucene - Java
  Issue Type: Bug
  Components: contrib/spatial
Affects Versions: 2.9
Reporter: Glen Stampoultzis
Assignee: Chris Male
 Attachments: LUCENE-1777.patch


 If miles is under 1.0 distance query will break.
 To reproduce modify the file
 http://svn.apache.org/viewvc/lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java?revision=794721
 And set the line:
 final double miles = 6.0;
 to 
 final double miles = 0.5;

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Assigned: (LUCENE-1895) Point2D defines equals by comparing double types with ==

2010-04-05 Thread Chris Male (JIRA)


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

Chris Male reassigned LUCENE-1895:
--

Assignee: Chris Male

 Point2D defines equals by comparing double types with ==
 

 Key: LUCENE-1895
 URL: https://issues.apache.org/jira/browse/LUCENE-1895
 Project: Lucene - Java
  Issue Type: Bug
  Components: contrib/spatial
Reporter: Mark Miller
Assignee: Chris Male
Priority: Trivial

 Ideally, this should allow for a margin of error right?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-1895) Point2D defines equals by comparing double types with ==

2010-04-05 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-1895:


Mark,

Its been over 6 months I know, but do you remember why you suggested this? Was 
there a particular case you had in mind? 

I'd like to see Point2D (or Point as I'd like it renamed) to be an all purpose 
class for the spatial work, so it seems comparing the values exactly would be a 
good idea.

 Point2D defines equals by comparing double types with ==
 

 Key: LUCENE-1895
 URL: https://issues.apache.org/jira/browse/LUCENE-1895
 Project: Lucene - Java
  Issue Type: Bug
  Components: contrib/spatial
Reporter: Mark Miller
Assignee: Chris Male
Priority: Trivial

 Ideally, this should allow for a margin of error right?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-1895) Point2D defines equals by comparing double types with ==

2010-04-05 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-1895:


{quote}
My generic worry is that you can come to the same double value in two different 
ways, but == will not find them to be equal.
{quote}

How so?

 Point2D defines equals by comparing double types with ==
 

 Key: LUCENE-1895
 URL: https://issues.apache.org/jira/browse/LUCENE-1895
 Project: Lucene - Java
  Issue Type: Bug
  Components: contrib/spatial
Reporter: Mark Miller
Assignee: Chris Male
Priority: Trivial

 Ideally, this should allow for a margin of error right?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Assigned: (LUCENE-1921) Absurdly large radius (miles) search fails to include entire earth

2010-04-05 Thread Chris Male (JIRA)


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

Chris Male reassigned LUCENE-1921:
--

Assignee: Chris Male

 Absurdly large radius (miles) search fails to include entire earth
 --

 Key: LUCENE-1921
 URL: https://issues.apache.org/jira/browse/LUCENE-1921
 Project: Lucene - Java
  Issue Type: Bug
  Components: contrib/spatial
Affects Versions: 2.9
Reporter: Michael McCandless
Assignee: Chris Male
Priority: Minor
 Fix For: 3.1


 Spinoff from LUCENE-1781.
 If you do a very large (eg 10 miles) radius search then the
 lat/lng bound box wraps around the entire earth and all points should
 be accepted.  But this fails today (many points are rejected).  It's
 easy to see the issue: edit TestCartesian, and insert a very large
 miles into either testRange or testGeoHashRange.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-1895) Point2D defines equals by comparing double types with ==

2010-04-05 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-1895:


As suggested, its best to use an epsilon when comparing doubles, much like 
junit.

I will work on a patch.

 Point2D defines equals by comparing double types with ==
 

 Key: LUCENE-1895
 URL: https://issues.apache.org/jira/browse/LUCENE-1895
 Project: Lucene - Java
  Issue Type: Bug
  Components: contrib/spatial
Reporter: Mark Miller
Assignee: Chris Male
Priority: Trivial

 Ideally, this should allow for a margin of error right?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-31 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2310:

I think this is a great idea.

Having a clear separation from the 'core space' where the indexer sits, and the
'user space' gives us the freedom to address the Document/Fieldable class stack
problems.

We could introduce an IndexableDocument abstraction (which Document would
implement) which provides the stripped down API that the indexer needs for
Documents, which is just a way to get the fields to index and store.

Given that the indexer need only know the name, type and value/tokenstream for
a Field, we can visualize this as just a tuple. Therefore the
IndexableDocument, rather than returning Fields, could return instances of a
new Tuple class, which would be immutable. Field would then implement Tuple.

Document and Field would then be exactly as suggested, 'user space' app
friendly mutable classes.

On the search side, the 'core space' wouldn't know of the idea of a Document,
but rather a set of tuples. We would then allow different consumers of those
tuples to be provided. One such consumer would use the tuples to build
Documents and Fields again.

Reduce Fieldable, AbstractField and Field complexity

Key: LUCENE-2310
URL: https://issues.apache.org/jira/browse/LUCENE-2310
Project: Lucene - Java
Issue Type: Sub-task
Components: Index
Reporter: Chris Male
Attachments: LUCENE-2310-Deprecate-AbstractField-CleanField.patch,
LUCENE-2310-Deprecate-AbstractField.patch,
LUCENE-2310-Deprecate-AbstractField.patch,
LUCENE-2310-Deprecate-AbstractField.patch,
LUCENE-2310-Deprecate-DocumentGetFields-core.patch,
LUCENE-2310-Deprecate-DocumentGetFields.patch,
LUCENE-2310-Deprecate-DocumentGetFields.patch

In order to move field type like functionality into its own class, we really
need to try to tackle the hierarchy of Fieldable, AbstractField and Field.
Currently AbstractField depends on Field, and does not provide much more
functionality that storing fields, most of which are being moved over to
FieldType. Therefore it seems ideal to try to deprecate AbstractField (and
possible Fieldable), moving much of the functionality into Field and
FieldType.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-31 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2310:


{quote}
Can we just name it Indexable, and omit Document from it? That way, it's both 
shorter and less chances for users to directly link it w/ Document.
{quote}

+1

{quote}
One thing I didn't understand though, is what will happen to ir/is.doc() 
method? Will those be deprecated in favor of some other class which receives an 
IR as parameter and knows how to re-construct Indexable(Document)?
{quote}

I imagine some sort of callback which the IR/IS call with the information they 
take from the index.  One default implementation we could provide would 
re-construct Indexables, and one could re-construct Documents for the userspace.

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField-CleanField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields-core.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-31 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2310:


Earwin,

Yeah definitely we want to keep things separate.  I am infavour of Indexable 
being an indexing only construct, staying in the index part of the core space.  
However Document will be a user space construct that spans both indexing and 
searching since its API is designed to be flexible and easy to use and 
manipulate.

Writing implements of Indexable will be an expert thing I imagine, so if you 
index bytes taken from a socket, then I imagine you'll choose an implementation 
on the search side that can handle it.  If your stream from a socket has some 
custom stuff, then you could write a custom consumer on the search side that 
builds whatever search construct you want.

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField-CleanField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields-core.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-31 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2310:


Hi Uwe,

I envisaged the Indexable providing Tuples of  field name, field type, and 
TokenStream as it is today.  So I think we shouldn't run into any problems?

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField-CleanField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields-core.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2359) CartesianPolyFilterBuilder doesn't handle edge case around the 180 meridian

2010-03-31 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2359:


Hi Nicolas,

Sorry I hadn't seen that you had been working on this.  I will create a patch 
based on your work so we can get this fixed up in the next day or two.

 CartesianPolyFilterBuilder doesn't handle edge case around the 180 meridian
 ---

 Key: LUCENE-2359
 URL: https://issues.apache.org/jira/browse/LUCENE-2359
 Project: Lucene - Java
  Issue Type: Bug
  Components: contrib/spatial
Affects Versions: 2.9, 2.9.1, 2.9.2, 3.0, 3.0.1
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Attachments: LUCENE-2359.patch


 Test case:  
 Points all around the globe, plus two points at 0, 179.9 and 0,-179.9 (on 
 each side of the meridian).  Then, do a Cartesian Tier filter on a point 
 right near those two.  It will return all the points when it should just 
 return those two.
 The flawed logic is in the else clause below:
 {code}
 if (longX2 != 0.0) {
   //We are around the prime meridian
   if (longX == 0.0) {
   longX = longX2;
   longY = 0.0;
   shape = getShapeLoop(shape,ctp,latX,longX,latY,longY);
   } else {//we are around the 180th longitude
   longX = longX2;
   longY = -180.0;
   shape = getShapeLoop(shape,ctp,latY,longY,latX,longX);
   }
 {code}
 Basically, the Y and X values are transposed.  This currently says go from 
 longY (-180) all the way around  to longX which is the lower left longitude 
 of the box formed.  Instead, it should go from the lower left long to -180.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2350) Refactor/Cleanup Lucene Spatial

2010-03-26 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2350:


+1

Most of my patches for Spatial are doing this very work.  I will connect them 
all here and we can go through what still needs work.

 Refactor/Cleanup Lucene Spatial
 ---

 Key: LUCENE-2350
 URL: https://issues.apache.org/jira/browse/LUCENE-2350
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Grant Ingersoll

 Lucene spatial needs a lot of work.  We should clean it up and allow for 
 people to use different distances (i.e. don't assume Haversine), etc.  We 
 should also merge the Solr and Lucene code into a single lib, where possible 
 (starting w/ Distance Utils).   Update the distance filter to allow for 
 pluggable distance measures. 
 Also do things like not assume everything is in degrees (users may already 
 store radians, for instance) and use constants for 
 conversions/multiplications instead of division.
  End goal:  No more experimental status.  Clean up the APIs, use the more 
 common nomenclature for tiers and be consistent across Lucene and Solr.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-21 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2310:
---

Attachment: LUCENE-2310-Deprecate-DocumentGetFields.patch

Attached new version of Document change which makes the Iterator unmodifiable.  
 Noted this fact in the javadoc for the iterator() method.

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField-CleanField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields-core.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-21 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2310:


The patch I just attached makes a test in InstantiatedIndex fail because it 
tries to remove a field through the iterator.  This illustrates a concern I 
have with making the iterator unmodifiable, there is no efficient way to remove 
a field while iterating, without also running into a CCE.  I will think over 
this issue a little bit before deciding whether to continue with the 
unmodifiable iterator or not.

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField-CleanField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields-core.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-20 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2310:
---

Attachment: LUCENE-2310-Deprecate-AbstractField-CleanField.patch

New version of the AbstractField deprecation patch which cleans up Field so its 
more readable, deferring documentation to Fieldable where possible in 
preparation for deprecating most the methods in Fieldable. 

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField-CleanField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-20 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2310:
---

Attachment: LUCENE-2310-Deprecate-DocumentGetFields.patch

Attaching patch for changes to Document implementing above ideas discussed above

- Document#getFields() is deprecated
- Document now implements IterableFieldable and provides an iterator() method
- Added a getNumFields() method for returning the number of fields in a Document

Having not paid attention earlier, there is already a removeFields method in 
Document, so it didn't need to be added.

There are some greater problems with Document related to this issue.  It 
provides methods for both Fieldables and Fields, getField(String) for example, 
could throw a ClassCastException if used in combination with AbstractField.  
Because the overall goal of this work is to reduce these 3 classes to just 
Field in 4.x, I think we can leave the methods as most will be deprecated.  
However some documentation improvements might prevent any CCEs.

I'll spin off another issue later to do that once this stuff has been committed.

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField-CleanField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-20 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2310:
---

Attachment: LUCENE-2310-Deprecate-DocumentGetFields-core.patch

Attaching patch that migrates core (including tests) away from 
Document#getFields().

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField-CleanField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields-core.patch, 
 LUCENE-2310-Deprecate-DocumentGetFields.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-16 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2310:

Hi Shai,

{quote}
i like the idea of Document to implement Iterable, but how does that solve the
case where someone wants to query how many fields a document has?
{quote}

It doesn't, but then I'd add a numFields() method maybe. It seems like
something with a small use case and so having it has a method on the side seems
ideal.

{quote}
Will you still have getFields(), only now it will return an unmodifiable
collection?
{quote}

Yes and no. getFields will remain but with a modifiable list. I will then
deprecate the method and recommend people use the Iterable. This gives
everybody a chance to migrate during the 3.x versions.

{quote}
Maybe just do: (1) Doc implements Iterable and (2) Doc exposes numFIelds(),
add(Field)?
{quote}

Yup lets do that. Unfortunately getFields will remain until 4.0.

{quote}
About remove(field), I thought of a possible scenario though I still don't
think it's interesting enough - suppose that you pass your Document through a
processing pipeline/chain, each handler adds fields as metadata to the
Document. For example, annotators. It might be that a field A exists, only for
a handler down the chain to understand A's meaning and then replace it w/ A1
and A2. For that you'll want to be able to move a field ... I guess we could
add a remove method to Document, and if it'll be called while the fields are
iterated on, a CME will be thrown, which is perfectly fine with me.
{quote}

With the idea of having remove(...) I am trying to foresee what people might be
doing via getFields() and thus are not going to be able to do when its gone.
We will have the ability to add and iterate, so having the functionality to
remove seems to complete it. I completely agree that if something happens and
a CME is thrown, then that problem should be left to the user.

I think this clarifies this direction. Document will be changed as follows:
- Document will become IterableFieldable
- getFields() will be deprecated in favour of the Iterable
- numFields() will be added returning the number of fields
- remove(String) will be added allowing someone to remove Fields with the given
name. If a CME occurs, thats up to the user to handle.

Cheers Shai!

Reduce Fieldable, AbstractField and Field complexity

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-16 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2310:

{quote}
So overall we agree on the changes that need to be made. BTW, when you
deprecate a method, you usually change it to call the new API or change it to
use the new data structures or whatever. So we need to think how to impl
getFields such that if one calls remove, numFields or use the iterator on an
interleving manner, his code doesn't break ... I don't think it should be hard
but it might be a good idea to even write such (deprecated) unit test
{quote}

I'm not sure we have to change getFields. We can just deprecate it, and point
people to the new methods. I think it'd be more effort than its worth to
create a List impl that calls the new methods. Was that what you were
implying? I do agree its worth writing a test to ensure all old functionality
can be done via the new methods somehow.

Reduce Fieldable, AbstractField and Field complexity

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-16 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2310:


I recommend we keep it as a List since that facilitates having different 
iterators by FieldType criteria more.  A Map would support get and remove 
better, but I think we want to move people to using Iterators and the remove 
method is there for a case we don't know of yet.

I'll create a patch with these ideas shortly.

Cheers!

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-14 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2310:

Spent more time pondering how to deprecate Fieldable and the major issue is
Document#getFields(), which returns a modifiable ListFieldable. Because it
is modifiable, consumers can add to it directly rather than through Document.

If it were unmodifiable, then it would be possible to control adding Fieldables
in Document, which would then allow us to wrap Fieldable instances in a Field
subclass, meaning Document would only have a ListField.

Given this limitation, I'm currently thinking about not trying to deprecate
Fieldable in 3.x, but instead adding the unmodifiable list method and
deprecating #getFields(). I would also add some functionality for removing
Fieldables, which seems to be all thats lack in Document. Then in 4.x I would
deprecate Fieldable.

Slow process, but I think by deprecating AbstractField now we have already made
a step forward to improving this hierarchy in preparation for the FieldType
classes.

Remaining in this work is a code cleanup of all 3 classes, so that code is
understandable when we add in FieldType.

Reduce Fieldable, AbstractField and Field complexity

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-14 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2310:

Hi Shai,

{quote}
How about if getFields() will return an IterableField? It'll need to be
deprecated and a new method created, but it can be simple enough solution to
avoid one adding fields directly to Document w/o passing through doc.add first.
{quote}

I'm not really in favour of Iterable in this case as it inhibits people calling
.size(). Knowing how many fields a Document has might be useful. But I agree
it would certainly prevent people from adding new Fields and is a simple
solution. Do you think getting the number of fields has a use case at all?

{quote}
If you do end up removing getFields(), then I'd like to have a clear() on
Document. I once proposed it and was told to call getFields().clear() instead,
which allows me to reuse my Document instance. If I lose that option, I'd
appreciate if a direct clear() on Document will exist instead.
{quote}

Yes. I will certainly add clear(). Do you think its useful to support
removing specific fields as well i.e. remove(String fieldName)?

Reduce Fieldable, AbstractField and Field complexity

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-14 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2310:


Haha, i whole heartedly agree with all your points.

One option instead of adding another method to return IterableFieldable, is 
for Document to implement IterableFieldable and to return a unmodifiable 
Iterator.

This would then fit nicely with future ideas I had about providing iterators 
based on FieldType criteria, allowing the IW to then retrieve an iterator of 
only those fields which are to be indexed for example.

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-14 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2310:


Haha, i whole heartedly agree with all your points.

One option instead of adding another method to return IterableFieldable, is 
for Document to implement IterableFieldable and to return a unmodifiable 
Iterator.

This would then fit nicely with future ideas I had about providing iterators 
based on FieldType criteria, allowing the IW to then retrieve an iterator of 
only those fields which are to be indexed for example.

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-14 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2310:
---

Comment: was deleted

(was: Haha, i whole heartedly agree with all your points.

One option instead of adding another method to return IterableFieldable, is 
for Document to implement IterableFieldable and to return a unmodifiable 
Iterator.

This would then fit nicely with future ideas I had about providing iterators 
based on FieldType criteria, allowing the IW to then retrieve an iterator of 
only those fields which are to be indexed for example.)

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-13 Thread Chris Male (JIRA)

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

Chris Male updated LUCENE-2310:
---

Attachment: LUCENE-2310-Deprecate-AbstractField.patch

Attaching first version of the patch which deprecates AbstractField.

- Moves the properties and getters/setters down into Field.
- Field now only implements Fieldable
- Field now allows its value to be set to null through its construction. This
allows subclasses to set the fieldData to their own
- NumericField now extends Field, overridding the setValue methods as they are
not supported
- LazyField also now extends Field
- AbstractField is now no longer used anywhere.

Reduce Fieldable, AbstractField and Field complexity

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-13 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2310:

{quote}
You should also not be able to set the TokenStream in NF.
{quote}

Yes good point.

{quote}
IMO, i would keep AbstractField and only remove Fieldable, as interfaces are
not wanted in Lucene
{quote}

Actually I would like to remove both actually. There doesn't seem much reason
to keep AbstractField, especially since its already dependent on Field.XYZ and
seems only to only store all the various properties, most of which will be
moved away to FieldType anyway.

Would a compromise be to also add an UOE to setting the TokenStream in
NumericField? It does still have the concept of a TokenStream, so it is a
Field, but a specialisation which handles the TokenStream itself.

Reduce Fieldable, AbstractField and Field complexity

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-13 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2310:


I should note, to prevent confusion, that my patch is just the beginning of 
this work, designed to illustrate the direction I'm heading.

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-13 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2310:


Hi Tim,

Yeah I see what you are saying, but as Earwin says, the 'settings' will be 
pushed into the FieldType, so they'll be removed from Fieldable as well.

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-13 Thread Chris Male (JIRA)

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

Chris Male updated LUCENE-2310:
---

Attachment: LUCENE-2310-Deprecate-AbstractField.patch

Addressed the issues raised by Uwe about the TokenStream in NumericField.
NumericField now throws a UOE on setTokenStream. Since it also extends Field
which has its own TokenStream field, NumericField now uses the field from
TokenStream rather than its own.

The more and more this is discussed the clearer it is that Field should be the
base class of the Field hierarchy, and not AbstractField or Fieldable. The
issue of having all the setters and configurations will be addressed in
LUENE-2308 when we move them all to FieldType. Field will become a simple
tuple consisting of at least a value and type, and possibly a TokenStream.

NumericField and LazyField are customisations of Field controlling certain
aspects of the tuple. For NumericField that is the TokenStream and setting the
value. For LazyField that is the value.

Reduce Fieldable, AbstractField and Field complexity

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Updated: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-13 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2310:
---

Attachment: LUCENE-2310-Deprecate-AbstractField.patch

Addressed Uwe's issue again.

Only solution is to change Field to extend AbstractField again, even though 
AbstractField is dead code.

Also fixed:

- Added final to setter methods that are also final in AbstractField for 
consistency sake
- Fixed import for javadocs in CheckIndex and FieldsReader

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male
 Attachments: LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch, 
 LUCENE-2310-Deprecate-AbstractField.patch


 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-12 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2310:


The challenge presented in this work is the pervasiveness of the Fieldable 
class.  Its used in several hundred places through the source, but the majority 
are in tests, and in Document itself.  Therefore part of this work will be also 
to move as many of the tests over to using Field, and working on the Document 
API as well.

 Reduce Fieldable, AbstractField and Field complexity
 

 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male

 In order to move field type like functionality into its own class, we really 
 need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
 Currently AbstractField depends on Field, and does not provide much more 
 functionality that storing fields, most of which are being moved over to 
 FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
 possible Fieldable), moving much of the functionality into Field and 
 FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2308) Separately specify a field's type

2010-03-12 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2308:

So you are thinking more along the lines indexNorms(true|false)?

Separately specify a field's type
-

Key: LUCENE-2308
URL: https://issues.apache.org/jira/browse/LUCENE-2308
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Michael McCandless

This came up from dicussions on IRC. I'm summarizing here...
Today when you make a Field to add to a document you can set things
index or not, stored or not, analyzed or not, details like omitTfAP,
omitNorms, index term vectors (separately controlling
offsets/positions), etc.
I think we should factor these out into a new class (FieldType?).
Then you could re-use this FieldType instance across multiple fields.
The Field instance would still hold the actual value.
We could then do per-field analyzers by adding a setAnalyzer on the
FieldType, instead of the separate PerFieldAnalzyerWrapper (likewise
for per-field codecs (with flex), where we now have
PerFieldCodecWrapper).
This would NOT be a schema! It's just refactoring what we already
specify today. EG it's not serialized into the index.
This has been discussed before, and I know Michael Busch opened a more
ambitious (I think?) issue. I think this is a good first baby step. We could
consider a hierarchy of FIeldType (NumericFieldType, etc.) but maybe hold
off on that for starters...

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2308) Separately specify a field's type

2010-03-12 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2308:

I agree entirely. This is definitely the moment to remove any ambiguity or
confusion in this API. I'll make sure to incorporate this idea.

Separately specify a field's type
-

Key: LUCENE-2308
URL: https://issues.apache.org/jira/browse/LUCENE-2308
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Michael McCandless

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2308) Separately specify a field's type

2010-03-12 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2308:

What I covered with Mike earlier was whether FieldType methods would be
immutable or not.

If they are, which seems a good idea, then everything will be enabled/disabled
in the construction of the FieldType so we would only need to support property
getter methods.

Separately specify a field's type
-

Key: LUCENE-2308
URL: https://issues.apache.org/jira/browse/LUCENE-2308
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Michael McCandless

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2308) Separately specify a field's type

2010-03-12 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2308:

{quote}
It would be nice if we could do something similar to IndexWriterConfig
(LUCENE-2294), where you use incremental ctor/setters to set up the
configuration but then once it's used (bound to a Field), it's
immutable.
{quote}

Yeah we could use something like a FieldTypeBuilder which could provide a fluid
interface for specifying each property, which then get built into an immutable
FieldType at the end.

Separately specify a field's type
-

Key: LUCENE-2308
URL: https://issues.apache.org/jira/browse/LUCENE-2308
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Michael McCandless

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2308) Separately specify a field's type

2010-03-12 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2308:

{quote}
I'm not sure if strict immutability is necessary - there's everything in
between too.
One can simply say that all changes should be made before first use, and after
that point it's undefined.
{quote}

I'm really unsure about this if people are going to be using a FieldType
instance with multiple Fields. Perhaps this really is just an edge case.

{quote}
Unrelated question: I assume that this would retain the same flexibility as we
have today... the ability to change FieldType for field foo from one document
to the next?
{quote}

Are you wanting to be able to reuse the same Field instance in both documents
while defining separate FieldTypes? Or is creating new Field instances okay?

Separately specify a field's type
-

Key: LUCENE-2308
URL: https://issues.apache.org/jira/browse/LUCENE-2308
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Michael McCandless

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Issue Comment Edited: (LUCENE-2308) Separately specify a field's type

2010-03-12 Thread Chris Male (JIRA)

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

Chris Male edited comment on LUCENE-2308 at 3/12/10 10:01 PM:
--

I'm really unsure about this if people are going to be using a FieldType
instance with multiple Fields. Perhaps this really is just an edge case though.

{quote}
Unrelated question: I assume that this would retain the same flexibility as we
have today... the ability to change FieldType for field foo from one document
to the next?
{quote}

Are you wanting to be able to reuse the same Field instance in both documents
while defining separate FieldTypes? Or is creating new Field instances okay?

was (Author: cmale):
{quote}
I'm not sure if strict immutability is necessary - there's everything in
between too.
One can simply say that all changes should be made before first use, and after
that point it's undefined.
{quote}

I'm really unsure about this if people are going to be using a FieldType
instance with multiple Fields. Perhaps this really is just an edge case.

{quote}
Unrelated question: I assume that this would retain the same flexibility as we
have today... the ability to change FieldType for field foo from one document
to the next?
{quote}

Are you wanting to be able to reuse the same Field instance in both documents
while defining separate FieldTypes? Or is creating new Field instances okay?

Separately specify a field's type
-

Key: LUCENE-2308
URL: https://issues.apache.org/jira/browse/LUCENE-2308
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Michael McCandless

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2308) Separately specify a field's type

2010-03-12 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2308:

{quote}
I will, if I can (provided the FieldType does not contain the field name). That
shouldn't have anything to do with immutability though.
{quote}

Yeah the field name will stay inside the Field. To me the reuse issue relates
immutability in that a change to a property in one FieldType after construction
means the change effects all the Fields that use that type.

But as you say, if we document that its best to set everything at instantiation
and that whatever happens after that is undefined, then I imagine it'll be fine.

{quote}
new Field instances should be fine - it's not really my use case anyway. But
we're designing for the 1000's of use cases that are out there and we should be
careful about adding new constraints.
{quote}

Yeah I appreciate that this API will be used in lots of different ways. Baby
steps as Mike said :) But to answer your question, yes the flexibility will
remain.

Separately specify a field's type
-

Key: LUCENE-2308
URL: https://issues.apache.org/jira/browse/LUCENE-2308
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Michael McCandless

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2308) Separately specify a field's type

2010-03-11 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2308:

Hi Mike,

+1 to this idea.

Do you envisage FieldType instances being immutable or would you be able to
change the Analyzer on a FieldType? If they are mutable, would you see
FieldType instances being shared across multiple Fields? Or would each Field
have its own FieldType instance?

Separately specify a field's type
-

Key: LUCENE-2308
URL: https://issues.apache.org/jira/browse/LUCENE-2308
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Michael McCandless

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2308) Separately specify a field's type

2010-03-11 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2308:

Yeah I agree with the immutability and shareability.

I'll give this a shot, with taking the babiest of baby steps.

Separately specify a field's type
-

Key: LUCENE-2308
URL: https://issues.apache.org/jira/browse/LUCENE-2308
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Michael McCandless

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Created: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity

2010-03-11 Thread Chris Male (JIRA)

Reduce Fieldable, AbstractField and Field complexity


 Key: LUCENE-2310
 URL: https://issues.apache.org/jira/browse/LUCENE-2310
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: Index
Reporter: Chris Male


In order to move field type like functionality into its own class, we really 
need to try to tackle the hierarchy of Fieldable, AbstractField and Field.  
Currently AbstractField depends on Field, and does not provide much more 
functionality that storing fields, most of which are being moved over to 
FieldType.  Therefore it seems ideal to try to deprecate AbstractField (and 
possible Fieldable), moving much of the functionality into Field and FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2152) Abstract Spatial distance filtering process and supported field formats

2010-01-20 Thread Chris Male (JIRA)

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

Chris Male updated LUCENE-2152:
---

Attachment: LUCENE-2152-alt.patch

Attaching a new patch based on the above discussion.

This patch introduces the interface DocumentDistanceSource, which provides a
single place to retrieve the distances for documents. It uses the new
PointDecoder interface (a simplified version of the LocationDataSet in the
previous patches) and the GeoDistanceCalculators to determine the distance for
a document.

It comes with 2 implementations, SimpleDocumentDistanceSource which does the
calculations always and does not cache, and MapCachingDocumentDistanceSource,
which does some simple map caching of distances.

By using a combination of these impls, its possible for the user to choose
whether they want the calculated distances to be stored or not. It also moves
the storage out from the Filter, returning the filter to a more stateless impl.

Abstract Spatial distance filtering process and supported field formats
---

Key: LUCENE-2152
URL: https://issues.apache.org/jira/browse/LUCENE-2152
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Attachments: LUCENE-2152-alt.patch, LUCENE-2152.patch,
LUCENE-2152.patch, LUCENE-2152.patch

Currently the second stage of the filtering process in the spatial contrib
involves calculating the exact distance for the remaining documents, and
filtering out those that fall out of the search radius. Currently this is
done through the 2 impls of DistanceFilter, LatLngDistanceFilter and
GeoHashDistanceFilter. The main difference between these 2 impls is the
format of data they support, the former supporting lat/lngs being stored in 2
distinct fields, while the latter supports geohashed lat/lngs through the
GeoHashUtils. This difference should be abstracted out so that the distance
filtering process is data format agnostic.
The second issue is that the distance filtering algorithm can be considerably
optimized by using multiple-threads. Therefore it makes sense to have an
abstraction of DistanceFilter which has different implementations, one being
a multi-threaded implementation and the other being a blank implementation
that can be used when no distance filtering is to occur.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2152) Abstract Spatial distance filtering process and supported field formats

2010-01-17 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2152:


I am currently working on a new patch that will incorporate the ideas discussed 
here and will attach it shortly.

 Abstract Spatial distance filtering process and supported field formats
 ---

 Key: LUCENE-2152
 URL: https://issues.apache.org/jira/browse/LUCENE-2152
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
 Attachments: LUCENE-2152.patch, LUCENE-2152.patch, LUCENE-2152.patch


 Currently the second stage of the filtering process in the spatial contrib 
 involves calculating the exact distance for the remaining documents, and 
 filtering out those that fall out of the search radius.  Currently this is 
 done through the 2 impls of DistanceFilter, LatLngDistanceFilter and 
 GeoHashDistanceFilter.  The main difference between these 2 impls is the 
 format of data they support, the former supporting lat/lngs being stored in 2 
 distinct fields, while the latter supports geohashed lat/lngs through the 
 GeoHashUtils.  This difference should be abstracted out so that the distance 
 filtering process is data format agnostic.
 The second issue is that the distance filtering algorithm can be considerably 
 optimized by using multiple-threads.  Therefore it makes sense to have an 
 abstraction of DistanceFilter which has different implementations, one being 
 a multi-threaded implementation and the other being a blank implementation 
 that can be used when no distance filtering is to occur.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2184) CartesianPolyFilterBuilder doesn't properly account for which tiers actually exist in the index

2010-01-02 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2184:


I agree.  I will build a patch to that effect unless there are any other 
alternatives.

 CartesianPolyFilterBuilder doesn't properly account for which tiers actually 
 exist in the index 
 

 Key: LUCENE-2184
 URL: https://issues.apache.org/jira/browse/LUCENE-2184
 Project: Lucene - Java
  Issue Type: Bug
  Components: contrib/spatial
Affects Versions: 2.9, 2.9.1, 3.0
Reporter: Grant Ingersoll

 In the CartesianShapeFilterBuilder, there is logic that determines the best 
 fit tier to create the Filter against.  However, it does not account for 
 which fields actually exist in the index when doing so.  For instance, if you 
 index tiers 1 through 10, but then choose a very small radius to restrict the 
 space to, it will likely choose a tier like 15 or 16, which of course does 
 not exist.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2147) Improve Spatial Utility like classes

2010-01-02 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2147:


Okay, I will remove them from the other patches as well and update them over 
the next few days.

 Improve Spatial Utility like classes
 

 Key: LUCENE-2147
 URL: https://issues.apache.org/jira/browse/LUCENE-2147
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Assignee: Simon Willnauer
 Attachments: LUCENE-2147.patch, LUCENE-2147.patch, LUCENE-2147.patch, 
 LUCENE-2147.patch, LUCENE-2147.patch


 - DistanceUnits can be improved by giving functionality to the enum, such as 
 being able to convert between different units, and adding tests.  
 - GeoHashUtils can be improved through some code tidying, documentation, and 
 tests.
 - SpatialConstants allows us to move all constants, such as the radii and 
 circumferences of Earth, to a single consistent location that we can then use 
 throughout the contrib.  This also allows us to improve the transparency of 
 calculations done in the contrib, as users of the contrib can easily see the 
 values being used.  Currently this issues does not migrate classes to use 
 these constants, that will happen in issues related to the appropriate 
 classes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2152) Abstract Spatial distance filtering process and supported field formats

2009-12-30 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2152:


I agree that we need to decouple the sort from the Filter.  My current patches 
don't do that well enough unfortunately so I want to address that.

I like what you are suggesting, but I think there are a couple of things to 
consider.  The storage of the distances is not just for sorting sake, as you 
say its also needed in the CustomScoreQuery for boosting, and also for 
presentation of the results.  Given that, I'm still sort of favouring 
separating the distance calculation function from the storage mechanism.

If we added a DistanceCollector abstraction, then we could create a Remote impl 
for the Collector, and we could create a distance function (which I refer to as 
GeoDistanceCalculator in one of my other patches) which uses an existing 
DistanceCollector as a cache.

We could also make a NoOpDistanceCollector for those who don't want to actually 
store anything, and a RangeDistanceCollector for collecting values in ranges 
(which could be a space saving optimization, and could also help with distance 
range faceting).

 Abstract Spatial distance filtering process and supported field formats
 ---

 Key: LUCENE-2152
 URL: https://issues.apache.org/jira/browse/LUCENE-2152
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
 Attachments: LUCENE-2152.patch, LUCENE-2152.patch, LUCENE-2152.patch


 Currently the second stage of the filtering process in the spatial contrib 
 involves calculating the exact distance for the remaining documents, and 
 filtering out those that fall out of the search radius.  Currently this is 
 done through the 2 impls of DistanceFilter, LatLngDistanceFilter and 
 GeoHashDistanceFilter.  The main difference between these 2 impls is the 
 format of data they support, the former supporting lat/lngs being stored in 2 
 distinct fields, while the latter supports geohashed lat/lngs through the 
 GeoHashUtils.  This difference should be abstracted out so that the distance 
 filtering process is data format agnostic.
 The second issue is that the distance filtering algorithm can be considerably 
 optimized by using multiple-threads.  Therefore it makes sense to have an 
 abstraction of DistanceFilter which has different implementations, one being 
 a multi-threaded implementation and the other being a blank implementation 
 that can be used when no distance filtering is to occur.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2152) Abstract Spatial distance filtering process and supported field formats

2009-12-30 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2152:

Ha, genius. I hadn't thought about the reuse between searches. That would
make a huge difference in a situation where a user is changing their zoom on a
map.

I'm with you now and agree whole heartedly with what you are suggesting. I
really love the idea of having a single consistent way of retrieving a distance
for a document, whether it be the Filter itself, the Sort, a Query, or some
output mechanism. That would really hide away alot of the logic.

Would you then also put the task of loading/decoding the appropriate lat/lng
info for Documents inside this distance function idea as well? (I think this
was what you were suggesting a couple of posts ago).

Abstract Spatial distance filtering process and supported field formats
---

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2184) CartesianPolyFilterBuilder doesn't properly account for which tiers actually exist in the index

2009-12-29 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2184:

I have also seen this bug come up. It seems that there are only 15 possible
tiers, as if the best fit tier is greater than 15, then it is scaled back to
15. So one plausible solution that doesn't require any changes to the API, is
to simply require all documents have all 15 levels indexed. The other solution
is to take into account the range of indexed levels when calculating the the
best fit tier, but this would require an API change, although it could be made
backwards compatible quite easily.

Any thoughts on the preferred approach?

CartesianPolyFilterBuilder doesn't properly account for which tiers actually
exist in the index

Key: LUCENE-2184
URL: https://issues.apache.org/jira/browse/LUCENE-2184
Project: Lucene - Java
Issue Type: Bug
Components: contrib/spatial
Affects Versions: 2.9, 2.9.1, 3.0
Reporter: Grant Ingersoll

In the CartesianShapeFilterBuilder, there is logic that determines the best
fit tier to create the Filter against. However, it does not account for
which fields actually exist in the index when doing so. For instance, if you
index tiers 1 through 10, but then choose a very small radius to restrict the
space to, it will likely choose a tier like 15 or 16, which of course does
not exist.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2152) Abstract Spatial distance filtering process and supported field formats

2009-12-29 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2152:

One part of this implementation that I'm still wrestling with is the storage of
the computed distances. Currently each docId computed-distance pair is stored
in a Map which itself is stored in the DistanceFilter. This can then be
retrieved through the SpatialFilter. This restricts the storage of the
distances, which could be alot of values, to that chosen by the DistanceFilter.
If someone preferred not to store the distances at all, for memory sake maybe,
then they have no control over this. I'm thinking that it might be useful to
have some sort of DistanceCollector abstraction through which users of the
Filter can have greater control over how the distances are stored, if they are
at all.

Any thoughts on this idea?

Abstract Spatial distance filtering process and supported field formats
---

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Updated: (LUCENE-2148) Improve Spatial Point2D and Rectangle Classes

2009-12-28 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2148:
---

Attachment: LUCENE-2148.patch

Attached new patch incorporating Simon's suggestions.

 Improve Spatial Point2D and Rectangle Classes
 -

 Key: LUCENE-2148
 URL: https://issues.apache.org/jira/browse/LUCENE-2148
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Assignee: Simon Willnauer
 Attachments: LUCENE-2148.patch, LUCENE-2148.patch, LUCENE-2148.patch, 
 LUCENE-2148.patch


 The Point2D and Rectangle classes have alot of duplicate, redundant and used 
 functionality.  This issue cleans them both up and simplifies the 
 functionality they provide.
 Subsequent to this, Eclipse and LineSegment, which depend on Point2D, are not 
 used anywhere in the contrib, therefore rather than trying to update them to 
 use the improved Point2D, they will be removed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2185) add @Deprecated annotations

2009-12-28 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2185:
---

Attachment: LUCENE-2185.patch

Attaching patch for Robert.

 add @Deprecated annotations
 ---

 Key: LUCENE-2185
 URL: https://issues.apache.org/jira/browse/LUCENE-2185
 Project: Lucene - Java
  Issue Type: Task
Reporter: Robert Muir
Priority: Trivial
 Fix For: 3.1

 Attachments: LUCENE-2185.patch


 as discussed on LUCENE-2084, I think we should be consistent about use of 
 @Deprecated annotations if we are to use it.
 This patch adds the missing annotations... unfortunately i cannot commit this 
 for some time, because my internet connection does not support heavy 
 committing (it is difficult to even upload a large patch).
 So if someone wants to take it, have fun, otherwise in a week or so I will 
 commit it if nobody objects.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2147) Improve Spatial Utility like classes

2009-12-21 Thread Chris Male (JIRA)

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

Chris Male updated LUCENE-2147:
---

Attachment: LUCENE-2147.patch

Improved javadoc on DistanceUnits.convert so its a little clearer.

Improve Spatial Utility like classes

Key: LUCENE-2147
URL: https://issues.apache.org/jira/browse/LUCENE-2147
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Assignee: Simon Willnauer
Attachments: LUCENE-2147.patch, LUCENE-2147.patch, LUCENE-2147.patch,
LUCENE-2147.patch

- DistanceUnits can be improved by giving functionality to the enum, such as
being able to convert between different units, and adding tests.
- GeoHashUtils can be improved through some code tidying, documentation, and
tests.
- SpatialConstants allows us to move all constants, such as the radii and
circumferences of Earth, to a single consistent location that we can then use
throughout the contrib. This also allows us to improve the transparency of
calculations done in the contrib, as users of the contrib can easily see the
values being used. Currently this issues does not migrate classes to use
these constants, that will happen in issues related to the appropriate
classes.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Created: (LUCENE-2173) Simplify and tidy Cartesian Tier Code in Spatial

2009-12-20 Thread Chris Male (JIRA)

Simplify and tidy Cartesian Tier Code in Spatial


 Key: LUCENE-2173
 URL: https://issues.apache.org/jira/browse/LUCENE-2173
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male


The Cartesian Tier filtering code in the spatial code can be simplified, tidied 
and generally improved.  Improvements include removing default field name 
support which isn't the responsibility of the code, adding javadoc, making 
method names more intuitive and trying to make the complex code in 
CartesianPolyFilterBuilder more understandable.

Few deprecations have to occur as part of this work, but some public methods in 
CartesianPolyFilterBuilder will be made private where possible so future 
improvements of this class can occur.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2173) Simplify and tidy Cartesian Tier Code in Spatial

2009-12-20 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2173:
---

Attachment: LUCENE-2173.patch

Attaching first attempt at this work.

 Simplify and tidy Cartesian Tier Code in Spatial
 

 Key: LUCENE-2173
 URL: https://issues.apache.org/jira/browse/LUCENE-2173
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
 Attachments: LUCENE-2173.patch


 The Cartesian Tier filtering code in the spatial code can be simplified, 
 tidied and generally improved.  Improvements include removing default field 
 name support which isn't the responsibility of the code, adding javadoc, 
 making method names more intuitive and trying to make the complex code in 
 CartesianPolyFilterBuilder more understandable.
 Few deprecations have to occur as part of this work, but some public methods 
 in CartesianPolyFilterBuilder will be made private where possible so future 
 improvements of this class can occur.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2173) Simplify and tidy Cartesian Tier Code in Spatial

2009-12-20 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2173:
---

Attachment: LUCENE-2173.patch

Attached new patch which deprecates getBoundingArea in 
CartesianPolyFilterBuilder and replaces it with a more intuitive buildFilter.

 Simplify and tidy Cartesian Tier Code in Spatial
 

 Key: LUCENE-2173
 URL: https://issues.apache.org/jira/browse/LUCENE-2173
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
 Attachments: LUCENE-2173.patch, LUCENE-2173.patch


 The Cartesian Tier filtering code in the spatial code can be simplified, 
 tidied and generally improved.  Improvements include removing default field 
 name support which isn't the responsibility of the code, adding javadoc, 
 making method names more intuitive and trying to make the complex code in 
 CartesianPolyFilterBuilder more understandable.
 Few deprecations have to occur as part of this work, but some public methods 
 in CartesianPolyFilterBuilder will be made private where possible so future 
 improvements of this class can occur.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2173) Simplify and tidy Cartesian Tier Code in Spatial

2009-12-20 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2173:
---

Attachment: LUCENE-2173.patch

Updated patch to remove PolyCheck class which didn't seem to have a purpose and 
was broken by the changes to visibility in CartesianPolyFilterBuilder

 Simplify and tidy Cartesian Tier Code in Spatial
 

 Key: LUCENE-2173
 URL: https://issues.apache.org/jira/browse/LUCENE-2173
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
 Attachments: LUCENE-2173.patch, LUCENE-2173.patch, LUCENE-2173.patch


 The Cartesian Tier filtering code in the spatial code can be simplified, 
 tidied and generally improved.  Improvements include removing default field 
 name support which isn't the responsibility of the code, adding javadoc, 
 making method names more intuitive and trying to make the complex code in 
 CartesianPolyFilterBuilder more understandable.
 Few deprecations have to occur as part of this work, but some public methods 
 in CartesianPolyFilterBuilder will be made private where possible so future 
 improvements of this class can occur.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (LUCENE-2174) Add new SpatialFilter and DistanceFieldComparatorSource to Spatial

2009-12-20 Thread Chris Male (JIRA)

Add new SpatialFilter and DistanceFieldComparatorSource to Spatial
--

 Key: LUCENE-2174
 URL: https://issues.apache.org/jira/browse/LUCENE-2174
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male


The current DistanceQueryBuilder and DistanceFieldComparatorSource in Spatial 
are based on the old filtering process, most of which has been deprecated in 
previous issues.  These will be replaced by a new SpatialFilter class, which is 
a proper Lucene filter, and a new DistanceFieldComparatorSource which will be 
relocated and will use the new DistanceFilter interface.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2174) Add new SpatialFilter and DistanceFieldComparatorSource to Spatial

2009-12-20 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2174:
---

Attachment: LUCENE-2174.patch

Attaching patch that adds the SpatialFilter and DistanceFieldComparatorSource, 
which appropriate tests, and deprecations for old behavior.

 Add new SpatialFilter and DistanceFieldComparatorSource to Spatial
 --

 Key: LUCENE-2174
 URL: https://issues.apache.org/jira/browse/LUCENE-2174
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
 Attachments: LUCENE-2174.patch


 The current DistanceQueryBuilder and DistanceFieldComparatorSource in Spatial 
 are based on the old filtering process, most of which has been deprecated in 
 previous issues.  These will be replaced by a new SpatialFilter class, which 
 is a proper Lucene filter, and a new DistanceFieldComparatorSource which will 
 be relocated and will use the new DistanceFilter interface.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (LUCENE-2175) Deprecate remaining unused classes in Spatial

2009-12-20 Thread Chris Male (JIRA)

Deprecate remaining unused classes in Spatial
-

 Key: LUCENE-2175
 URL: https://issues.apache.org/jira/browse/LUCENE-2175
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
 Attachments: LUCENE-2175.patch

The major changes to spatial have rendered a few other classes in the module 
unnecessary.  This issue deprecates these classes so they can be removed later 
on.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2175) Deprecate remaining unused classes in Spatial

2009-12-20 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2175:
---

Attachment: LUCENE-2175.patch

Attaching patch which deprecates remaining redundant classes.

 Deprecate remaining unused classes in Spatial
 -

 Key: LUCENE-2175
 URL: https://issues.apache.org/jira/browse/LUCENE-2175
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
 Attachments: LUCENE-2175.patch


 The major changes to spatial have rendered a few other classes in the module 
 unnecessary.  This issue deprecates these classes so they can be removed 
 later on.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2147) Improve Spatial Utility like classes

2009-12-18 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2147:
---

Attachment: LUCENE-2147.patch

- Fixed bug in the patch which assigned earthCircumference to earthRadius in 
the DistanceUnits constructor.
- Added javadoc to DistanceUnits constructor for new parameters
- Tidied some of the other javadoc

 Improve Spatial Utility like classes
 

 Key: LUCENE-2147
 URL: https://issues.apache.org/jira/browse/LUCENE-2147
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Assignee: Simon Willnauer
 Attachments: LUCENE-2147.patch, LUCENE-2147.patch, LUCENE-2147.patch


 - DistanceUnits can be improved by giving functionality to the enum, such as 
 being able to convert between different units, and adding tests.  
 - GeoHashUtils can be improved through some code tidying, documentation, and 
 tests.
 - SpatialConstants allows us to move all constants, such as the radii and 
 circumferences of Earth, to a single consistent location that we can then use 
 throughout the contrib.  This also allows us to improve the transparency of 
 calculations done in the contrib, as users of the contrib can easily see the 
 values being used.  Currently this issues does not migrate classes to use 
 these constants, that will happen in issues related to the appropriate 
 classes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2148) Improve Spatial Point2D and Rectangle Classes

2009-12-18 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2148:
---

Attachment: LUCENE-2148.patch

Patch differs considerably from previous one in that it makes no deletes or 
renames to the existing code.  Instead it contains the following changes:

- Deprecates all classes in geometry.shape
- Adds simpler immutable Point class to geometry package.  This will be used 
instead of Point2D in remaining work
- Adds simpler LatLngRectangle class to geometry package.  This will be used 
instead of LLRect in remaining work
- Deprecates geometry.CartesianPoint
- Changes LatLng to a concrete class (instead of abstract), deprecates most of 
its methods and cleans up the ones that should remain
- Deprecates FloatLatLng and FixedLatLng since they are replaced by the logic 
in LatLng.

 Improve Spatial Point2D and Rectangle Classes
 -

 Key: LUCENE-2148
 URL: https://issues.apache.org/jira/browse/LUCENE-2148
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Assignee: Simon Willnauer
 Attachments: LUCENE-2148.patch, LUCENE-2148.patch


 The Point2D and Rectangle classes have alot of duplicate, redundant and used 
 functionality.  This issue cleans them both up and simplifies the 
 functionality they provide.
 Subsequent to this, Eclipse and LineSegment, which depend on Point2D, are not 
 used anywhere in the contrib, therefore rather than trying to update them to 
 use the improved Point2D, they will be removed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2151) Abstract the distance calculation process in the Spatial contrib

2009-12-18 Thread Chris Male (JIRA)

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

Chris Male updated LUCENE-2151:
---

Attachment: LUCENE-2151.patch

Updated patch so that it uses the DistanceUnits.convert instance method.

Abstract the distance calculation process in the Spatial contrib

Key: LUCENE-2151
URL: https://issues.apache.org/jira/browse/LUCENE-2151
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Assignee: Simon Willnauer
Attachments: LUCENE-2151.patch, LUCENE-2151.patch

The spatial contrib shouldn't tie users to one particular way of calculating
distances. Wikipedia lists multiple different formulas for the great-circle
distance calculation, and there are alternatives to that as well. In a
situation where many documents have the same points, it would be useful to be
able to cache some calculated values as well (currently this is sort of
handled in the filtering process itself).
This issue addresses this by abstracting away the distance calculator,
allowing the user to provide the implementation of choice. It would then be
possible to swap in different distance calculation strategies without
altering the distance filtering process itself.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Updated: (LUCENE-2152) Abstract Spatial distance filtering process and supported field formats

2009-12-18 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2152:
---

Attachment: LUCENE-2152.patch

Updated patch so that it uses Point rather than Point2D.

 Abstract Spatial distance filtering process and supported field formats
 ---

 Key: LUCENE-2152
 URL: https://issues.apache.org/jira/browse/LUCENE-2152
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
 Attachments: LUCENE-2152.patch, LUCENE-2152.patch


 Currently the second stage of the filtering process in the spatial contrib 
 involves calculating the exact distance for the remaining documents, and 
 filtering out those that fall out of the search radius.  Currently this is 
 done through the 2 impls of DistanceFilter, LatLngDistanceFilter and 
 GeoHashDistanceFilter.  The main difference between these 2 impls is the 
 format of data they support, the former supporting lat/lngs being stored in 2 
 distinct fields, while the latter supports geohashed lat/lngs through the 
 GeoHashUtils.  This difference should be abstracted out so that the distance 
 filtering process is data format agnostic.
 The second issue is that the distance filtering algorithm can be considerably 
 optimized by using multiple-threads.  Therefore it makes sense to have an 
 abstraction of DistanceFilter which has different implementations, one being 
 a multi-threaded implementation and the other being a blank implementation 
 that can be used when no distance filtering is to occur.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2149) Simplify Spatial LatLng and LLRect classes

2009-12-18 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2149:


This functionality has been incorporated into LUCENE-2148 because of 
dependencies between classes

 Simplify Spatial LatLng and LLRect classes
 --

 Key: LUCENE-2149
 URL: https://issues.apache.org/jira/browse/LUCENE-2149
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Assignee: Simon Willnauer
 Attachments: LUCENE-2149.patch


 Currently in the contrib there is FloatLatLng, and FixedLatLng, which both 
 extend LatLng.  The reason for this separation is not clear and is not needed 
 in the current functionality.  The functionality that is used can be 
 collapsed into LatLng, which can be made a concrete class.  Internally LatLng 
 can benefit from the improvements suggested in LUCENE-1934.
 LLRect, which uses LatLng, can also be simplified by removing the unused 
 functionality, and using the new LatLng class.
 All classes can be improved through documentation, some method renaming, and 
 general code tidy up.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2148) Improve Spatial Point2D and Rectangle Classes

2009-12-18 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2148:
---

Attachment: LUCENE-2148.patch

Added full deprecation annotations

 Improve Spatial Point2D and Rectangle Classes
 -

 Key: LUCENE-2148
 URL: https://issues.apache.org/jira/browse/LUCENE-2148
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Assignee: Simon Willnauer
 Attachments: LUCENE-2148.patch, LUCENE-2148.patch, LUCENE-2148.patch


 The Point2D and Rectangle classes have alot of duplicate, redundant and used 
 functionality.  This issue cleans them both up and simplifies the 
 functionality they provide.
 Subsequent to this, Eclipse and LineSegment, which depend on Point2D, are not 
 used anywhere in the contrib, therefore rather than trying to update them to 
 use the improved Point2D, they will be removed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2152) Abstract Spatial distance filtering process and supported field formats

2009-12-18 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2152:
---

Attachment: LUCENE-2152.patch

Added full deprecation annotations

 Abstract Spatial distance filtering process and supported field formats
 ---

 Key: LUCENE-2152
 URL: https://issues.apache.org/jira/browse/LUCENE-2152
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
 Attachments: LUCENE-2152.patch, LUCENE-2152.patch, LUCENE-2152.patch


 Currently the second stage of the filtering process in the spatial contrib 
 involves calculating the exact distance for the remaining documents, and 
 filtering out those that fall out of the search radius.  Currently this is 
 done through the 2 impls of DistanceFilter, LatLngDistanceFilter and 
 GeoHashDistanceFilter.  The main difference between these 2 impls is the 
 format of data they support, the former supporting lat/lngs being stored in 2 
 distinct fields, while the latter supports geohashed lat/lngs through the 
 GeoHashUtils.  This difference should be abstracted out so that the distance 
 filtering process is data format agnostic.
 The second issue is that the distance filtering algorithm can be considerably 
 optimized by using multiple-threads.  Therefore it makes sense to have an 
 abstraction of DistanceFilter which has different implementations, one being 
 a multi-threaded implementation and the other being a blank implementation 
 that can be used when no distance filtering is to occur.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2139) Cleanup and Improvement of Spatial Contrib

2009-12-11 Thread Chris Male (JIRA)

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

Chris Male updated LUCENE-2139:
---

Attachment: LUCENE-2139-svnScript.sh

Attaching simple bash script which executes a series of SVN commands to clean
out the existing module and rename most of the files to what they will be in
the next patch. The only file that still needs to be renamed later in
TestCartesian.java that will be renamed to TestSpatialFilter.java once
SpatialFilter exists.

Script assumes you are existing it from the root directory of lucene checkout.

Cleanup and Improvement of Spatial Contrib
--

Key: LUCENE-2139
URL: https://issues.apache.org/jira/browse/LUCENE-2139
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Assignee: Simon Willnauer
Attachments: LUCENE-2139-Java5Only.patch, LUCENE-2139-svnScript.sh,
LUCENE-2139.patch

The current spatial contrib can be improved by adding documentation, tests,
removing unused classes and code, repackaging the classes and improving the
performance of the distance filtering. The latter will incorporate the
multi-threaded functionality introduced in LUCENE-1732.
Other improvements involve adding better support for different distance
units, different distance calculators and different data formats (whether it
be lat/long fields, geohashes, or something else in the future).
Patch to be added soon.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Created: (LUCENE-2147) Improve Spatial Utility like classes

2009-12-11 Thread Chris Male (JIRA)

Improve Spatial Utility like classes


 Key: LUCENE-2147
 URL: https://issues.apache.org/jira/browse/LUCENE-2147
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male


- DistanceUnits can be improved by giving functionality to the enum, such as 
being able to convert between different units, and adding tests.  

- GeoHashUtils can be improved through some code tidying, documentation, and 
tests.

- SpatialConstants allows us to move all constants, such as the radii and 
circumferences of Earth, to a single consistent location that we can then use 
throughout the contrib.  This also allows us to improve the transparency of 
calculations done in the contrib, as users of the contrib can easily see the 
values being used.  Currently this issues does not migrate classes to use these 
constants, that will happen in issues related to the appropriate classes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2147) Improve Spatial Utility like classes

2009-12-11 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2147:
---

Attachment: LUCENE-2147.patch

Added patch that implementations described behavior.

 Improve Spatial Utility like classes
 

 Key: LUCENE-2147
 URL: https://issues.apache.org/jira/browse/LUCENE-2147
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
 Attachments: LUCENE-2147.patch


 - DistanceUnits can be improved by giving functionality to the enum, such as 
 being able to convert between different units, and adding tests.  
 - GeoHashUtils can be improved through some code tidying, documentation, and 
 tests.
 - SpatialConstants allows us to move all constants, such as the radii and 
 circumferences of Earth, to a single consistent location that we can then use 
 throughout the contrib.  This also allows us to improve the transparency of 
 calculations done in the contrib, as users of the contrib can easily see the 
 values being used.  Currently this issues does not migrate classes to use 
 these constants, that will happen in issues related to the appropriate 
 classes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (LUCENE-2148) Improve Spatial Point2D and Rectangle Classes

2009-12-11 Thread Chris Male (JIRA)

Improve Spatial Point2D and Rectangle Classes
-

 Key: LUCENE-2148
 URL: https://issues.apache.org/jira/browse/LUCENE-2148
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male


The Point2D and Rectangle classes have alot of duplicate, redundant and used 
functionality.  This issue cleans them both up and simplifies the functionality 
they provide.

Subsequent to this, Eclipse and LineSegment, which depend on Point2D, are not 
used anywhere in the contrib, therefore rather than trying to update them to 
use the improved Point2D, they will be removed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2148) Improve Spatial Point2D and Rectangle Classes

2009-12-11 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2148:
---

Attachment: LUCENE-2148.patch

Added patch

 Improve Spatial Point2D and Rectangle Classes
 -

 Key: LUCENE-2148
 URL: https://issues.apache.org/jira/browse/LUCENE-2148
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
 Attachments: LUCENE-2148.patch


 The Point2D and Rectangle classes have alot of duplicate, redundant and used 
 functionality.  This issue cleans them both up and simplifies the 
 functionality they provide.
 Subsequent to this, Eclipse and LineSegment, which depend on Point2D, are not 
 used anywhere in the contrib, therefore rather than trying to update them to 
 use the improved Point2D, they will be removed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (LUCENE-2149) Simplify Spatial LatLng and LLRect classes

2009-12-11 Thread Chris Male (JIRA)

Simplify Spatial LatLng and LLRect classes
--

 Key: LUCENE-2149
 URL: https://issues.apache.org/jira/browse/LUCENE-2149
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male


Currently in the contrib there is FloatLatLng, and FixedLatLng, which both 
extend LatLng.  The reason for this separation is not clear and is not needed 
in the current functionality.  The functionality that is used can be collapsed 
into LatLng, which can be made a concrete class.  Internally LatLng can benefit 
from the improvements suggested in LUCENE-1934.

LLRect, which uses LatLng, can also be simplified by removing the unused 
functionality, and using the new LatLng class.

All classes can be improved through documentation, some method renaming, and 
general code tidy up.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2149) Simplify Spatial LatLng and LLRect classes

2009-12-11 Thread Chris Male (JIRA)

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

Chris Male updated LUCENE-2149:
---

Attachment: LUCENE-2149.patch

Added in patch that provides functionality.

In the patch FloatLatLng and FixedLatLng are removed. Some unrelated classes
are updated to use the new APIs. They will be improved in their own issues.

Simplify Spatial LatLng and LLRect classes
--

Key: LUCENE-2149
URL: https://issues.apache.org/jira/browse/LUCENE-2149
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Attachments: LUCENE-2149.patch

Currently in the contrib there is FloatLatLng, and FixedLatLng, which both
extend LatLng. The reason for this separation is not clear and is not needed
in the current functionality. The functionality that is used can be
collapsed into LatLng, which can be made a concrete class. Internally LatLng
can benefit from the improvements suggested in LUCENE-1934.
LLRect, which uses LatLng, can also be simplified by removing the unused
functionality, and using the new LatLng class.
All classes can be improved through documentation, some method renaming, and
general code tidy up.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2147) Improve Spatial Utility like classes

2009-12-11 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2147:

Hi,

Yeah you are right about DistanceUnits using the SpatialConstants. I would
like to leave SpatialConstants in as it gives us a single place to manage these
values, particularly if the values are dependent on eachother (for example the
circumference should really depend on the radius). However adding to
DistanceUnits getEarthRadius() and getEarthCircumference() would make alot of
sense in the current environment. These could then simply pull their values
from the SpatialConstants.

I am fine with removing SpatialConstants if you feel this is overkill.

Improve Spatial Utility like classes

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Created: (LUCENE-2151) Abstract the distance calculation process in the Spatial contrib

2009-12-11 Thread Chris Male (JIRA)

Abstract the distance calculation process in the Spatial contrib


 Key: LUCENE-2151
 URL: https://issues.apache.org/jira/browse/LUCENE-2151
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male


The spatial contrib shouldn't tie users to one particular way of calculating 
distances.  Wikipedia lists multiple different formulas for the great-circle 
distance calculation, and there are alternatives to that as well.  In a 
situation where many documents have the same points, it would be useful to be 
able to cache some calculated values as well (currently this is sort of handled 
in the filtering process itself).  

This issue addresses this by abstracting away the distance calculator, allowing 
the user to provide the implementation of choice.  It would then be possible to 
swap in different distance calculation strategies without altering the distance 
filtering process itself.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2151) Abstract the distance calculation process in the Spatial contrib

2009-12-11 Thread Chris Male (JIRA)

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

Chris Male updated LUCENE-2151:
---

Attachment: LUCENE-2151.patch

Attached patch that adds in the GeoDistanceCalculator interface, with 2 impls:

- ArcGeoDistanceCalculator (note it was known as ArcDistanceCalculator in
previous patches, this addresses this inconsistency) - This calculator emulates
the existing distance calculation algorithm.
- PlaneGeoDistanceCalculator - This calculator assumes the the earth is flat,
and does simple trigonometry. This obviously includes an error, but it maybe
an error that is acceptable to some.

Tests for both impls are included

Abstract the distance calculation process in the Spatial contrib

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Updated: (LUCENE-2152) Abstract Spatial distance filtering process and supported field formats

2009-12-11 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-2152:
---

Attachment: LUCENE-2152.patch

Added patch that implements above behavior.  Adds DistanceFilter interface with 
implementations for multi-threading and no-op, and LocationDataSet/Factory 
which is responsible for processing the different formats of data and 
converting it into a Point2D.

 Abstract Spatial distance filtering process and supported field formats
 ---

 Key: LUCENE-2152
 URL: https://issues.apache.org/jira/browse/LUCENE-2152
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
 Attachments: LUCENE-2152.patch


 Currently the second stage of the filtering process in the spatial contrib 
 involves calculating the exact distance for the remaining documents, and 
 filtering out those that fall out of the search radius.  Currently this is 
 done through the 2 impls of DistanceFilter, LatLngDistanceFilter and 
 GeoHashDistanceFilter.  The main difference between these 2 impls is the 
 format of data they support, the former supporting lat/lngs being stored in 2 
 distinct fields, while the latter supports geohashed lat/lngs through the 
 GeoHashUtils.  This difference should be abstracted out so that the distance 
 filtering process is data format agnostic.
 The second issue is that the distance filtering algorithm can be considerably 
 optimized by using multiple-threads.  Therefore it makes sense to have an 
 abstraction of DistanceFilter which has different implementations, one being 
 a multi-threaded implementation and the other being a blank implementation 
 that can be used when no distance filtering is to occur.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-2148) Improve Spatial Point2D and Rectangle Classes

2009-12-11 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2148:


Hi Simon,

Yes I think thats a great idea.  Although it does set me back on the issues I 
have just created, but thats okay I can remake those patches.

 Improve Spatial Point2D and Rectangle Classes
 -

 Key: LUCENE-2148
 URL: https://issues.apache.org/jira/browse/LUCENE-2148
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Assignee: Simon Willnauer
 Attachments: LUCENE-2148.patch


 The Point2D and Rectangle classes have alot of duplicate, redundant and used 
 functionality.  This issue cleans them both up and simplifies the 
 functionality they provide.
 Subsequent to this, Eclipse and LineSegment, which depend on Point2D, are not 
 used anywhere in the contrib, therefore rather than trying to update them to 
 use the improved Point2D, they will be removed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2139) Cleanup and Improvement of Spatial Contrib

2009-12-10 Thread Chris Male (JIRA)

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

Chris Male updated LUCENE-2139:
---

Attachment: LUCENE-2139-Java5Only.patch

Attached updated version of the patch which is now compiled and tested with
Java 5. Difference is replacing the LinkedBlockingDeque with a
LinkedBlockingQueue, and fixing some weirdness with a single threaded
ThreadPoolExecutor.

Will tackle the structural problems now.

Cleanup and Improvement of Spatial Contrib
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2139) Cleanup and Improvement of Spatial Contrib

2009-12-10 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-2139:

Hi Simon,

Alright that sounds great. I will work on creating a list of SVN move / copies
commands followed by a patch to get the existing contrib into the structure
that I want. I will then break this big patch down into a handful of smaller
patches.

Cleanup and Improvement of Spatial Contrib
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Created: (LUCENE-2139) Cleanup and Improvement of Spatial Contrib

2009-12-09 Thread Chris Male (JIRA)

Cleanup and Improvement of Spatial Contrib
--

 Key: LUCENE-2139
 URL: https://issues.apache.org/jira/browse/LUCENE-2139
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male


The current spatial contrib can be improved by adding documentation, tests, 
removing unused classes and code, repackaging the classes and improving the 
performance of the distance filtering.  The latter will incorporate the 
multi-threaded functionality introduced in LUCENE-1732.  

Other improvements involve adding better support for different distance units, 
different distance calculators and different data formats (whether it be 
lat/long fields, geohashes, or something else in the future).

Patch to be added soon.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-2139) Cleanup and Improvement of Spatial Contrib

2009-12-09 Thread Chris Male (JIRA)

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

Chris Male updated LUCENE-2139:
---

Attachment: LUCENE-2139.patch

Added patch.

Couple of TODOs still noted in the patch related to distances. We need to
decide what distances we are going to use for the radius and circumference of
the Earth and then use them in SpatialConstants. Currently the
SpatialConstants values are taken from Wikipedia and other sites, yet differ
from some of the distances in the coded.

Also the patch doesn't seem to remove a couple of empty packages. Too many
changes in 1 patch confusing the IDE I think. Help cleaning this up would be
appreciated.

Cleanup and Improvement of Spatial Contrib
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Commented: (LUCENE-2139) Cleanup and Improvement of Spatial Contrib

2009-12-09 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-2139:


I have also included LUCENE-1934 in this, and tried to include LUCENE-1930 but 
was unable to get 1930 to work.

 Cleanup and Improvement of Spatial Contrib
 --

 Key: LUCENE-2139
 URL: https://issues.apache.org/jira/browse/LUCENE-2139
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Assignee: Simon Willnauer
 Attachments: LUCENE-2139.patch


 The current spatial contrib can be improved by adding documentation, tests, 
 removing unused classes and code, repackaging the classes and improving the 
 performance of the distance filtering.  The latter will incorporate the 
 multi-threaded functionality introduced in LUCENE-1732.  
 Other improvements involve adding better support for different distance 
 units, different distance calculators and different data formats (whether it 
 be lat/long fields, geohashes, or something else in the future).
 Patch to be added soon.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-1930) Scale moderator not in line with sinusoidal projector

2009-11-26 Thread Chris Male (JIRA)


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

Chris Male commented on LUCENE-1930:


Hi Nicolas,

I have every intention to commit my work to Lucene in the next week or so.  If 
you can wait till then, I will include this patch in my patch.

Thanks

 Scale moderator not in line with sinusoidal projector
 -

 Key: LUCENE-1930
 URL: https://issues.apache.org/jira/browse/LUCENE-1930
 Project: Lucene - Java
  Issue Type: Bug
  Components: contrib/spatial
Affects Versions: 2.9
Reporter: Nicolas Helleringer
 Attachments: LUCENE-1930.patch


 Current implementation in spatial Lucene does :
 public double getTierBoxId (double latitude, double longitude) {
   double[] coords = projector.coords(latitude, longitude);
   double id = getBoxId(coords[0]) + (getBoxId(coords[1]) / 
 tierVerticalPosDivider);
   return id ;
 }
 private double getBoxId (double coord){
   return Math.floor(coord / (idd / this.tierLength));
 }
 with
 Double idd = new Double(180);
 in the CartesianTierPlotter constructor.
 But current Sinusoidal Projector set and used in initialisation of 
 CartesianTierPlotter does :
 public double[] coords(double latitude, double longitude) {
   double rlat = Math.toRadians(latitude);
   double rlong = Math.toRadians(longitude);
   double nlat = rlong * Math.cos(rlat);
   double r[] = {nlat, rlong};
 return r;
 }
 Thus we moderate with idd = 180 a coord that is in a Radian space.
 Things to do :
 1°) fix idd to : double idd= PI;
 2°) Move idd definition to IProjector interface : The coord space should 
 belong to the projector doing the job. Change the code from CTP to use that 
 new interface.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (LUCENE-1732) Multi-threaded Spatial Search

2009-07-03 Thread Chris Male (JIRA)

Multi-threaded Spatial Search
-

 Key: LUCENE-1732
 URL: https://issues.apache.org/jira/browse/LUCENE-1732
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 2.9
Reporter: Chris Male


The attached patch is a large refactoring of the spatial search contrib.  The 
primary contribution is the creation of the ThreadedDistanceFilter, which uses 
an ExecutorService to filter the documents in multiple threads.  As a result of 
doing the filtering in multiple threads, the time taken to filter 1.2 million 
documents has been reduced from nearly 3s, to between 500-800ms.

As part of this work, the DistanceQueryBuilder has been replaced by the 
SpatialFilter, a Lucene Filter, some unused functionality has been removed, and 
the package hierarchy has changed.  Consequently this patch breaks backwards 
compatibility with the existing spatial search contrib.

Also during the process of making these changes, abstractions have been added 
so that the one implementation of the ThreadedDistanceFilter can work with 
lat/long and geohash data formats, and so that precise but costly arc distance 
calculations can be replaced by less precise but much more efficient flat plane 
calculations if needed.

This patch will be used in an upcoming patch for Solr which will improve Solr's 
support for spatial search.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-1732) Multi-threaded Spatial Search

2009-07-03 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-1732:
---

Attachment: LUCENE-1732_multi_threaded_spatial_search.patch

 Multi-threaded Spatial Search
 -

 Key: LUCENE-1732
 URL: https://issues.apache.org/jira/browse/LUCENE-1732
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/spatial
Affects Versions: 2.9
Reporter: Chris Male
 Attachments: LUCENE-1732_multi_threaded_spatial_search.patch


 The attached patch is a large refactoring of the spatial search contrib.  The 
 primary contribution is the creation of the ThreadedDistanceFilter, which 
 uses an ExecutorService to filter the documents in multiple threads.  As a 
 result of doing the filtering in multiple threads, the time taken to filter 
 1.2 million documents has been reduced from nearly 3s, to between 500-800ms.
 As part of this work, the DistanceQueryBuilder has been replaced by the 
 SpatialFilter, a Lucene Filter, some unused functionality has been removed, 
 and the package hierarchy has changed.  Consequently this patch breaks 
 backwards compatibility with the existing spatial search contrib.
 Also during the process of making these changes, abstractions have been added 
 so that the one implementation of the ThreadedDistanceFilter can work with 
 lat/long and geohash data formats, and so that precise but costly arc 
 distance calculations can be replaced by less precise but much more efficient 
 flat plane calculations if needed.
 This patch will be used in an upcoming patch for Solr which will improve 
 Solr's support for spatial search.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-1732) Multi-threaded Spatial Search

2009-07-03 Thread Chris Male (JIRA)

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

Chris Male commented on LUCENE-1732:

Unfortunately Solr is not using a version of Lucene which has the NumericUtils
class at this point and I would like for this patch to be usable with Solr.
When Solr does update to a version of Lucene which does include NumericUtils, I
will update my patch to use the class.

Multi-threaded Spatial Search
-

Key: LUCENE-1732
URL: https://issues.apache.org/jira/browse/LUCENE-1732
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/spatial
Affects Versions: 2.9
Reporter: Chris Male
Attachments: LUCENE-1732_multi_threaded_spatial_search.patch

The attached patch is a large refactoring of the spatial search contrib. The
primary contribution is the creation of the ThreadedDistanceFilter, which
uses an ExecutorService to filter the documents in multiple threads. As a
result of doing the filtering in multiple threads, the time taken to filter
1.2 million documents has been reduced from nearly 3s, to between 500-800ms.
As part of this work, the DistanceQueryBuilder has been replaced by the
SpatialFilter, a Lucene Filter, some unused functionality has been removed,
and the package hierarchy has changed. Consequently this patch breaks
backwards compatibility with the existing spatial search contrib.
Also during the process of making these changes, abstractions have been added
so that the one implementation of the ThreadedDistanceFilter can work with
lat/long and geohash data formats, and so that precise but costly arc
distance calculations can be replaced by less precise but much more efficient
flat plane calculations if needed.
This patch will be used in an upcoming patch for Solr which will improve
Solr's support for spatial search.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

93 matches

Mail list logo