[
https://issues.apache.org/jira/browse/LUCENE-6480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14544686#comment-14544686
]
Karl Wright commented on LUCENE-6480:
-------------------------------------
I looked at the LUCENE-6481 patch and the mapping methods. Thanks for
including them.
It is not clear how these could be used to modify geo3D, since (as I mentioned
before) the math intersects planes with the unit sphere algebraically. The
logic which determines if a point is within a shape is largely robust against
differences in altitude, with some exceptions, so as I stated before shape
membership is not very sensitive to oblate spheroid vs. true sphere. There are
some exceptions to that, however -- for example, the side edges of paths do not
go through the origin, and therefore altitude will matter somewhat. Also,
membership in a GeoCircle is computed as being on the appropriate side of a
plane into which the circle is transcribed, which means that it is more
sensitive to altitude than any other shape geo3d supports. Polygons are
completely insensitive because their edges all go through the origin. Bounding
boxes are also sensitive, especially when top or bottom latitude is near a
pole, for very similar reasons to GeoCircles.
Public goe3D distance computations are done along GeoPaths and from the centers
of GeoCircles. While GeoCircles can have radii of up to 180 degrees, typical
usage is much smaller than that. The same is true for GeoPath segments, where
a kilometer or two would be typical. There is no distance computation for
large area-covering objects like polygons.
I doubt very much that it would be possible to *algebraically* change geo3D
completely to handle an oblate spheroid rather than a sphere. The places where
it breaks mathematically are as follows:
(1) Finding lat/lon bounds of a shape, which requires computing the maximum and
minimum latitude and longitude of the intersection of a plane and the unit
sphere
(2) Determining relationships between shapes, which requires intersecting
planes with the unit sphere
(3) Geocircles, because a plane is only an approximation for membership for an
oblate spheroid; you really require a warped plane, which is way beyond simple
mathematics to compute
Part-way solutions can be found, however, for the distance issue, since
distance computation is pretty much completely independent of everything else.
This will, of course, lead to "nonsense" answers where a point in a circle has
a greater distance to the center in some cases than the circle's radius, but
that can't be helped.
> Extend Simple GeoPointField Type to 3d
> ---------------------------------------
>
> Key: LUCENE-6480
> URL: https://issues.apache.org/jira/browse/LUCENE-6480
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/index
> Reporter: Nicholas Knize
>
> [LUCENE-6450 | https://issues.apache.org/jira/browse/LUCENE-6450] proposes a
> simple GeoPointField type to lucene core. This field uses 64bit encoding of 2
> dimensional points to construct sorted term representations of GeoPoints
> (aka: GeoHashing).
> This feature investigates adding support for encoding 3 dimensional
> GeoPoints, either by extending GeoPointField to a Geo3DPointField or adding
> an additional 3d constructor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
