[
https://issues.apache.org/jira/browse/LUCENE-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14586081#comment-14586081
]
David Smiley commented on LUCENE-6544:
--------------------------------------
I like the changes Karl.
Some feedback:
* GeoPath: I think the done() methods should throw an IllegalStateException if
it is called after it has already been called (edgePoints is already defined)?
And likewise, addPoint could throw if edgePoints is already defined.
* PlanetModel: I think the surfaceDistance() method should include javadocs to
mention that it's intended for non-spherical PlanetModel; for sphere use
GeoPoint.arcDistance. And for that matter, GeoPoint.arcDistance could mention
it's computation is surface of a sphere, and that for accurate ellipsoidal, use
PlanetModel.surfaceDistance().
The issue of thread-safety came to mind as I saw the lazy-evaluation of the
latitude & longitude. There should be some docs/language somewhere so that
people can understand that Geo3D generally isn't necessarily threadsafe, and
GeoPoint in particular isn't. Lazy BBox calculation of Geo3dShape is another
reason. This isn't necessarily a big deal but at least should be documented
for these two classes, indicating how to construct them such that they are
thread-safe. Come to think of it, even if an app knows to call
getLatitude/Longitude on GeoPoint so that it's fully constructed, it has no way
to do so on any use of GeoPoint embedded within other Geo3d shapes (such as
GeoDegenerateHorizontalLine). What do you think?
> Geo3d cleanup: Regularize path and polygon construction, plus consider adding
> ellipsoid surface distance method
> ---------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-6544
> URL: https://issues.apache.org/jira/browse/LUCENE-6544
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
> Reporter: Karl Wright
> Attachments: LUCENE-6544.patch
>
>
> Geo3d's way of constructing polygons and paths differs in that in one case
> you construct points and the other you feed lat/lon values directly to the
> builder. Probably both should be supported for both kinds of entity.
> Also it may be useful to have an accurate point-point ellipsoidal distance
> function. This is expensive and would be an addition to the arc distance we
> currently compute. It would probably be called "surface distance".
--
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
