[ https://issues.apache.org/jira/browse/LUCENE-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16178177#comment-16178177 ]
Karl Wright edited comment on LUCENE-7970 at 9/24/17 12:39 PM: --------------------------------------------------------------- [~ivera] The splitting algorithm described above yields the following number of planes for WGS84, where the first number reported is for the circle centered at lat = 0, and the last is the circle centered at lat = Math.PI * 0.5. So, to hit full accuracy, the number of planes is probably too high to be practical: {code} [junit4] 1> Number of planes needed: 1536 [junit4] 1> Number of planes needed: 1534 [junit4] 1> Number of planes needed: 1518 [junit4] 1> Number of planes needed: 1506 [junit4] 1> Number of planes needed: 1482 [junit4] 1> Number of planes needed: 2 {code} However, if we allow the user to determine the level of accuracy, and (for instance) the user chooses an accuracy level of 1 meter or so, then it may well be a different story. Trying that out next. Turns out that 1M accuracy isn't prohibitive at all: {code} [junit4] 1> Number of planes needed: 14 [junit4] 1> Number of planes needed: 14 [junit4] 1> Number of planes needed: 14 [junit4] 1> Number of planes needed: 14 [junit4] 1> Number of planes needed: 14 [junit4] 1> Number of planes needed: 2 {code} was (Author: kwri...@metacarta.com): [~ivera] The splitting algorithm described above yields the following number of planes for WGS84, where the first number reported is for the circle centered at lat = 0, and the last is the circle centered at lat = Math.PI * 0.5. So, to hit full accuracy, the number of planes is probably too high to be practical: {code} [junit4] 1> Number of planes needed: 1536 [junit4] 1> Number of planes needed: 1534 [junit4] 1> Number of planes needed: 1518 [junit4] 1> Number of planes needed: 1506 [junit4] 1> Number of planes needed: 1482 [junit4] 1> Number of planes needed: 2 {code} However, if we allow the user to determine the level of accuracy, and (for instance) the user chooses an accuracy level of 1 meter or so, then it may well be a different story. Trying that out next. > Add a Geo3d shape that models an exact circle, even when the planet model is > not a sphere > ----------------------------------------------------------------------------------------- > > Key: LUCENE-7970 > URL: https://issues.apache.org/jira/browse/LUCENE-7970 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d > Reporter: Ignacio Vera > Assignee: Karl Wright > Attachments: LUCENE_7970.patch, LUCENE-7970.patch, > LUCENE-7970-proposed.patch, LUCENE-7970_testBearingPoint.patch > > > Hi [~Karl wright], > How circles are currently build do not behave very well when the planet model > is not an sphere. when you are close to the border in WGS84 you might get > false positves or false negatives when checking if a point is WITHIN. I think > the reason is how the points to generate the circle plane are generated which > assumes a sphere. > My proposal is the following: > Add a new method to PlanetModel: > public GeoPoint pointOnBearing(GeoPoint from, double dist, double bearing); > Which uses and algorithm that takes into account that the planet might not be > spherical. For example Vincenty's formulae > (https://en.wikipedia.org/wiki/Vincenty%27s_formulae). > Use this method to generate the points for the circle plane. My experiments > shows that this approach removes false negatives in WGS84 meanwhile it works > nicely in the Sphere. > Does it make sense? -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org