lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1781) Large distances in Spatial go beyond Prime MEridian
Date Sat, 08 Aug 2009 09:21:14 GMT

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


Mime
View raw message