[ https://issues.apache.org/jira/browse/LUCENE-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740859#action_12740859 ]
Michael McCandless commented on LUCENE-1781: -------------------------------------------- OK the new normLat looks like it handles crossing the pole now, by flipping the lng; thanks. Can you add a unit test that confirms this was a problem before, and that the new lng-flipping resolves it? Probably if you just modify TestCartesian, to add a new point, and then add a new test cast that starts from a lat/lng that's near the pole, you could get the issue to happen & be resolved. Also, can use "svn diff" and post the resulting output (instead of the whole copy of each source file)? Thanks. bq. The current Spatial ONLY works for one hemisphere at a time. Actually, shouldn't LLRect work fine if a rect crosses the equator? Or, a pole? What I think it cannot handle is crossing the anti-meridian? (Because, when that projects out, you'll need 2 rectangles, on opposite sides, to handle it?). I'm not sure what LLRect should even do if it finds it "needs" to cross the anti-meridian. If it had the ability to return 2 rectangles I think it could be fixed. Or are you saying there are further limitations in contrib/spatial (ie, not caused by LLRect) that cause it to only work within one hemisphere? As for the "we get no results when radius is very large" bug, I like the theory that the corners need to be flipped. Or, it could be the rect tried to cross the anti-meridian, and once we fix that, this case will also be fixed. Finally, it could also be we simply have to floor the the lat after normalizing. Ie before normalizing we get a ridiculous lat, say 1000.0, which normLat cannot handle since it can only "undo" at most "off by 90". I think normLat may need to be changed so that if it still sees lat/lng out of bounds after doing it's normalization, it simply floors the resulting lat? Can you add a test case for this case as well? We may as well get test cases for all the problems we're uncovering... then as we iterate on the patches we can see if they are fixed. > Large distances in Spatial go beyond Prime MEridian > --------------------------------------------------- > > Key: LUCENE-1781 > URL: https://issues.apache.org/jira/browse/LUCENE-1781 > Project: Lucene - Java > Issue Type: Bug > Components: contrib/spatial > Affects Versions: 2.9 > Environment: All > Reporter: Bill Bell > Assignee: Michael McCandless > Fix For: 3.1 > > Attachments: LLRect.java, LLRect.java, LUCENE-1781.patch > > > http://amidev.kaango.com/solr/core0/select?fl=*&json.nl=map&wt=json&radius=5000&rows=20&lat=39.5500507&q=honda&qt=geo&long=-105.7820674 > Get an error when using Solr when distance is calculated for the boundary box > past 90 degrees. > Aug 4, 2009 1:54:00 PM org.apache.solr.common.SolrException log > SEVERE: java.lang.IllegalArgumentException: Illegal lattitude value > 93.1558669413734 > at > org.apache.lucene.spatial.geometry.FloatLatLng.<init>(FloatLatLng.java:26) > at > org.apache.lucene.spatial.geometry.shape.LLRect.createBox(LLRect.java:93) > at > org.apache.lucene.spatial.tier.DistanceUtils.getBoundary(DistanceUtils.java:50) > at > org.apache.lucene.spatial.tier.CartesianPolyFilterBuilder.getBoxShape(CartesianPolyFilterBuilder.java:47) > at > org.apache.lucene.spatial.tier.CartesianPolyFilterBuilder.getBoundingArea(CartesianPolyFilterBuilder.java:109) > at > org.apache.lucene.spatial.tier.DistanceQueryBuilder.<init>(DistanceQueryBuilder.java:61) > at > com.pjaol.search.solr.component.LocalSolrQueryComponent.prepare(LocalSolrQueryComponent.java:151) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1328) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:244) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) > at > org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:857) > at > org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:565) > at > org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1509) > at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org