[ 
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

Reply via email to