[
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
