You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Karl Wright (JIRA)" <ji...@apache.org> on 2015/06/24 15:45:05 UTC

[jira] [Comment Edited] (LUCENE-6597) Geo3d circle creation that covers whole globe throws an IllegalArgumentException

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

Karl Wright edited comment on LUCENE-6597 at 6/24/15 1:44 PM:
--------------------------------------------------------------

bq. Why does the intersects() method return false when the circle is the world; shouldn't it return true? Or maybe I'm misunderstanding the semantics.

You're misunderstanding the semantics.  "intersects()" is whether the boundary intersects.  There is no boundary, hence no intersection.

bq. Do you think it may be worth constructing a special Circle subclass or special Plane subclass instead, thereby reducing the conditions you added to the methods?

I did think of that.  If you introduced a GeoCircleFactory class, which you used to construct circles, that might make sense.  Not sure this is worth it however.  It really is only a single minor special case for a circle.  The GeoBBox case is obviously rather different, because there really are a myriad of 3d shapes described by a bounding-box-style rectangle, each of which has significantly different logic.
In the longer run, there are some shapes that get constructed via a factory, and others via a constructor.  Regularizing usage to always rely on factories may make for a prettier API.  But I still don't think I'd change the GeoCircle implementation.

bq. Can you add a test please? Perhaps make the random test sometimes in a rare while pick a world circle.

It will.  Before it would have gotten an illegal argument exception, though, and continued.  But I will add an explicit test case.



was (Author: kwright@metacarta.com):
bq. Why does the intersects() method return false when the circle is the world; shouldn't it return true? Or maybe I'm misunderstanding the semantics.

You're misunderstanding the semantics.  "intersects()" is whether the boundary intersects.  There is no boundary, hence no intersection.

bq. Do you think it may be worth constructing a special Circle subclass or special Plane subclass instead, thereby reducing the conditions you added to the methods?

I did think of that.  If you introduced a GeoCircleFactory class, which you used to construct circles, that might make sense.  Not sure this is worth it however.  It really is only a single minor special case for a circle.

bq. Can you add a test please? Perhaps make the random test sometimes in a rare while pick a world circle.

It will.  Before it would have gotten an illegal argument exception, though, and continued.  But I will add an explicit test case.


> Geo3d circle creation that covers whole globe throws an IllegalArgumentException
> --------------------------------------------------------------------------------
>
>                 Key: LUCENE-6597
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6597
>             Project: Lucene - Core
>          Issue Type: Bug
>          Components: modules/spatial
>            Reporter: Karl Wright
>         Attachments: LUCENE-6597.patch
>
>
> The following GeoCircle construction:
> {code}
> new GeoCircle(PlanetModel.SPHERE, -20.0 * RADIANS_PER_DEGREE, -20.0 * RADIANS_PER_DEGREE, Math.PI);
> {code}
> ... fails as follows:
> {code}
> Degenerate/parallel vector constructed
> {code}
> The reason is that the plane normal vector cannot be computed in that case.  A special case is warranted for circles that cover the whole globe.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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