Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 1 Feb 2011 20:13:28 +0000 (UTC)
From: "Julian Atkinson (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <18430269.3537.1296591208982.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Commented: (LUCENE-2475) Incorrect Bounding Box calculation
 results in the exclusion of valid data locations
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989366#comment-12989366 ] 

Julian Atkinson commented on LUCENE-2475:
-----------------------------------------

Thanks Nicolas.  It took me a while but I finally got round to verifying your patch - I was using my fix in the meantime but your patch addresses other issues as well.  I've backported and all my tests pass. I'd mark this as resolved but your patch has been reverted I see.

> Incorrect Bounding Box calculation results in the exclusion of valid data locations
> -----------------------------------------------------------------------------------
>
>                 Key: LUCENE-2475
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2475
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: contrib/spatial
>    Affects Versions: 2.9.1, 3.0
>            Reporter: Julian Atkinson
>         Attachments: BoundingBoxCalucationIssueTest.java, test.html
>
>
> I have found a scenario where some of my location data is not being returned.  The calculated distance between my search origin and the data is well within my search radius but the data is not being returned. 
> I have traced this down to what I think is an error when calculating the boundary box which is used to determine the Shape for the CartesianShapeFilter in  CartesianPolyFilterBuilder.getBoxShape()
> The boundary box calculated by LLRect.createBox() is incorrect.  The box returned is a box that fits WITHIN the search circle, where the four corners of the box intersect the circle line. This creates 4 regions where data points are not included - these are regions that are in the circle but outside the box.
> What I is required is a boundary box that fully CONTAINS the search circle.  As a side effect you would end up with 4 regions outside of the circle but inside the box.  This would potentially return data that are not real hits but these can be filtered out by a more precise distance comparison.
> I will attach a test class that covers the issue with more details and a proposed fix - a one liner in LLRect.java
> I would appreciate if someone could verify my findings.  All my data tests pass with this fix but there is one test case in Lucene 3.0.0 that fails and I can't figure out why.  TestCartesian.testAntiM().

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

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