You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Jon H (JIRA)" <ji...@apache.org> on 2015/04/21 21:14:58 UTC
[jira] [Comment Edited] (SOLR-7439) Large spatial query with high
precision yields incorrect results
[ https://issues.apache.org/jira/browse/SOLR-7439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14505542#comment-14505542 ]
Jon H edited comment on SOLR-7439 at 4/21/15 7:14 PM:
------------------------------------------------------
I now realize what I've done by truncating the points a couple decimal places for the second query is make a polygon that is a north oriented rectangle. I'm guessing that has something to do with the problem.
was (Author: jhines):
I now realize what I've done by truncating the points a couple decimal places for the second query is make a polygon that is a north oriented rectangle. I'm guess that has something to do with the problem.
> Large spatial query with high precision yields incorrect results
> ----------------------------------------------------------------
>
> Key: SOLR-7439
> URL: https://issues.apache.org/jira/browse/SOLR-7439
> Project: Solr
> Issue Type: Bug
> Components: spatial
> Affects Versions: 4.10.3
> Environment: Windows 7, Oracle JDK 1.8.0_40
> Reporter: Jon H
>
> I've noticed that queries with polygons that span more than 180 degrees can be interpreted as going the opposite way around the earth when the points have "many" decimal places.
> Here are the relevant schema details. Note I am using ccwRect for datelineRule.
> {quote}
> <field name="geo" type="location_rpt" indexed="true" stored="false"/>
> <fieldType name="location_rpt" class="solr.SpatialRecursivePrefixTreeFieldType"
> spatialContextFactory="com.spatial4j.core.context.jts.JtsSpatialContextFactory"
> geo="true" distErrPct="0.1" maxDistErr="0.000009" units="degrees"
> datelineRule="ccwRect" normWrapLongitude="true" autoIndex="true"/>
> {quote}
> JTS v1.10 jar has been added to the classpath.
> A simple test case that shows the problem:
> I have 3 documents indexed each with one of the following polygon values set for the "geo" field.
> {quote}
> POLYGON ((-0.70312499989791 8.0592296260867, 13.359374998139 8.0592296260867, 13.359374998139 21.616579333871, -0.70312499989791 21.616579333871, -0.70312499989791 8.0592296260867))
> POLYGON ((120.58593748322 13.923403895824, 132.53906248155 13.923403895824, 132.53906248155 25.165173365383, 120.58593748322 25.165173365383, 120.58593748322 13.923403895824))
> POLYGON ((-133.24218748145 0.35156029394437, -121.99218748302 0.35156029394437, -121.99218748302 11.523087505283, -133.24218748145 11.523087505283, -133.24218748145 0.35156029394437))
> {quote}
> When I execute this query, I get only 1 hit:
> {quote}
> geo:"Intersects(POLYGON((-136.40624998100992 -41.50857729267501,129.02343748203592 -41.50857729267501,129.02343748203583 58.4477327986157,-136.40624998100992 58.4477327986157,-136.40624998100992 -41.50857729267501))) distErrPct=0.0"
> {quote}
> Now if I run this query where a took off a couple decimal places from each point, I get 3 hits (this is what I would expect):
> {quote}
> geo:"Intersects(POLYGON((-136.406249981009 -41.508577292675,129.023437482035 -41.508577292675,129.023437482035 58.44773279861,-136.406249981009 58.44773279861,-136.406249981009 -41.508577292675))) distErrPct=0.0"
> {quote}
> It looks like the first query is actually doing the opposite of what I intend - it's being interpreted as the smaller area going the opposite way around the earth. I may be able alter my queries slightly so that I get the desired behavior but it seems like these queries should give the same results, correct?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org