[
https://issues.apache.org/jira/browse/LUCENE-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221625#comment-15221625
]
Karl Wright commented on LUCENE-7157:
-------------------------------------
bq. but now I hear you don't like things about it, or it won't work for you
(not sure which it really is: if its just some extra methods really bothering
you but not hurting you, or if you really need changes). I think we should not
do this forking, i do not agree with him there.
Just to clarify: the class allows access to the polygon information directly,
without going through methods that compute things, so I'm good with using it as
is. If those accessor methods *weren't* there I wouldn't be good with it. But
that is, as you say, a detail, and it can be worked out in the future.
I'm trying quite hard here to follow your lead on API since you seem to be the
person who is setting that. I was suddenly handed a huge concern about how the
Geo3DPoint API's looked and an utterly non-negotiable requirement that they
look identical to the 2D APIs, and I've been scrambling to keep up ever since.
Mike's proposal to fork the Polygon class was his attempt to be helpful here,
but I'm not going forward anyhow until all required API classes are publicly
available within spatial3d, however that is done.
The same APIs implemented by multiple people independently do need to be
semantically consistent. Where I see potential issues I thought it would be
good to raise them. So I'm raising them. I'm not in a position to write tests
for the 2D stuff right now that might show the issues -- I *do* have a day job
-- but please don't shoot the messenger.
> Geo3DPoint implementation should pay attention to the ordering of lat/lon
> points
> --------------------------------------------------------------------------------
>
> Key: LUCENE-7157
> URL: https://issues.apache.org/jira/browse/LUCENE-7157
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Karl Wright
>
> The LatLonPoint API implementation pays attention to the order of the points;
> "clockwise" means one side of the polygon boundary, and "counterclockwise"
> means the complement. We need to use that in Geo3DPoint and convert into
> whatever the underlying GeoPolygonFactory method requires.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
