[
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: [email protected]):
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: [email protected]
For additional commands, e-mail: [email protected]
