[
https://issues.apache.org/jira/browse/SOLR-6446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley closed SOLR-6446.
------------------------------
Resolution: Not a Problem
Assignee: David Smiley
Hi. Without looking through your specific examples, I'm pretty sure what's
going on based on what you've said. In Lucene 4.7, Spatial4j was upgraded to
v0.4.1, which has a different default behavior for interpreting rectangular
polygons. Check out the release notes:
https://github.com/spatial4j/spatial4j/blob/master/CHANGES.md
{quote}
It used to be the case that rectangular polygons provided in WKT had to have
its vertexes given in counter-clockwise order to indicate which way around the
earth it went. The default is now the shorter width (less than 180 degrees).
This setting can be changed via the “datelineRule” setting. To avoid ambiguity,
just use the ENVELOPE syntax.
{quote}
The javadocs for datelineRule are here:
https://spatial4j.github.io/spatial4j/apidocs/com/spatial4j/core/io/jts/JtsWktShapeParser.DatelineRule.html
In particular, to get the former behavior, you should set
datelineRule="ccwRect" on the field type in your Solr schema.
As an aside, you might also want to add autoIndex="true" to see some speedup.
It's a new option in 0.4.
> Large spatial query problem
> ---------------------------
>
> Key: SOLR-6446
> URL: https://issues.apache.org/jira/browse/SOLR-6446
> Project: Solr
> Issue Type: Bug
> Components: spatial
> Affects Versions: 4.9
> Environment: Windows 7, Oracle JDK 1.7.0_45
> Reporter: Jon Hines
> Assignee: David Smiley
>
> We are currently upgrading from Solr 4.1 to 4.9 and have observed differences
> in spatial query results.
> Here are the relevant schema details:
> {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"/>
> {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 2 results. With this exact same
> configuration and data in Solr 4.1, the query yields all 3 results.
> {quote}
> geo:"Intersects(POLYGON((-126 -14, 128 -14, 128 35, -126 35, -126 -14)))"
> {quote}
> My assumption is that the query now goes the opposite way around the earth.
> This seems to be confirmed by the following query that spans the date line. I
> get the same 2 results.
> {quote}
> geo:"Intersects(POLYGON((128 -14, 128 35, -126 35, -126 -14, 128 -14)))"
> {quote}
> Have I uncovered a bug or is this actually how the system is supposed to
> behave now? Is there a way to get the old behavior? It is a requirement for
> us to allow these large polygon queries.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
