[
https://issues.apache.org/jira/browse/LUCENE-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14586120#comment-14586120
]
Karl Wright commented on LUCENE-6544:
-------------------------------------
I'm fine with the GeoPath and PlanetModel suggestions.
Thread safety is easier than you think, because all classes with lazy members
are in fact immutable *except* for those lazy members, and they are based only
other (immutable) characteristics of the classes in question. So the worst
that can happen if more than one thread attempts to fill in one of these values
is that it will be computed twice -- one time unnecessarily. I suspect that
therefore the only thing we really need to do is mention this in the javadoc
for the lazy variable(s), and maybe (could be wrong about this) declare those
variables to be volatile. Thoughts?
> 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
