[ 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