[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org