[jira] [Updated] (LUCENE-6480) Extend Simple GeoPointField Type to 3d
[ https://issues.apache.org/jira/browse/LUCENE-6480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6480: --- Component/s: (was: core/index) modules/spatial > Extend Simple GeoPointField Type to 3d > --- > > Key: LUCENE-6480 > URL: https://issues.apache.org/jira/browse/LUCENE-6480 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/spatial >Reporter: Nicholas Knize > Attachments: MortonEncoding3D.java > > > [LUCENE-6450 | https://issues.apache.org/jira/browse/LUCENE-6450] proposes a > simple GeoPointField type to lucene core. This field uses 64bit encoding of 2 > dimensional points to construct sorted term representations of GeoPoints > (aka: GeoHashing). > This feature investigates adding support for encoding 3 dimensional > GeoPoints, either by extending GeoPointField to a Geo3DPointField or adding > an additional 3d constructor. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6935) Improve random testing for GeoPointPointInPolygonQuery and DimensionalPointInPolygonQuery
[
https://issues.apache.org/jira/browse/LUCENE-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6935:
---
Component/s: modules/spatial
> Improve random testing for GeoPointPointInPolygonQuery and
> DimensionalPointInPolygonQuery
> -
>
> Key: LUCENE-6935
> URL: https://issues.apache.org/jira/browse/LUCENE-6935
> Project: Lucene - Core
> Issue Type: Test
> Components: modules/spatial
>Reporter: Nicholas Knize
>Priority: Minor
>
> Currently {{TestGeoPointQuery}} and {{TestDimensionalQueries}} only create
> bounding box polygons to test {{PointInPolygonQuery}}. This provides coverage
> for testing basic functionality but lacks critical testing with true random
> shapes. Random shape generation needs to be added to {{BaseGeoPointTestCase}}
> and used in {{newPolygonQuery}} for GeoPoint and DimensionalQuery testing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6930:
---
Component/s: modules/spatial
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch, LUCENE-6930.patch,
> LUCENE-6930.patch, LUCENE-6930.patch, LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6540) Add BKDPointDistanceQuery
[ https://issues.apache.org/jira/browse/LUCENE-6540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6540: --- Component/s: (was: core/search) modules/spatial > Add BKDPointDistanceQuery > - > > Key: LUCENE-6540 > URL: https://issues.apache.org/jira/browse/LUCENE-6540 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/spatial >Reporter: Nicholas Knize > > LUCENE-6532 adds the supporting mathematics for point-distance computation > based on the ellipsoid (using Vincenty's Direct and Inverse solutions). This > feature adds BKDPointDistance query function to LUCENE-6477 for finding all > documents that match the provided distance criteria from a given geo point. > This should out perform other solutions since we can stop traversing the BKD > tree once we've found an internal node that matches the given criteria. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6532) Add GeoPointDistanceQuery for GeoPointField type
[ https://issues.apache.org/jira/browse/LUCENE-6532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6532: --- Component/s: (was: core/search) modules/spatial > Add GeoPointDistanceQuery for GeoPointField type > > > Key: LUCENE-6532 > URL: https://issues.apache.org/jira/browse/LUCENE-6532 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/spatial >Reporter: Nicholas Knize > Attachments: LUCENE-6532.patch, LUCENE-6532.patch > > > [LUCENE-6481 | https://issues.apache.org/jira/browse/LUCENE-6481] adds > GeoPointField w/ GeoPointInBBox and GeoPointInPolygon queries. This feature > adds GeoPointDistanceQuery to support point radius queries. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6996) Deconflict GeoPointField and BKD LatLonField Encoding, Decoding, and Tolerance
[
https://issues.apache.org/jira/browse/LUCENE-6996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126615#comment-15126615
]
Nicholas Knize commented on LUCENE-6996:
Will do!
> Deconflict GeoPointField and BKD LatLonField Encoding, Decoding, and Tolerance
> --
>
> Key: LUCENE-6996
> URL: https://issues.apache.org/jira/browse/LUCENE-6996
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>
> Follow up to LUCENE-6956, BKD based {{LatLonField}} and postings based
> {{GeoPointField}} should use a consistent lat/lon encoding/decoding method to
> ensure consistent round-off error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6846) Handle Pole Crossing for GeoPointQuery
[ https://issues.apache.org/jira/browse/LUCENE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6846: --- Component/s: modules/spatial > Handle Pole Crossing for GeoPointQuery > -- > > Key: LUCENE-6846 > URL: https://issues.apache.org/jira/browse/LUCENE-6846 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial >Reporter: Nicholas Knize > > Dateline crossing is handled by way of a query rewrite for GeoPointInBBox and > GeoPointDistance queries. Pole crossing can be handled the same way but is > currently not implemented. This issue will implement pole crossing for > GeoPoint queries. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6994) GeoUtils Distance accuracy degrades with irregular rectangles
[ https://issues.apache.org/jira/browse/LUCENE-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6994: --- Component/s: modules/spatial > GeoUtils Distance accuracy degrades with irregular rectangles > - > > Key: LUCENE-6994 > URL: https://issues.apache.org/jira/browse/LUCENE-6994 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial >Reporter: Nicholas Knize > > This is a continuation of LUCENE-6908 which validates USGS accuracy of 0.5% > for Sinnott haversine distance calculation. The issue also introduced a space > segmentation approach for BKD distance queries near the poles. In LUCENE-6956 > a restriction on distance size was initially removed to randomly test BKD > distance queries at any range. This revealed an issue where distance error > nearly doubles for exotic rectangles created by BKD's split algorithm. This > issue will investigate potential distance error caused by the segmentation > approach introduced in the second part of LUCENE-6908. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6996) Deconflict GeoPointField and BKD LatLonField Encoding, Decoding, and Tolerance
[
https://issues.apache.org/jira/browse/LUCENE-6996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6996:
---
Component/s: modules/spatial
> Deconflict GeoPointField and BKD LatLonField Encoding, Decoding, and Tolerance
> --
>
> Key: LUCENE-6996
> URL: https://issues.apache.org/jira/browse/LUCENE-6996
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Nicholas Knize
>
> Follow up to LUCENE-6956, BKD based {{LatLonField}} and postings based
> {{GeoPointField}} should use a consistent lat/lon encoding/decoding method to
> ensure consistent round-off error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15123897#comment-15123897
]
Nicholas Knize commented on LUCENE-6997:
bq. It seems this has more to do with the presence of external dependencies
than trying to define what "lite" is vs "heavy"
agree!
I think this is a great compromise. Let me make sure I understand the changes
(slightly different but same result):
* rename spatial3d to lucene-spatial-extras (unless someone suggests a better
name I'm good with this).
* move existing s4j implementations to lucene-spatial-extras (which includes
geo3d)
* move sandbox spatial code to lucene-spatial and require it remain dependency
free
> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field
> currently in sandbox. It has evolved into a very fast lightweight geo option
> that heavily leverages the optimized performance of the postings structure.
> It was originally intended to graduate to core but this does not seem
> appropriate given the variety of "built on postings" term encoding options
> (e.g., see LUCENE-6930).
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight
> relational approximation utilities used by both {{GeoPointField}} and the BKD
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial
> module.
> These classes have been evolving and baking for some time and are at a
> maturity level qualifying for promotion from sandbox. This will allow support
> for experimental encoding methods with (minimal) backwards compatibility -
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and
> utility classes currently in sandbox would be promoted to the spatial3d
> package. (possibly a separate issue to rename spatial3d to spatialcore or
> spatiallite?) Such that for basic lightweight Geo support one would only need
> a handful of lucene jars. By simply adding the lucene-spatial module and its
> dependency jars users can obtain more advanced geospatial support (heatmap
> facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15124740#comment-15124740
]
Nicholas Knize commented on LUCENE-6997:
+1 as well! A separate issue for geo3d sounds like the right move to me.
I'd like to work this before committing LUCENE-6930, any objections?
> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field
> currently in sandbox. It has evolved into a very fast lightweight geo option
> that heavily leverages the optimized performance of the postings structure.
> It was originally intended to graduate to core but this does not seem
> appropriate given the variety of "built on postings" term encoding options
> (e.g., see LUCENE-6930).
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight
> relational approximation utilities used by both {{GeoPointField}} and the BKD
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial
> module.
> These classes have been evolving and baking for some time and are at a
> maturity level qualifying for promotion from sandbox. This will allow support
> for experimental encoding methods with (minimal) backwards compatibility -
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and
> utility classes currently in sandbox would be promoted to the spatial3d
> package. (possibly a separate issue to rename spatial3d to spatialcore or
> spatiallite?) Such that for basic lightweight Geo support one would only need
> a handful of lucene jars. By simply adding the lucene-spatial module and its
> dependency jars users can obtain more advanced geospatial support (heatmap
> facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121761#comment-15121761
]
Nicholas Knize edited comment on LUCENE-6997 at 1/28/16 3:52 PM:
-
bq. What's missing, in your opinion? And did you actually mean Spatial4j? FYI
JTS as of yesterday is licensed BSD.
Hey wonderful! I actually meant JTS. Last conversation I had with Martin he
wasn't confident in a friendly timeline for relicense. I think the larger
discussion re: dependencies is still relevant? Unless there's a blacklist
somewhere of licenses we will always reject.
bq. I think Maven "optional" dependencies are for uses cases where you need a
class only at compile time (mandatory), but consumer (runtime) may not need it,
Its likely I misunderstood this so this clarification will certainly help. I
thought Java's module system is changing in Java 9 such that it needs all
dependencies at runtime? That's the relevancy of Java 9 in the discussion.
was (Author: nknize):
bq. What's missing, in your opinion? And did you actually mean Spatial4j? FYI
JTS as of yesterday is licensed BSD.
Hey wonderful! I actually meant JTS. Last conversation I had with Martin he
wasn't confident in a friendly timeline for relicense. I think the larger
discussion re: dependencies is still relevant? Unless there's a blacklist
somewhere of licenses we will always reject.
bq. I think Maven "optional" dependencies are for uses cases where you need a
class only at compile time (mandatory), but consumer (runtime) may not need it,
Its likely I misunderstood this so this clarification will certainly help. I
thought Java's module system is changing in Java 9 such that it needs all
dependencies are needed at runtime? That's the relevancy of Java 9 in the
discussion.
> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field
> currently in sandbox. It has evolved into a very fast lightweight geo option
> that heavily leverages the optimized performance of the postings structure.
> It was originally intended to graduate to core but this does not seem
> appropriate given the variety of "built on postings" term encoding options
> (e.g., see LUCENE-6930).
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight
> relational approximation utilities used by both {{GeoPointField}} and the BKD
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial
> module.
> These classes have been evolving and baking for some time and are at a
> maturity level qualifying for promotion from sandbox. This will allow support
> for experimental encoding methods with (minimal) backwards compatibility -
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and
> utility classes currently in sandbox would be promoted to the spatial3d
> package. (possibly a separate issue to rename spatial3d to spatialcore or
> spatiallite?) Such that for basic lightweight Geo support one would only need
> a handful of lucene jars. By simply adding the lucene-spatial module and its
> dependency jars users can obtain more advanced geospatial support (heatmap
> facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121827#comment-15121827
]
Nicholas Knize commented on LUCENE-6997:
Thanks for clearing that up [~thetaphi]!
Then it boils down to the value of having a spatial module for the simple use
case that users don't have to worry about dependency management. If there's
agreement in having that value then these classes should go into that package.
If not, then either a. spatial3d could be refactored back to the spatial module
(since JTS license is no longer an issue), or b. the GeoUtils classes go into
spatial3d (renaming still seems appropriate) and the Lucene Query and Field
classes go into the spatial module.
I'm open to thoughts or other ideas.
> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field
> currently in sandbox. It has evolved into a very fast lightweight geo option
> that heavily leverages the optimized performance of the postings structure.
> It was originally intended to graduate to core but this does not seem
> appropriate given the variety of "built on postings" term encoding options
> (e.g., see LUCENE-6930).
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight
> relational approximation utilities used by both {{GeoPointField}} and the BKD
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial
> module.
> These classes have been evolving and baking for some time and are at a
> maturity level qualifying for promotion from sandbox. This will allow support
> for experimental encoding methods with (minimal) backwards compatibility -
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and
> utility classes currently in sandbox would be promoted to the spatial3d
> package. (possibly a separate issue to rename spatial3d to spatialcore or
> spatiallite?) Such that for basic lightweight Geo support one would only need
> a handful of lucene jars. By simply adding the lucene-spatial module and its
> dependency jars users can obtain more advanced geospatial support (heatmap
> facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121761#comment-15121761
]
Nicholas Knize commented on LUCENE-6997:
bq. What's missing, in your opinion? And did you actually mean Spatial4j? FYI
JTS as of yesterday is licensed BSD.
Hey wonderful! I actually meant JTS. Last conversation I had with Martin he
wasn't confident in a friendly timeline for relicense. I think the larger
discussion re: dependencies is still relevant? Unless there's a blacklist
somewhere of licenses we will always reject.
bq. I think Maven "optional" dependencies are for uses cases where you need a
class only at compile time (mandatory), but consumer (runtime) may not need it,
Its likely I misunderstood this so this clarification will certainly help. I
thought Java's module system is changing in Java 9 such that it needs all
dependencies are needed at runtime? That's the relevancy of Java 9 in the
discussion.
> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field
> currently in sandbox. It has evolved into a very fast lightweight geo option
> that heavily leverages the optimized performance of the postings structure.
> It was originally intended to graduate to core but this does not seem
> appropriate given the variety of "built on postings" term encoding options
> (e.g., see LUCENE-6930).
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight
> relational approximation utilities used by both {{GeoPointField}} and the BKD
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial
> module.
> These classes have been evolving and baking for some time and are at a
> maturity level qualifying for promotion from sandbox. This will allow support
> for experimental encoding methods with (minimal) backwards compatibility -
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and
> utility classes currently in sandbox would be promoted to the spatial3d
> package. (possibly a separate issue to rename spatial3d to spatialcore or
> spatiallite?) Such that for basic lightweight Geo support one would only need
> a handful of lucene jars. By simply adding the lucene-spatial module and its
> dependency jars users can obtain more advanced geospatial support (heatmap
> facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121761#comment-15121761
]
Nicholas Knize edited comment on LUCENE-6997 at 1/28/16 4:12 PM:
-
bq. What's missing, in your opinion? And did you actually mean Spatial4j? FYI
JTS as of yesterday is licensed BSD.
Hey wonderful! I actually meant JTS. Last conversation I had with Martin he
wasn't confident in a friendly timeline for relicense. I think the larger
discussion re: dependencies is still relevant? Unless there's a blacklist
somewhere of licenses we will always reject.
bq. I think Maven "optional" dependencies are for uses cases where you need a
class only at compile time (mandatory), but consumer (runtime) may not need it,
Its likely I misunderstood this so this clarification will certainly help. I
thought Java's module system is changing in Java 9 such that it needs all
dependencies at runtime (even if the dependencies are not used)? That's the
relevancy of Java 9 in the discussion.
was (Author: nknize):
bq. What's missing, in your opinion? And did you actually mean Spatial4j? FYI
JTS as of yesterday is licensed BSD.
Hey wonderful! I actually meant JTS. Last conversation I had with Martin he
wasn't confident in a friendly timeline for relicense. I think the larger
discussion re: dependencies is still relevant? Unless there's a blacklist
somewhere of licenses we will always reject.
bq. I think Maven "optional" dependencies are for uses cases where you need a
class only at compile time (mandatory), but consumer (runtime) may not need it,
Its likely I misunderstood this so this clarification will certainly help. I
thought Java's module system is changing in Java 9 such that it needs all
dependencies at runtime? That's the relevancy of Java 9 in the discussion.
> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field
> currently in sandbox. It has evolved into a very fast lightweight geo option
> that heavily leverages the optimized performance of the postings structure.
> It was originally intended to graduate to core but this does not seem
> appropriate given the variety of "built on postings" term encoding options
> (e.g., see LUCENE-6930).
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight
> relational approximation utilities used by both {{GeoPointField}} and the BKD
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial
> module.
> These classes have been evolving and baking for some time and are at a
> maturity level qualifying for promotion from sandbox. This will allow support
> for experimental encoding methods with (minimal) backwards compatibility -
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and
> utility classes currently in sandbox would be promoted to the spatial3d
> package. (possibly a separate issue to rename spatial3d to spatialcore or
> spatiallite?) Such that for basic lightweight Geo support one would only need
> a handful of lucene jars. By simply adding the lucene-spatial module and its
> dependency jars users can obtain more advanced geospatial support (heatmap
> facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6930:
---
Attachment: LUCENE-6930.patch
Updated patch to include review feedback.
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch, LUCENE-6930.patch,
> LUCENE-6930.patch, LUCENE-6930.patch, LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15120345#comment-15120345
]
Nicholas Knize commented on LUCENE-6930:
Thanks for the feedback [~mikemccand]! I'll post an updated patch shortly. In
the meantime I think this will be blocked by LUCENE-6997 so I may put this in a
feature branch.
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch, LUCENE-6930.patch,
> LUCENE-6930.patch, LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15120317#comment-15120317
]
Nicholas Knize commented on LUCENE-6997:
bq. ...can you explain better? I'm unfamiliar with restrictions imposed by
sandbox.
I had the understanding the sandbox module provides no backwards compatibility.
Not "it doesn't guarantee backwards compatibility" but there is "NO backwards
compatibility". Other modules do not have this restriction. In this particular
case the restriction makes it difficult/impossible to experiment and evolve
alternative postings based encoding methods without adding some crazy
abstraction layer (that just masks backcompat), or duplicating code and (like
codecs) changing class names.
bq. ...doesn't depend on Spatial4j (what I assume you imply by "dependency
free")
Just no dependencies whatsoever, be them optional or not (to include JTS or
future dependencies).
bq. I don't think that need be fundamental to the spatial module's future.
I agree. While the GeoUtils API is really close to being able to remove the JTS
dependency there are some Apache friendly libraries I think would really boost
lucene-spatial's capabilities. And IMHO that's what defines the lucene-spatial
module. A provider of the more advanced GIS capabilities with dependencies from
only "friendly" licenses (I'm not a lawyer so I don't know what this list would
include).
bq. From a maven standpoint, they could be marked "optional".
I think that's part of the benefits for having a lightweight dependency free
module. I was told (and did some quick research - a la elgoog) that optional
dependencies are no longer going to be supported by Java 9? I'm sure someone
far smarter than me on Java 9 can chime in but if class A depends on B which
optionally depends on C you can no longer include B without C? Sounds like that
will break the current Spatial4J / JTS model? Also Optional dependencies aren't
well supported for build systems other than maven (e.g., gradle)? I'm certainly
not a gradle expert (by any means) but I know I've seen this as enough of a
headache in the past that gradle users try to avoid them unless necessary.
To me these seem like compelling reasons to split the complexity of spatial
into a lightweight dependency free core module that can be leveraged by modules
that either do or do not have a dependency restriction.
> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field
> currently in sandbox. It has evolved into a very fast lightweight geo option
> that heavily leverages the optimized performance of the postings structure.
> It was originally intended to graduate to core but this does not seem
> appropriate given the variety of "built on postings" term encoding options
> (e.g., see LUCENE-6930).
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight
> relational approximation utilities used by both {{GeoPointField}} and the BKD
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial
> module.
> These classes have been evolving and baking for some time and are at a
> maturity level qualifying for promotion from sandbox. This will allow support
> for experimental encoding methods with (minimal) backwards compatibility -
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and
> utility classes currently in sandbox would be promoted to the spatial3d
> package. (possibly a separate issue to rename spatial3d to spatialcore or
> spatiallite?) Such that for basic lightweight Geo support one would only need
> a handful of lucene jars. By simply adding the lucene-spatial module and its
> dependency jars users can obtain more advanced geospatial support (heatmap
> facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
Nicholas Knize created LUCENE-6997:
--
Summary: Graduate GeoUtils and postings based GeoPointField from
sandbox...
Key: LUCENE-6997
URL: https://issues.apache.org/jira/browse/LUCENE-6997
Project: Lucene - Core
Issue Type: Improvement
Reporter: Nicholas Knize
{{GeoPointField}} is a lightweight dependency-free postings based geo field
currently in sandbox. It has evolved into a very fast lightweight geo option
that heavily leverages the optimized performance of the postings structure. It
was originally intended to graduate to core but this does not seem appropriate
given the variety of "built on postings" term encoding options (e.g., see
LUCENE-6930).
Additionally, the {{Geo*Utils}} classes are dependency free lightweight
relational approximation utilities used by both {{GeoPointField}} and the BKD
based {{LatLonField}} and can also be applied to benefit the lucene-spatial
module.
These classes have been evolving and baking for some time and are at a maturity
level qualifying for promotion from sandbox. This will allow support for
experimental encoding methods with (minimal) backwards compatibility -
something sandbox does not allow.
Since GeoPoint classes are dependency free, all GeoPointField and support and
utility classes currently in sandbox would be promoted to the spatial3d
package. (possibly a separate issue to rename spatial3d to spatialcore or
spatiallite?) Such that for basic lightweight Geo support one would only need a
handful of lucene jars. By simply adding the lucene-spatial module and its
dependency jars users can obtain more advanced geospatial support (heatmap
facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize resolved LUCENE-6956.
Resolution: Fixed
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956-enc.patch, LUCENE-6956.patch,
> LUCENE-6956.patch, LUCENE-6956.patch, LUCENE-6956.patch, LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836 lon=-9.408821929246187
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30077 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29821
>[junit4] 1> lat=86.84681385755539 lon=-8.837449550628662
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30185 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29929
>
[jira] [Updated] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6930:
---
Attachment: LUCENE-6930.patch
Corrected patch
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch, LUCENE-6930.patch,
> LUCENE-6930.patch, LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15117389#comment-15117389
]
Nicholas Knize commented on LUCENE-6956:
++ Thanks for reminding me where that came from! I forgot we are using 2
different encoding methods for BKD and GeoPoint. The GeoPointEncoding of 31
bits was for supporting the GeoHash bit twiddle methods in {{GeoHashUtils}}. We
had issue LUCENE-6710 that used the full 32 bits but I reverted it because of
conflicts the the GeoHash string encoding.
I'll go back to 32 bits so BKD and GeoUtils encoding methods and rounding error
are consistent and we can use the same encoding methods for BKD and GeoPoint.
Separately I'll fix up the GeoHash string encoding to work with the 32 bit
encoding changes and deconflict tests.
bq. I also separately added tests to confirm the encode/decode are stable
Which encoding, BKD? {{TestGeoUtils.testGeoHash}} tests morton and geohash
stabilization for GeoUtils.
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956-enc.patch, LUCENE-6956.patch,
> LUCENE-6956.patch, LUCENE-6956.patch, LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836 lon=-9.408821929246187
>[junit4] 1> deleted?=false
>[junit4] 1>
[jira] [Created] (LUCENE-6996) Deconflict GeoPointField and BKD LatLonField Encoding, Decoding, and Tolerance
Nicholas Knize created LUCENE-6996:
--
Summary: Deconflict GeoPointField and BKD LatLonField Encoding,
Decoding, and Tolerance
Key: LUCENE-6996
URL: https://issues.apache.org/jira/browse/LUCENE-6996
Project: Lucene - Core
Issue Type: Improvement
Reporter: Nicholas Knize
Follow up to LUCENE-6956, BKD based {{LatLonField}} and postings based
{{GeoPointField}} should use a consistent lat/lon encoding/decoding method to
ensure consistent round-off error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6956:
---
Attachment: LUCENE-6956.patch
Updated patch that reverts BKD tolerance back to {{1e-7}}. I opened LUCENE-6996
as a separate issue to reconcile encoding/decoding resolution and tolerance
between BKD and GeoPoint.
This should be ready, I'd like to get this committed before LUCENE-6930 and
then tackle the encoding resolution.
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956-enc.patch, LUCENE-6956.patch,
> LUCENE-6956.patch, LUCENE-6956.patch, LUCENE-6956.patch, LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836 lon=-9.408821929246187
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30077 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29821
>[junit4] 1> lat=86.84681385755539 lon=-8.837449550628662
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30185 should match but did not
[jira] [Commented] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15118233#comment-15118233
]
Nicholas Knize commented on LUCENE-6930:
argghh.. guessed the fancy {{--show-copies-as-adds}} didn't work this time.
I'll prep a new patch shortly. Thx [~mikemccand]!
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch, LUCENE-6930.patch,
> LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15115991#comment-15115991
]
Nicholas Knize commented on LUCENE-6956:
Oh, sorry for not addressing the {{1e-7}} question. With the 32 bit
quantization encoding error can exceed {{1e-7}} but not {{1e-6}}. So its not
that its weakening the test, its that once a point is indexed (quantized from
two doubles to two 32 bit ints) the location can be affected by that much. I'm
not exactly sure where 1e-7 came from? I can reduce it from 1e-6 but, in all
honesty, I haven't worked out the exact maximum error. That could be a fun and
useful exercise, just haven't had the time.
bq. Hmm I hit this failure with the patch after a some beasting:
Looks like the TestGeoUtils distance test doesn't have any boundary checks, so
this is related to above. I thought I added a boundary check (e.g., return null
boolean)? Maybe it was stepped on? I can add it back.
bq. Can we rename GeoRelationUtils.pointInRect to .pointInRectPrecise since
it's now comparing doubles directly?
Absolutely!
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956.patch, LUCENE-6956.patch, LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836
[jira] [Comment Edited] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15116002#comment-15116002
]
Nicholas Knize edited comment on LUCENE-6930 at 1/25/16 8:50 PM:
-
Updated patch to include the following:
* incorporate review feedback
* override {{GeoPointPrefixTermsEnum.accept}} to "seek" to the "floor" range
of the candidate term. This boosts query performance by eliminating superfluous
range visits.
* fixed bug in {{GeoEncodingUtils.geoCodedToPrefixCodedBytes}} and
{{.getPrefixCodedLongShift}} that was ignoring the {{BytesRef.offset}} variable
I'm going to open up another query performance improvement issue that switches
from comparing BytesRefs to directly comparing the long encoded range values.
This will instead convert candidate terms to their encoded range values and
eliminate the need for constantly converting ranges to BytesRefs for
comparisons.
NOTE: Beast testing this may result in some accuracy failures that are being
fixed separately by LUCENE-6956
was (Author: nknize):
Updated patch to include the following:
* incorporate review feedback
* override {{GeoPointPrefixTermsEnum.accept}} to "seek" to the "floor" range
of the candidate term. This boosts query performance by eliminating superfluous
range visits.
* fixed bug in {{GeoEncodingUtils.geoCodedToPrefixCodedBytes}} and
{{.getPrefixCodedLongShift}} that was ignoring the {{BytesRef.offset}} variable
I'm going to open up another query performance improvement issue that switches
from comparing BytesRefs to directly comparing the long encoded range values.
This will instead convert candidate terms to their encoded range values and
eliminate the need for constantly converting ranges to BytesRefs for
comparisons.
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch, LUCENE-6930.patch,
> LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6930:
---
Attachment: LUCENE-6930.patch
Updated patch to include the following:
* incorporate review feedback
* override {{GeoPointPrefixTermsEnum.accept}} to "seek" to the "floor" range
of the candidate term. This boosts query performance by eliminating superfluous
range visits.
* fixed bug in {{GeoEncodingUtils.geoCodedToPrefixCodedBytes}} and
{{.getPrefixCodedLongShift}} that was ignoring the {{BytesRef.offset}} variable
I'm going to open up another query performance improvement issue that switches
from comparing BytesRefs to directly comparing the long encoded range values.
This will instead convert candidate terms to their encoded range values and
eliminate the need for constantly converting ranges to BytesRefs for
comparisons.
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch, LUCENE-6930.patch,
> LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6994) GeoUtils Distance accuracy degrades with irregular rectangles
Nicholas Knize created LUCENE-6994: -- Summary: GeoUtils Distance accuracy degrades with irregular rectangles Key: LUCENE-6994 URL: https://issues.apache.org/jira/browse/LUCENE-6994 Project: Lucene - Core Issue Type: Bug Reporter: Nicholas Knize This is a continuation of LUCENE-6908 which validates USGS accuracy of 0.5% for Sinnott haversine distance calculation. The issue also introduced a space segmentation approach for BKD distance queries near the poles. In LUCENE-6956 a restriction on distance size was initially removed to randomly test BKD distance queries at any range. This revealed an issue where distance error nearly doubles for exotic rectangles created by BKD's split algorithm. This issue will investigate potential distance error caused by the segmentation approach introduced in the second part of LUCENE-6908. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6956:
---
Attachment: LUCENE-6956.patch
Updated patch to address comments. Note: distance size restriction was added
back and new issue LUCENE-6994 was opened to investigate distance accuracy
issues.
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956.patch, LUCENE-6956.patch, LUCENE-6956.patch,
> LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836 lon=-9.408821929246187
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30077 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29821
>[junit4] 1> lat=86.84681385755539 lon=-8.837449550628662
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30185 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456]
[jira] [Commented] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15116246#comment-15116246
]
Nicholas Knize commented on LUCENE-6956:
bq. Hmm I hit this failure with the patch after a some beasting
Dug deeper and this error revealed a 2x accuracy issue with large exotic
rectangles created by the BKD split approach. (different from the pole
crossing). I added back the distance restriction and opened LUCENE-6994 to
address the accuracy issue.
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956.patch, LUCENE-6956.patch, LUCENE-6956.patch,
> LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836 lon=-9.408821929246187
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30077 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29821
>[junit4] 1> lat=86.84681385755539 lon=-8.837449550628662
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30185 should match but did not
>[junit4] 1>
[jira] [Updated] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6956:
---
Attachment: LUCENE-6956.patch
Updated patch that includes all feedback.
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956.patch, LUCENE-6956.patch, LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836 lon=-9.408821929246187
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30077 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29821
>[junit4] 1> lat=86.84681385755539 lon=-8.837449550628662
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30185 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29929
>[junit4] 1>
[jira] [Commented] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15114772#comment-15114772
]
Nicholas Knize commented on LUCENE-6956:
done!
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956.patch, LUCENE-6956.patch, LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836 lon=-9.408821929246187
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30077 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29821
>[junit4] 1> lat=86.84681385755539 lon=-8.837449550628662
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30185 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29929
>[junit4] 1> lat=86.84285902418196
[jira] [Commented] (LUCENE-6974) TesGeoPointQuery failures: some hits were wrong (should not match but did)
[
https://issues.apache.org/jira/browse/LUCENE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15112989#comment-15112989
]
Nicholas Knize commented on LUCENE-6974:
It can be resolved. Looks like I don't have that power on this issue. :/
> TesGeoPointQuery failures: some hits were wrong (should not match but did)
> --
>
> Key: LUCENE-6974
> URL: https://issues.apache.org/jira/browse/LUCENE-6974
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Steve Rowe
> Attachments: LUCENE-6974.patch
>
>
> Reproducible failure from Policeman Jenkins
> [http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15540/]:
> {noformat}
>[junit4] Suite: org.apache.lucene.search.TestGeoPointQuery
>[junit4] 1> T0: id=1 should not match but did
>[junit4] 1> small=true query=GeoPointInPolygonQuery: field=point:
> Points: [4.3475002236664295, -39.484346117824316] [4.3475002236664295,
> -38.95751953125] [5.824887603521347, -38.95751953125] [5.824887603521347,
> -39.484346117824316] [4.3475002236664295, -39.484346117824316] docID=1
>[junit4] 1> lat=-38.94430998712778 lon=4.362290930002928
>[junit4] 1> deleted?=false
>[junit4] 2> JAN 13, 2016 6:53:32 R?
> com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
> uncaughtException
>[junit4] 2> WARNING: Uncaught exception in thread:
> Thread[T0,5,TGRP-TestGeoPointQuery]
>[junit4] 2> java.lang.AssertionError: some hits were wrong
>[junit4] 2> at
> __randomizedtesting.SeedInfo.seed([30950A47BB2DFA04]:0)
>[junit4] 2> at org.junit.Assert.fail(Assert.java:93)
>[junit4] 2> at
> org.apache.lucene.util.BaseGeoPointTestCase$VerifyHits.test(BaseGeoPointTestCase.java:554)
>[junit4] 2> at
> org.apache.lucene.util.BaseGeoPointTestCase$2._run(BaseGeoPointTestCase.java:758)
>[junit4] 2> at
> org.apache.lucene.util.BaseGeoPointTestCase$2.run(BaseGeoPointTestCase.java:625)
>[junit4] 2>
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestGeoPointQuery
> -Dtests.method=testRandomTiny -Dtests.seed=30950A47BB2DFA04
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=mer_KE
> -Dtests.timezone=America/Martinique -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR 0.93s J0 | TestGeoPointQuery.testRandomTiny <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase.verify(BaseGeoPointTestCase.java:772)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase.doTestRandom(BaseGeoPointTestCase.java:411)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase.testRandomTiny(BaseGeoPointTestCase.java:331)
>[junit4]> at java.lang.Thread.run(Thread.java:747)Throwable #2:
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an
> uncaught exception in thread: Thread[id=57, name=T0, state=RUNNABLE,
> group=TGRP-TestGeoPointQuery]
>[junit4]> Caused by: java.lang.AssertionError: some hits were wrong
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([30950A47BB2DFA04]:0)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase$VerifyHits.test(BaseGeoPointTestCase.java:554)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase$2._run(BaseGeoPointTestCase.java:758)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase$2.run(BaseGeoPointTestCase.java:625)
>[junit4] IGNOR/A 0.01s J0 | TestGeoPointQuery.testRandomBig
>[junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
>[junit4] IGNOR/A 0.00s J0 | TestGeoPointQuery.testAllLatEqual
>[junit4]> Assumption #1: GeoPoint*Query is too slow otherwise
>[junit4] 1> T1: id=15902 should not match but did
>[junit4] 1> small=true query=GeoPointInPolygonQuery: field=point:
> Points: [4.3475002236664295, -39.484346117824316] [4.3475002236664295,
> -38.95751953125] [5.824887603521347, -38.95751953125] [5.824887603521347,
> -39.484346117824316] [4.3475002236664295, -39.484346117824316] docID=714
>[junit4] 1> lat=-38.95061678253114 lon=5.752138886600733
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=16650 should not match but did
>[junit4] 1> small=true query=GeoPointInPolygonQuery: field=point:
> Points: [4.3475002236664295, -39.484346117824316] [4.3475002236664295,
> -38.95751953125] [5.824887603521347, -38.95751953125] [5.824887603521347,
> -39.484346117824316] [4.3475002236664295, -39.484346117824316] docID=739
>[junit4] 1> lat=-38.94194939173758 lon=5.094362664967775
>[junit4] 1> deleted?=false
>[junit4] 1>
[jira] [Resolved] (LUCENE-6974) TesGeoPointQuery failures: some hits were wrong (should not match but did)
[
https://issues.apache.org/jira/browse/LUCENE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize resolved LUCENE-6974.
Resolution: Resolved
> TesGeoPointQuery failures: some hits were wrong (should not match but did)
> --
>
> Key: LUCENE-6974
> URL: https://issues.apache.org/jira/browse/LUCENE-6974
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Steve Rowe
> Attachments: LUCENE-6974.patch
>
>
> Reproducible failure from Policeman Jenkins
> [http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15540/]:
> {noformat}
>[junit4] Suite: org.apache.lucene.search.TestGeoPointQuery
>[junit4] 1> T0: id=1 should not match but did
>[junit4] 1> small=true query=GeoPointInPolygonQuery: field=point:
> Points: [4.3475002236664295, -39.484346117824316] [4.3475002236664295,
> -38.95751953125] [5.824887603521347, -38.95751953125] [5.824887603521347,
> -39.484346117824316] [4.3475002236664295, -39.484346117824316] docID=1
>[junit4] 1> lat=-38.94430998712778 lon=4.362290930002928
>[junit4] 1> deleted?=false
>[junit4] 2> JAN 13, 2016 6:53:32 R?
> com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
> uncaughtException
>[junit4] 2> WARNING: Uncaught exception in thread:
> Thread[T0,5,TGRP-TestGeoPointQuery]
>[junit4] 2> java.lang.AssertionError: some hits were wrong
>[junit4] 2> at
> __randomizedtesting.SeedInfo.seed([30950A47BB2DFA04]:0)
>[junit4] 2> at org.junit.Assert.fail(Assert.java:93)
>[junit4] 2> at
> org.apache.lucene.util.BaseGeoPointTestCase$VerifyHits.test(BaseGeoPointTestCase.java:554)
>[junit4] 2> at
> org.apache.lucene.util.BaseGeoPointTestCase$2._run(BaseGeoPointTestCase.java:758)
>[junit4] 2> at
> org.apache.lucene.util.BaseGeoPointTestCase$2.run(BaseGeoPointTestCase.java:625)
>[junit4] 2>
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestGeoPointQuery
> -Dtests.method=testRandomTiny -Dtests.seed=30950A47BB2DFA04
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=mer_KE
> -Dtests.timezone=America/Martinique -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR 0.93s J0 | TestGeoPointQuery.testRandomTiny <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase.verify(BaseGeoPointTestCase.java:772)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase.doTestRandom(BaseGeoPointTestCase.java:411)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase.testRandomTiny(BaseGeoPointTestCase.java:331)
>[junit4]> at java.lang.Thread.run(Thread.java:747)Throwable #2:
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an
> uncaught exception in thread: Thread[id=57, name=T0, state=RUNNABLE,
> group=TGRP-TestGeoPointQuery]
>[junit4]> Caused by: java.lang.AssertionError: some hits were wrong
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([30950A47BB2DFA04]:0)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase$VerifyHits.test(BaseGeoPointTestCase.java:554)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase$2._run(BaseGeoPointTestCase.java:758)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase$2.run(BaseGeoPointTestCase.java:625)
>[junit4] IGNOR/A 0.01s J0 | TestGeoPointQuery.testRandomBig
>[junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
>[junit4] IGNOR/A 0.00s J0 | TestGeoPointQuery.testAllLatEqual
>[junit4]> Assumption #1: GeoPoint*Query is too slow otherwise
>[junit4] 1> T1: id=15902 should not match but did
>[junit4] 1> small=true query=GeoPointInPolygonQuery: field=point:
> Points: [4.3475002236664295, -39.484346117824316] [4.3475002236664295,
> -38.95751953125] [5.824887603521347, -38.95751953125] [5.824887603521347,
> -39.484346117824316] [4.3475002236664295, -39.484346117824316] docID=714
>[junit4] 1> lat=-38.95061678253114 lon=5.752138886600733
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=16650 should not match but did
>[junit4] 1> small=true query=GeoPointInPolygonQuery: field=point:
> Points: [4.3475002236664295, -39.484346117824316] [4.3475002236664295,
> -38.95751953125] [5.824887603521347, -38.95751953125] [5.824887603521347,
> -39.484346117824316] [4.3475002236664295, -39.484346117824316] docID=739
>[junit4] 1> lat=-38.94194939173758 lon=5.094362664967775
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=16686 should not match but did
>[junit4] 1> small=true
[jira] [Commented] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15112630#comment-15112630
]
Nicholas Knize commented on LUCENE-6930:
That's unrelated to this patch. Its from nuking the pre-quantization in the
tests and is being fixed by LUCENE-6956.
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch, LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6956:
---
Attachment: LUCENE-6956.patch
The issue is related to the performance improvements added in LUCENE-6951. That
approximation exploits characteristics of the range based GeoPoint encoding
which are "well formed" quad cells. Much like the issue seen with range
queries and BKD's tendency to create exotic splits, the polygon approximation
can fail with these irregular rectangles.
The attached patch changes the following:
* add the original rectCrossesPoly method and uses it for more "precise"
relations required by BKD.
* remove tolerance comparisons from {{GeoRelationUtils.pointInRect}}. This
method should operate independent of the tolerance factor.
* for LatLonPoint BoundingBox queries, ignore false positives/negatives that
are within TOLERANCE rounding error
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836 lon=-9.408821929246187
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30077 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317,
[jira] [Commented] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15111280#comment-15111280
]
Nicholas Knize commented on LUCENE-6956:
Patch has been successfully beast tested and passes on the jenkins failures I
was able to reproduce. I'm unable to reproduce some of the java 9 failures due
to a {{java.util.IllformedLocaleException}} so if there are no objections I'll
commit this fix shortly and get jenkins working on it.
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836 lon=-9.408821929246187
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30077 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29821
>[junit4] 1> lat=86.84681385755539 lon=-8.837449550628662
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30185 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points:
[jira] [Updated] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6956:
---
Attachment: LUCENE-6956.patch
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956.patch, LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836 lon=-9.408821929246187
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30077 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29821
>[junit4] 1> lat=86.84681385755539 lon=-8.837449550628662
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30185 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29929
>[junit4] 1> lat=86.84285902418196 lon=-9.196635894477367
>[junit4]
[jira] [Commented] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15111532#comment-15111532
]
Nicholas Knize commented on LUCENE-6956:
That was my fault, stale change. Reverted and updated the patch.
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956.patch, LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836 lon=-9.408821929246187
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30077 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29821
>[junit4] 1> lat=86.84681385755539 lon=-8.837449550628662
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30185 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29929
>
[jira] [Commented] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15111345#comment-15111345
]
Nicholas Knize commented on LUCENE-6930:
It's related to {{TOLERANCE}} and that {{computeMaxShift}} in this patch is
reused for all query types. So the depth of traversal for distanceQueries may
vary slightly. The effect is that trunk has a handful of false negatives that
this patch has picked up. The tests don't report them as failures because the
deltas are within the {{TOLERANCE}}.
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch, LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15111382#comment-15111382
]
Nicholas Knize commented on LUCENE-6956:
Sure [~thetaphi]. Just tried w/ java 7, 8, and 9. Same exception on all. Looks
like its related to the {{mer_KE}} locale tag.
The exception:
{noformat}
[junit4] 2> Jan 21, 2016 3:57:10 PM
com.carrotsearch.randomizedtesting.RandomizedRunner runSuite
[junit4] 2> SEVERE: Panic: RunListener hook shouldn't throw exceptions.
[junit4] 2> java.lang.NullPointerException
[junit4] 2>at
org.apache.lucene.util.RunListenerPrintReproduceInfo.printDebuggingInformation(RunListenerPrintReproduceInfo.java:132)
[junit4] 2>at
org.apache.lucene.util.RunListenerPrintReproduceInfo.testRunFinished(RunListenerPrintReproduceInfo.java:119)
[junit4] 2>at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:706)
[junit4] 2>at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$200(RandomizedRunner.java:140)
[junit4] 2>at
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:591)
[junit4] 2>
[junit4] ERROR 0.00s | TestGeoPointQuery (suite) <<<
[junit4]> Throwable #1: java.util.IllformedLocaleException: Invalid
subtag: mer_KE [at index 0]
[junit4]>at
__randomizedtesting.SeedInfo.seed([30950A47BB2DFA04]:0)
[junit4]>at
java.util.Locale$Builder.setLanguageTag(Locale.java:2426)
[junit4]>at
org.apache.lucene.util.LuceneTestCase.localeForLanguageTag(LuceneTestCase.java:1530)
[junit4]>at java.lang.Thread.run(Thread.java:745)
[junit4] Completed [1/1 (1!)] in 0.29s, 0 tests, 1 error <<< FAILURES!
{noformat}
reproduce with:
{noformat}
ant test -Dtestcase=TestGeoPointQuery -Dtests.method=testRandomTiny
-Dtests.seed=30950A47BB2DFA04 -Dtests.multiplier=3 -Dtests.slow=true
-Dtests.locale=mer_KE -Dtests.timezone=America/Martinique -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII{noformat}
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1>
[jira] [Commented] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15111530#comment-15111530
]
Nicholas Knize commented on LUCENE-6956:
Correct. I was testing against an old failure in an open issue. New style
locale fixed it. Thx for the help!
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956.patch, LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836 lon=-9.408821929246187
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30077 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29821
>[junit4] 1> lat=86.84681385755539 lon=-8.837449550628662
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30185 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583]
[jira] [Updated] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6930:
---
Attachment: LUCENE-6930.patch
Thanks for the great feedback [~mikemccand] Patch updated with
recommendations.
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch, LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6956) TestBKDTree.testRandomMedium() failure: some hits were wrong
[
https://issues.apache.org/jira/browse/LUCENE-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15111384#comment-15111384
]
Nicholas Knize commented on LUCENE-6956:
got it.. posted my reply 3 mins too late ;) Thanks!
> TestBKDTree.testRandomMedium() failure: some hits were wrong
>
>
> Key: LUCENE-6956
> URL: https://issues.apache.org/jira/browse/LUCENE-6956
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Michael McCandless
> Attachments: LUCENE-6956.patch
>
>
> My Jenkins found a reproducible seed for a failure of
> {{TestBKDTree.testRandomMedium()}} on branch_5x with Java8:
> {noformat}
> [junit4] Suite: org.apache.lucene.bkdtree.TestBKDTree
>[junit4] 1> T1: id=29784 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29528
>[junit4] 1> lat=86.88086835667491 lon=-8.821268286556005
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29801 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29545
>[junit4] 1> lat=86.88149104826152 lon=-9.34366637840867
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=29961 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29705
>[junit4] 1> lat=86.8706679996103 lon=-9.38328042626381
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30015 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29759
>[junit4] 1> lat=86.84762765653431 lon=-9.44802425801754
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30017 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29761
>[junit4] 1> lat=86.8753323610872 lon=-9.091365560889244
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30042 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29786
>[junit4] 1> lat=86.85837233439088 lon=-9.127480667084455
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30061 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29805
>[junit4] 1> lat=86.85876209288836 lon=-9.408821929246187
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30077 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29821
>[junit4] 1> lat=86.84681385755539 lon=-8.837449550628662
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=30185 should match but did not
>[junit4] 1> small=true query=BKDPointInPolygonQuery: field=point:
> Points: [-9.594408497214317, 86.83882305398583] [-9.594408497214317,
> 86.8827043287456] [-8.752231243997812, 86.8827043287456] [-8.752231243997812,
> 86.83882305398583] [-9.594408497214317, 86.83882305398583] docID=29929
>[junit4] 1>
[jira] [Resolved] (LUCENE-6897) Fix maxRadius at pole for GeoPointDistanceQuery
[ https://issues.apache.org/jira/browse/LUCENE-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize resolved LUCENE-6897. Resolution: Resolved Fix Version/s: 5.4 Resolved by LUCENE-6905 > Fix maxRadius at pole for GeoPointDistanceQuery > --- > > Key: LUCENE-6897 > URL: https://issues.apache.org/jira/browse/LUCENE-6897 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 5.4, Trunk >Reporter: Nicholas Knize > Fix For: 5.4 > > > At the moment GeoPointDistanceQuery throws and IllegalArgumentException if > the distance exceeds the maximum radial distance on the earth's surface. At > the pole, however, the radial distance should be no greater than the maximum > meridian distance on the ellipsoid. This issue will correct the maximum > radius check to handle center points at the poles. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles
[
https://issues.apache.org/jira/browse/LUCENE-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize resolved LUCENE-6908.
Resolution: Fixed
> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
>
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch, LUCENE-6908.patch,
> LUCENE-6908.patch, LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of
> GeoPoint*Query as its using the BKD split technique (instead of quad cell
> division) to divide the space on each pass. For "large" distance queries this
> can create a lot of irregular rectangles producing large radial distortion
> error when using the cartesian approximation methods provided by
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian
> approximation methods on irregular rectangles without having to cut over to
> an expensive oblate geometry approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106018#comment-15106018
]
Nicholas Knize commented on LUCENE-6930:
Try again with the new patch. I guess diff didn't like the way I refactored
{{GeoUtils}} and adding another new {{GeoUtils}} class.
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106018#comment-15106018
]
Nicholas Knize edited comment on LUCENE-6930 at 1/19/16 12:19 AM:
--
Try again with the new patch. I guess diff didn't like the way I refactored
{{GeoUtils}} and added another new {{GeoUtils}} class.
was (Author: nknize):
Try again with the new patch. I guess diff didn't like the way I refactored
{{GeoUtils}} and adding another new {{GeoUtils}} class.
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106127#comment-15106127
]
Nicholas Knize commented on LUCENE-6930:
Nice!!! Thanks for that protip! That certainly would have come in handy in this
situation.
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6930:
---
Attachment: LUCENE-6930.patch
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch, LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6930:
---
Attachment: LUCENE-6930.patch
Attached patch adds the following changes:
* Adds a new {{GeoPointTokenStream}} that encodes {{GeoPointField}} type into a
maximum of 5 "prefix only" terms. Full precision post filtering uses DocValues.
* Adds a {{GeoPointTermQuery.TermEncoding}} enum to choose between existing
{{NUMERIC}} encoding or new {{PREFIX}} encoding
* Refactors {{GeoPointTermsEnum}} into a base class with two derived classes:
** {{GeoPointNumericTermsEnum}} - Uses existing {{NumericTokenStream}} logic
** {{GeoPointPrefixTermsEnum}} - Uses new {{GeoPointTokenStream}} logic
* Refactors term encoding logic out of {{GeoUtils}} into a dedicated
{{GeoEncodingUtils}} class
* Adds {{randomTermEncoding}} to {{TestGeoPointQuery}} to randomly test both
encoding approaches
Quick luceneutil benchmarks: 76% reduction in index size, 81% boost in indexing
performance, 19% average boost in query performance.
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6930.patch
>
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6974) TesGeoPointQuery failures: some hits were wrong (should not match but did)
[
https://issues.apache.org/jira/browse/LUCENE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6974:
---
Attachment: LUCENE-6974.patch
Patch to fix simple bug in the horizontal collinear case. This also adds a
short-cut to rectWithinPoly to bail when candidate rectangle crosses the
bounding box.
> TesGeoPointQuery failures: some hits were wrong (should not match but did)
> --
>
> Key: LUCENE-6974
> URL: https://issues.apache.org/jira/browse/LUCENE-6974
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Steve Rowe
> Attachments: LUCENE-6974.patch
>
>
> Reproducible failure from Policeman Jenkins
> [http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15540/]:
> {noformat}
>[junit4] Suite: org.apache.lucene.search.TestGeoPointQuery
>[junit4] 1> T0: id=1 should not match but did
>[junit4] 1> small=true query=GeoPointInPolygonQuery: field=point:
> Points: [4.3475002236664295, -39.484346117824316] [4.3475002236664295,
> -38.95751953125] [5.824887603521347, -38.95751953125] [5.824887603521347,
> -39.484346117824316] [4.3475002236664295, -39.484346117824316] docID=1
>[junit4] 1> lat=-38.94430998712778 lon=4.362290930002928
>[junit4] 1> deleted?=false
>[junit4] 2> JAN 13, 2016 6:53:32 R?
> com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
> uncaughtException
>[junit4] 2> WARNING: Uncaught exception in thread:
> Thread[T0,5,TGRP-TestGeoPointQuery]
>[junit4] 2> java.lang.AssertionError: some hits were wrong
>[junit4] 2> at
> __randomizedtesting.SeedInfo.seed([30950A47BB2DFA04]:0)
>[junit4] 2> at org.junit.Assert.fail(Assert.java:93)
>[junit4] 2> at
> org.apache.lucene.util.BaseGeoPointTestCase$VerifyHits.test(BaseGeoPointTestCase.java:554)
>[junit4] 2> at
> org.apache.lucene.util.BaseGeoPointTestCase$2._run(BaseGeoPointTestCase.java:758)
>[junit4] 2> at
> org.apache.lucene.util.BaseGeoPointTestCase$2.run(BaseGeoPointTestCase.java:625)
>[junit4] 2>
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestGeoPointQuery
> -Dtests.method=testRandomTiny -Dtests.seed=30950A47BB2DFA04
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=mer_KE
> -Dtests.timezone=America/Martinique -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR 0.93s J0 | TestGeoPointQuery.testRandomTiny <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase.verify(BaseGeoPointTestCase.java:772)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase.doTestRandom(BaseGeoPointTestCase.java:411)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase.testRandomTiny(BaseGeoPointTestCase.java:331)
>[junit4]> at java.lang.Thread.run(Thread.java:747)Throwable #2:
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an
> uncaught exception in thread: Thread[id=57, name=T0, state=RUNNABLE,
> group=TGRP-TestGeoPointQuery]
>[junit4]> Caused by: java.lang.AssertionError: some hits were wrong
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([30950A47BB2DFA04]:0)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase$VerifyHits.test(BaseGeoPointTestCase.java:554)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase$2._run(BaseGeoPointTestCase.java:758)
>[junit4]> at
> org.apache.lucene.util.BaseGeoPointTestCase$2.run(BaseGeoPointTestCase.java:625)
>[junit4] IGNOR/A 0.01s J0 | TestGeoPointQuery.testRandomBig
>[junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
>[junit4] IGNOR/A 0.00s J0 | TestGeoPointQuery.testAllLatEqual
>[junit4]> Assumption #1: GeoPoint*Query is too slow otherwise
>[junit4] 1> T1: id=15902 should not match but did
>[junit4] 1> small=true query=GeoPointInPolygonQuery: field=point:
> Points: [4.3475002236664295, -39.484346117824316] [4.3475002236664295,
> -38.95751953125] [5.824887603521347, -38.95751953125] [5.824887603521347,
> -39.484346117824316] [4.3475002236664295, -39.484346117824316] docID=714
>[junit4] 1> lat=-38.95061678253114 lon=5.752138886600733
>[junit4] 1> deleted?=false
>[junit4] 1> T1: id=16650 should not match but did
>[junit4] 1> small=true query=GeoPointInPolygonQuery: field=point:
> Points: [4.3475002236664295, -39.484346117824316] [4.3475002236664295,
> -38.95751953125] [5.824887603521347, -38.95751953125] [5.824887603521347,
> -39.484346117824316] [4.3475002236664295, -39.484346117824316] docID=739
>[junit4] 1>
[jira] [Resolved] (LUCENE-6951) GeoPointInPolygonQuery can be improved
[
https://issues.apache.org/jira/browse/LUCENE-6951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize resolved LUCENE-6951.
Resolution: Resolved
> GeoPointInPolygonQuery can be improved
> --
>
> Key: LUCENE-6951
> URL: https://issues.apache.org/jira/browse/LUCENE-6951
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6951.patch
>
>
> {{GeoRelationutils}} uses a basic algebraic approach for computing if (and
> where) a rectangle crosses a polygon by checking the line segments of both
> the polygon and rectangle. The current suboptimal line crossing approach can
> be greatly improved by exploiting the orientation of the lines and endpoints.
> If the endpoints of one line are on different "sides" of the line segment
> then the two may cross.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6951) GeoPointInPolygonQuery can be improved
[
https://issues.apache.org/jira/browse/LUCENE-6951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6951:
---
Attachment: LUCENE-6951.patch
Patch includes:
* Updated line crossing algorithm to use point orientation
* Updated GPTQ ConstantScoreWrapper MultiValue check to add doc when 1 point is
found within the poly - avoids superflous pip checking if the doc is already a
match
* Tests indicate up to 45% boost in GeoPointInPolygonQuery performance
> GeoPointInPolygonQuery can be improved
> --
>
> Key: LUCENE-6951
> URL: https://issues.apache.org/jira/browse/LUCENE-6951
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6951.patch
>
>
> {{GeoRelationutils}} uses a basic algebraic approach for computing if (and
> where) a rectangle crosses a polygon by checking the line segments of both
> the polygon and rectangle. The current suboptimal line crossing approach can
> be greatly improved by exploiting the orientation of the lines and endpoints.
> If the endpoints of one line are on different "sides" of the line segment
> then the two may cross.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles
[
https://issues.apache.org/jira/browse/LUCENE-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6908:
---
Attachment: LUCENE-6908.patch
Updated patch includes:
* space segmentation for irregular rectangles at the poles
* utility method for computing bearing from two given lat/lon points
* explicitly tested against failed seeds and nightly beasting
* updated javadocs
> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
>
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch, LUCENE-6908.patch,
> LUCENE-6908.patch, LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of
> GeoPoint*Query as its using the BKD split technique (instead of quad cell
> division) to divide the space on each pass. For "large" distance queries this
> can create a lot of irregular rectangles producing large radial distortion
> error when using the cartesian approximation methods provided by
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian
> approximation methods on irregular rectangles without having to cut over to
> an expensive oblate geometry approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6951) GeoPointInPolygonQuery can be improved
Nicholas Knize created LUCENE-6951:
--
Summary: GeoPointInPolygonQuery can be improved
Key: LUCENE-6951
URL: https://issues.apache.org/jira/browse/LUCENE-6951
Project: Lucene - Core
Issue Type: Improvement
Reporter: Nicholas Knize
{{GeoRelationutils}} uses a basic algebraic approach for computing if (and
where) a rectangle crosses a polygon by checking the line segments of both the
polygon and rectangle. The current suboptimal line crossing approach can be
greatly improved by exploiting the orientation of the lines and endpoints. If
the endpoints of one line are on different "sides" of the line segment then
the two may cross.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles
[
https://issues.apache.org/jira/browse/LUCENE-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15068336#comment-15068336
]
Nicholas Knize commented on LUCENE-6908:
++ Thanks [~steve_rowe] There's a geometric approximation in the within that's
a bit too lenient for BKD. These seeds have been super helpful in regression
testing a fix. Should have a patch shortly. Sorry for the noise!
> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
>
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch, LUCENE-6908.patch,
> LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of
> GeoPoint*Query as its using the BKD split technique (instead of quad cell
> division) to divide the space on each pass. For "large" distance queries this
> can create a lot of irregular rectangles producing large radial distortion
> error when using the cartesian approximation methods provided by
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian
> approximation methods on irregular rectangles without having to cut over to
> an expensive oblate geometry approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6935) Improve random testing for GeoPointPointInPolygonQuery and DimensionalPointInPolygonQuery
Nicholas Knize created LUCENE-6935:
--
Summary: Improve random testing for GeoPointPointInPolygonQuery
and DimensionalPointInPolygonQuery
Key: LUCENE-6935
URL: https://issues.apache.org/jira/browse/LUCENE-6935
Project: Lucene - Core
Issue Type: Test
Reporter: Nicholas Knize
Priority: Minor
Currently {{TestGeoPointQuery}} and {{TestDimensionalQueries}} only create
bounding box polygons to test {{PointInPolygonQuery}}. This provides coverage
for testing basic functionality but lacks critical testing with true random
shapes. Random shape generation needs to be added to {{BaseGeoPointTestCase}}
and used in {{newPolygonQuery}} for GeoPoint and DimensionalQuery testing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6930) Decouple GeoPointField from NumericType
Nicholas Knize created LUCENE-6930:
--
Summary: Decouple GeoPointField from NumericType
Key: LUCENE-6930
URL: https://issues.apache.org/jira/browse/LUCENE-6930
Project: Lucene - Core
Issue Type: Improvement
Reporter: Nicholas Knize
{{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
terms for a GeoPoint using the precision step defined in {{GeoPointField}}. At
search time {{GeoPointTermsEnum}} recurses to a max precision that is computed
by the Query parameters. This max precision is never the full precision, so
creating and indexing the full precision terms is useless and wasteful (it was
always a side effect of just using indexing logic from the Numeric type).
Furthermore, since the numerical logic always stored high precision terms
first, the recursion in {{GeoPointTermsEnum}} required transient memory for
storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}} and
reversing the term order (such that lower resolution terms are first), the
GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
PrefixTerms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6930) Decouple GeoPointField from NumericType
[
https://issues.apache.org/jira/browse/LUCENE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6930:
---
Description:
{{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
terms for a GeoPoint using the precision step defined in {{GeoPointField}}. At
search time {{GeoPointTermsEnum}} recurses to a max precision that is computed
by the Query parameters. This max precision is never the full precision, so
creating and indexing the full precision terms is useless and wasteful (it was
always a side effect of just using indexing logic from the Numeric type).
Furthermore, since the numerical logic always stored high precision terms
first, the recursion in {{GeoPointTermsEnum}} required transient memory for
storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}} and
reversing the term order (such that lower resolution terms are first), the
GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
PrefixTerms. This will be done in a separate issue.
was:
{{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
terms for a GeoPoint using the precision step defined in {{GeoPointField}}. At
search time {{GeoPointTermsEnum}} recurses to a max precision that is computed
by the Query parameters. This max precision is never the full precision, so
creating and indexing the full precision terms is useless and wasteful (it was
always a side effect of just using indexing logic from the Numeric type).
Furthermore, since the numerical logic always stored high precision terms
first, the recursion in {{GeoPointTermsEnum}} required transient memory for
storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}} and
reversing the term order (such that lower resolution terms are first), the
GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
PrefixTerms.
> Decouple GeoPointField from NumericType
> ---
>
> Key: LUCENE-6930
> URL: https://issues.apache.org/jira/browse/LUCENE-6930
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>
> {{GeoPointField}} currently relies on {{NumericTokenStream}} to create prefix
> terms for a GeoPoint using the precision step defined in {{GeoPointField}}.
> At search time {{GeoPointTermsEnum}} recurses to a max precision that is
> computed by the Query parameters. This max precision is never the full
> precision, so creating and indexing the full precision terms is useless and
> wasteful (it was always a side effect of just using indexing logic from the
> Numeric type).
> Furthermore, since the numerical logic always stored high precision terms
> first, the recursion in {{GeoPointTermsEnum}} required transient memory for
> storing ranges. By moving the trie logic to its own {{GeoPointTokenStream}}
> and reversing the term order (such that lower resolution terms are first),
> the GeoPointTermsEnum can naturally traverse, enabling on-demand creation of
> PrefixTerms. This will be done in a separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles
[
https://issues.apache.org/jira/browse/LUCENE-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15045752#comment-15045752
]
Nicholas Knize commented on LUCENE-6908:
Thanks [~mikemccand]! I plan to add the benchmark to luceneutil unless you
think there's a better place for it? Going to commit shortly.
> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
>
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch, LUCENE-6908.patch,
> LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of
> GeoPoint*Query as its using the BKD split technique (instead of quad cell
> division) to divide the space on each pass. For "large" distance queries this
> can create a lot of irregular rectangles producing large radial distortion
> error when using the cartesian approximation methods provided by
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian
> approximation methods on irregular rectangles without having to cut over to
> an expensive oblate geometry approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles
[
https://issues.apache.org/jira/browse/LUCENE-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6908:
---
Attachment: LUCENE-6908.patch
Thanks [~mikemccand]! Fixed the patch to include GeoRelationUtils and changes
to SloppyMath.
> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
>
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch, LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of
> GeoPoint*Query as its using the BKD split technique (instead of quad cell
> division) to divide the space on each pass. For "large" distance queries this
> can create a lot of irregular rectangles producing large radial distortion
> error when using the cartesian approximation methods provided by
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian
> approximation methods on irregular rectangles without having to cut over to
> an expensive oblate geometry approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles
[
https://issues.apache.org/jira/browse/LUCENE-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6908:
---
Attachment: LUCENE-6908.patch
Thanks [~mikemccand]. In {{isClosestPointOnRectWithinRange}} it was still using
{{SloppyMath.haversin}} where it should have been using the Sinnott haversine.
Looks like it was caused by a premature diff from my benchmark workspace.
A quick interesting benchmark re: distance methods. Using 2M iterations I
benchmarked average computation time, average spatial error, and maximum
spatial error between 5 different geospatial distance methods:
* Vincenty
* Karney - Modified Vincenty that uses Newton's series expansion to fix
problems w/ antipodal points
* HaverECF - Same as {{SloppyMath.haversin}} but uses ECEF to accurately
compute semi-major axis at the given latitude.
* Sinnott's Haversine - Implementation from the original haversine publicatoin
* SloppyMath
|| Distance Method || Avg Computation (ns) || Avg Error (%) || Max Error (%) ||
| Vincenty | 1286.5529689998828 | 8.4561794778802E-11 | 7.2565793775802E-10 |
| Karney | 31770.47920646 | 8.4561794778802E-11 | 7.2565793775802E-10 |
| HaverECF | 717.113985152 | 0.18409042301798453 | 0.6681179192384695 |
| SloppyMath.haverin | 159.309524995 | 0.22594450803222424 |
0.6539314586426048 |
| Sinnott Haversine | 146.8123669738 | 0.18158435835918563 |
0.4931242857748373 |
I need to run some better descriptive statistics before drawing any
conclusions. At the moment, the discrepancy between {{Sloppymath.haversin}} and
Sinnott's implementation is consistent with the error described in the original
publication (which is where the tolerance of 0.5% originated).
More to come
> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
>
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch, LUCENE-6908.patch,
> LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of
> GeoPoint*Query as its using the BKD split technique (instead of quad cell
> division) to divide the space on each pass. For "large" distance queries this
> can create a lot of irregular rectangles producing large radial distortion
> error when using the cartesian approximation methods provided by
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian
> approximation methods on irregular rectangles without having to cut over to
> an expensive oblate geometry approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles
[
https://issues.apache.org/jira/browse/LUCENE-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15036890#comment-15036890
]
Nicholas Knize edited comment on LUCENE-6908 at 12/2/15 11:48 PM:
--
Thanks [~mikemccand]. In {{isClosestPointOnRectWithinRange}} it was still using
{{SloppyMath.haversin}} where it should have been using the Sinnott haversine.
Looks like it was caused by a premature diff from my benchmark workspace.
A quick interesting benchmark re: distance methods. Using 2M iterations I
benchmarked average computation time, average spatial error, and maximum
spatial error between 5 different geospatial distance methods:
* Vincenty
* Karney - Modified Vincenty that uses Newton's series expansion to fix
problems w/ antipodal points
* HaverECF - Same as {{SloppyMath.haversin}} but uses ECEF to accurately
compute semi-major axis at the given latitude.
* Sinnott's Haversine - Implementation from the original haversine publication
* SloppyMath.haversin
|| Distance Method || Avg Computation (ns) || Avg Error (%) || Max Error (%) ||
| Vincenty | 1286.5529689998828 | 8.4561794778802E-11 | 7.2565793775802E-10 |
| Karney | 31770.47920646 | 8.4561794778802E-11 | 7.2565793775802E-10 |
| HaverECF | 717.113985152 | 0.18409042301798453 | 0.6681179192384695 |
| SloppyMath.haverin | 159.309524995 | 0.22594450803222424 |
0.6539314586426048 |
| Sinnott Haversine | 146.8123669738 | 0.18158435835918563 |
0.4931242857748373 |
I need to run some better descriptive statistics before drawing any
conclusions. At the moment, the discrepancy between {{Sloppymath.haversin}} and
Sinnott's implementation is consistent with the error described in the original
publication (which is where the tolerance of 0.5% originated).
More to come
was (Author: nknize):
Thanks [~mikemccand]. In {{isClosestPointOnRectWithinRange}} it was still using
{{SloppyMath.haversin}} where it should have been using the Sinnott haversine.
Looks like it was caused by a premature diff from my benchmark workspace.
A quick interesting benchmark re: distance methods. Using 2M iterations I
benchmarked average computation time, average spatial error, and maximum
spatial error between 5 different geospatial distance methods:
* Vincenty
* Karney - Modified Vincenty that uses Newton's series expansion to fix
problems w/ antipodal points
* HaverECF - Same as {{SloppyMath.haversin}} but uses ECEF to accurately
compute semi-major axis at the given latitude.
* Sinnott's Haversine - Implementation from the original haversine publicatoin
* SloppyMath
|| Distance Method || Avg Computation (ns) || Avg Error (%) || Max Error (%) ||
| Vincenty | 1286.5529689998828 | 8.4561794778802E-11 | 7.2565793775802E-10 |
| Karney | 31770.47920646 | 8.4561794778802E-11 | 7.2565793775802E-10 |
| HaverECF | 717.113985152 | 0.18409042301798453 | 0.6681179192384695 |
| SloppyMath.haverin | 159.309524995 | 0.22594450803222424 |
0.6539314586426048 |
| Sinnott Haversine | 146.8123669738 | 0.18158435835918563 |
0.4931242857748373 |
I need to run some better descriptive statistics before drawing any
conclusions. At the moment, the discrepancy between {{Sloppymath.haversin}} and
Sinnott's implementation is consistent with the error described in the original
publication (which is where the tolerance of 0.5% originated).
More to come
> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
>
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch, LUCENE-6908.patch,
> LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of
> GeoPoint*Query as its using the BKD split technique (instead of quad cell
> division) to divide the space on each pass. For "large" distance queries this
> can create a lot of irregular rectangles producing large radial distortion
> error when using the cartesian approximation methods provided by
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian
> approximation methods on irregular rectangles without having to cut over to
> an expensive oblate geometry approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles
[
https://issues.apache.org/jira/browse/LUCENE-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6908:
---
Attachment: LUCENE-6908.patch
Updated patch includes the following:
* Pushes down approximation fixes to the Geo utility APIs
* Refactors relation logic from {{GeoUtils}} into separate {{GeoRelationUtils}}
class
* Improves GeoDistance pole crossing by re-projecting to Earth Centered Earth
Fixed (ECEF)
* Adds {{approx}} flag to bypass advanced relation logic (useful for
{{GeoPointField}} since approximations are already handled at the grid level
* Removes {{AwaitsFix}} from {{TestGeoUtils.testGeoRelations}}
Next step is to test w/ BKD integration.
> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
>
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of
> GeoPoint*Query as its using the BKD split technique (instead of quad cell
> division) to divide the space on each pass. For "large" distance queries this
> can create a lot of irregular rectangles producing large radial distortion
> error when using the cartesian approximation methods provided by
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian
> approximation methods on irregular rectangles without having to cut over to
> an expensive oblate geometry approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles
[
https://issues.apache.org/jira/browse/LUCENE-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6908:
---
Description: The {{.testGeoRelations}} method doesn't exactly test the
behavior of GeoPoint*Query as its using the BKD split technique (instead of
quad cell division) to divide the space on each pass. For "large" distance
queries this can create a lot of irregular rectangles producing large radial
distortion error when using the cartesian approximation methods provided by
{{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian
approximation methods on irregular rectangles without having to cut over to an
expensive oblate geometry approach. (was: The {{.testGeoRelations}} method
doesn't exactly test the behavior of GeoPoint*Query as its using the BKD split
technique (instead of quad cell division) to divide the space on each pass. For
"large" distance queries this can create a lot of irregular rectangles
producing large radial distortion error when using the cartesian approximation
methods provided by {{GeoUtils}}. This issue will better divide the space
enabling use of the fast cartesian approximation methods instead of having to
convert to an expensive oblate geometry approach.)
> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
>
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of
> GeoPoint*Query as its using the BKD split technique (instead of quad cell
> division) to divide the space on each pass. For "large" distance queries this
> can create a lot of irregular rectangles producing large radial distortion
> error when using the cartesian approximation methods provided by
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian
> approximation methods on irregular rectangles without having to cut over to
> an expensive oblate geometry approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6905:
---
Issue Type: Bug (was: Improvement)
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15027001#comment-15027001
]
Nicholas Knize commented on LUCENE-6905:
thanks [~mikemccand]. I went ahead and added the jenkins failure as an explicit
test. I'll commit shortly.
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch,
> LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize resolved LUCENE-6905.
Resolution: Fixed
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch,
> LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6905:
---
Attachment: LUCENE-6905.patch
Updated patch:
* moves unwrapping into {{GeoPointDistanceQuery}}
* removes 7% tolerance - will be addressed by LUCENE-6908
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6905:
---
Attachment: LUCENE-6905.patch
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch,
> LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6905:
---
Attachment: (was: LUCENE-6905.patch)
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6905:
---
Attachment: LUCENE-6905.patch
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch,
> LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022849#comment-15022849
]
Nicholas Knize commented on LUCENE-6905:
bq. For the record, MBR in geo speak means "minimum bounding rectangle"
yesyes! Updated the comment to spell out the acronym.
bq. We should fix this test to "behave" like the query does: rewrite up front
into the two halves of the MBR
Are you referring to {{TestGeoUtils.testGeoRelations}}? {{unwrapLon}} is only
called iff the bbox crosses the dateline. Which behaves like the
{{GeoPointDistanceQueryImpl}} does.
Also, after digging a little bit more I've decided to move the
TestGeoUtils.testGeoRelations fixes to LUCENE-6846 (patch coming next). The
{{.testGeoRelations}} method doesn't exactly test the behavior of
GeoPoint*Query as its using the BKD split technique (instead of quad cell
division) to divide the space on each pass. For "large" distance queries this
can create a lot of irregular rectangles producing large radial distortion
error when using the cartesian approximation methods provided by {{GeoUtils}}.
I have a "rewrite" fix that I'll attach to LUCENE-6846 that further divides the
space allowing us to use the fast cartesian approximation methods instead of
converting to an expensive oblate geometry approach.
bq. Can we now remove the true in {{TestGeoUtils.testGeoRelations}}
Also doing this in LUCENE-6846.
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022854#comment-15022854
]
Nicholas Knize commented on LUCENE-6905:
Jenkins did catch this, eventually. Looking at the randomization it looks like
the probability of producing this case is quite low. The LUCENE-6846 patch will
re-enable large distances and {{testGeoRelations}} which will produce more of
these edge cases.
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6905:
---
Attachment: LUCENE-6905.patch
New patch to focus on unwrapping only.
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6905:
---
Attachment: LUCENE-6905.patch
Updated patch to correct path
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch,
> LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6905:
---
Attachment: (was: LUCENE-6905.patch)
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles
Nicholas Knize created LUCENE-6908:
--
Summary: TestGeoUtils.testGeoRelations is buggy with irregular
rectangles
Key: LUCENE-6908
URL: https://issues.apache.org/jira/browse/LUCENE-6908
Project: Lucene - Core
Issue Type: Bug
Reporter: Nicholas Knize
The {{.testGeoRelations}} method doesn't exactly test the behavior of
GeoPoint*Query as its using the BKD split technique (instead of quad cell
division) to divide the space on each pass. For "large" distance queries this
can create a lot of irregular rectangles producing large radial distortion
error when using the cartesian approximation methods provided by {{GeoUtils}}.
This issue will better divide the space enabling use of the fast cartesian
approximation methods instead of having to convert to an expensive oblate
geometry approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022849#comment-15022849
]
Nicholas Knize edited comment on LUCENE-6905 at 11/23/15 9:08 PM:
--
bq. For the record, MBR in geo speak means "minimum bounding rectangle"
yesyes! Updated the comment to spell out the acronym.
bq. We should fix this test to "behave" like the query does: rewrite up front
into the two halves of the MBR
Are you referring to {{TestGeoUtils.testGeoRelations}}? {{unwrapLon}} is only
called iff the bbox crosses the dateline. Which behaves like the
{{GeoPointDistanceQueryImpl}} does.
Also, after digging a little bit more I've decided to move the
TestGeoUtils.testGeoRelations fixes to new issue, LUCENE-6908 (patch coming
next). The {{.testGeoRelations}} method doesn't exactly test the behavior of
GeoPoint*Query as its using the BKD split technique (instead of quad cell
division) to divide the space on each pass. For "large" distance queries this
can create a lot of irregular rectangles producing large radial distortion
error when using the cartesian approximation methods provided by {{GeoUtils}}.
I have a "rewrite" fix that I'll attach to LUCENE-6908 that further divides the
space allowing us to use the fast cartesian approximation methods instead of
converting to an expensive oblate geometry approach.
bq. Can we now remove the true in {{TestGeoUtils.testGeoRelations}}
Also doing this in LUCENE-6908.
was (Author: nknize):
bq. For the record, MBR in geo speak means "minimum bounding rectangle"
yesyes! Updated the comment to spell out the acronym.
bq. We should fix this test to "behave" like the query does: rewrite up front
into the two halves of the MBR
Are you referring to {{TestGeoUtils.testGeoRelations}}? {{unwrapLon}} is only
called iff the bbox crosses the dateline. Which behaves like the
{{GeoPointDistanceQueryImpl}} does.
Also, after digging a little bit more I've decided to move the
TestGeoUtils.testGeoRelations fixes to LUCENE-6846 (patch coming next). The
{{.testGeoRelations}} method doesn't exactly test the behavior of
GeoPoint*Query as its using the BKD split technique (instead of quad cell
division) to divide the space on each pass. For "large" distance queries this
can create a lot of irregular rectangles producing large radial distortion
error when using the cartesian approximation methods provided by {{GeoUtils}}.
I have a "rewrite" fix that I'll attach to LUCENE-6846 that further divides the
space allowing us to use the fast cartesian approximation methods instead of
converting to an expensive oblate geometry approach.
bq. Can we now remove the true in {{TestGeoUtils.testGeoRelations}}
Also doing this in LUCENE-6846.
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022854#comment-15022854
]
Nicholas Knize edited comment on LUCENE-6905 at 11/23/15 9:08 PM:
--
Jenkins did catch this, eventually. Looking at the randomization it looks like
the probability of producing this case is quite low. The LUCENE-6908 patch will
re-enable large distances and {{testGeoRelations}} which will produce more of
these edge cases.
was (Author: nknize):
Jenkins did catch this, eventually. Looking at the randomization it looks like
the probability of producing this case is quite low. The LUCENE-6846 patch will
re-enable large distances and {{testGeoRelations}} which will produce more of
these edge cases.
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles
[
https://issues.apache.org/jira/browse/LUCENE-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6908:
---
Attachment: LUCENE-6908.patch
Patch includes:
* update {{testGeoRelations}} to rewrite longitudinal span queries into 4
slices to reduce radial distortion error in {{GeoUtils}} cartesian
approximation methods - this would be needed for BKD queries due to the nature
of the split algorithm for large distance queries.
* Incorporate distance error on {{isClosestPointOnRectWIthinRange}} for better
approximation within BKD.
* added comments and javadocs.
> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
>
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of
> GeoPoint*Query as its using the BKD split technique (instead of quad cell
> division) to divide the space on each pass. For "large" distance queries this
> can create a lot of irregular rectangles producing large radial distortion
> error when using the cartesian approximation methods provided by
> {{GeoUtils}}. This issue will better divide the space enabling use of the
> fast cartesian approximation methods instead of having to convert to an
> expensive oblate geometry approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6904) Rewrite max bound GeoPointInBBoxQuery to FieldValueQuery
[ https://issues.apache.org/jira/browse/LUCENE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6904: --- Fix Version/s: Trunk > Rewrite max bound GeoPointInBBoxQuery to FieldValueQuery > > > Key: LUCENE-6904 > URL: https://issues.apache.org/jira/browse/LUCENE-6904 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: Trunk, 5.4 >Reporter: Nicholas Knize >Priority: Minor > Fix For: Trunk > > Attachments: LUCENE-6904.patch, LUCENE-6904.patch > > > This simple improvement rewrites a GeoPointInBBoxQuery to a FieldValueQuery > when the min/max lon/lat (or x/y) values are set to their limits (e.g., -180, > 180, -90, 90). This bypasses all unnecessary GeoPointTermsEnum logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6904) Rewrite max bound GeoPointInBBoxQuery to FieldValueQuery
[ https://issues.apache.org/jira/browse/LUCENE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6904: --- Fix Version/s: 5.4 > Rewrite max bound GeoPointInBBoxQuery to FieldValueQuery > > > Key: LUCENE-6904 > URL: https://issues.apache.org/jira/browse/LUCENE-6904 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: Trunk, 5.4 >Reporter: Nicholas Knize >Priority: Minor > Fix For: Trunk, 5.4 > > Attachments: LUCENE-6904.patch, LUCENE-6904.patch > > > This simple improvement rewrites a GeoPointInBBoxQuery to a FieldValueQuery > when the min/max lon/lat (or x/y) values are set to their limits (e.g., -180, > 180, -90, 90). This bypasses all unnecessary GeoPointTermsEnum logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6904) Rewrite max bound GeoPointInBBoxQuery to FieldValueQuery
[ https://issues.apache.org/jira/browse/LUCENE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize resolved LUCENE-6904. Resolution: Fixed > Rewrite max bound GeoPointInBBoxQuery to FieldValueQuery > > > Key: LUCENE-6904 > URL: https://issues.apache.org/jira/browse/LUCENE-6904 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: Trunk, 5.4 >Reporter: Nicholas Knize >Priority: Minor > Fix For: Trunk, 5.4 > > Attachments: LUCENE-6904.patch, LUCENE-6904.patch > > > This simple improvement rewrites a GeoPointInBBoxQuery to a FieldValueQuery > when the min/max lon/lat (or x/y) values are set to their limits (e.g., -180, > 180, -90, 90). This bypasses all unnecessary GeoPointTermsEnum logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022960#comment-15022960
]
Nicholas Knize edited comment on LUCENE-6905 at 11/23/15 9:45 PM:
--
Updated patch to correct path and addresses review comments.
was (Author: nknize):
Updated patch to correct path
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6905:
---
Description: GeoPointDistanceQuery handles dateline crossing by splitting
the Minimum Bounding Rectangle (MBR) into east/west ranges and rewriting to a
Boolean SHOULD. PostFiltering is accomplished by calculating the distance from
the center point to the candidate point field. Unfortunately the center point
is wrapped such that calculating the closest point on the "circle" from an
eastern point to a western MBR provides incorrect results thus causing false
negatives in the range creation. This was caught by a jenkins failure and
reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
(was: GeoPointDistanceQuery handles dateline crossing by splitting the MBR into
east/west ranges and rewriting to a Boolean SHOULD. PostFiltering is
accomplished by calculating the distance from the center point to the candidate
point field. Unfortunately the center point is wrapped such that calculating
the distance from a eastern point to a western MBR provides incorrect results.)
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6904) Rewrite max bound GeoPointInBBoxQuery to MatchAllDocsQuery
[ https://issues.apache.org/jira/browse/LUCENE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6904: --- Attachment: LUCENE-6904.patch Simple change to rewrite GeoPointInBBoxQuery as a MatchAllDocsQuery when the maximum lon/lat bounds are specified. Updated tests included. > Rewrite max bound GeoPointInBBoxQuery to MatchAllDocsQuery > -- > > Key: LUCENE-6904 > URL: https://issues.apache.org/jira/browse/LUCENE-6904 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: Trunk, 5.4 >Reporter: Nicholas Knize >Priority: Minor > Attachments: LUCENE-6904.patch > > > This simple improvement rewrites a GeoPointInBBoxQuery to a MatchAllDocsQuery > when the min/max lon/lat (or x/y) values are set to their limits (e.g., -180, > 180, -90, 90). This bypasses all unnecessary GeoPointTermsEnum logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6904) Rewrite max bound GeoPointInBBoxQuery to MatchAllDocsQuery
Nicholas Knize created LUCENE-6904: -- Summary: Rewrite max bound GeoPointInBBoxQuery to MatchAllDocsQuery Key: LUCENE-6904 URL: https://issues.apache.org/jira/browse/LUCENE-6904 Project: Lucene - Core Issue Type: Improvement Affects Versions: Trunk, 5.4 Reporter: Nicholas Knize Priority: Minor This simple improvement rewrites a GeoPointInBBoxQuery to a MatchAllDocsQuery when the min/max lon/lat (or x/y) values are set to their limits (e.g., -180, 180, -90, 90). This bypasses all unnecessary GeoPointTermsEnum logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[ https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6905: --- Attachment: LUCENE-6905.patch Simple patch that unwraps the center longitude such that distance is correctly computed. Also corrects maxRadialDistance for center location at the poles. This is fixes build failure #14669 and passes a 200 iteration beast test.. > GeoPointDistanceQuery using wrapped lon for dateline crossing query > --- > > Key: LUCENE-6905 > URL: https://issues.apache.org/jira/browse/LUCENE-6905 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Nicholas Knize > Fix For: Trunk, 6.0, 5.4 > > Attachments: LUCENE-6905.patch > > > GeoPointDistanceQuery handles dateline crossing by splitting the MBR into > east/west ranges and rewriting to a Boolean SHOULD. PostFiltering is > accomplished by calculating the distance from the center point to the > candidate point field. Unfortunately the center point is wrapped such that > calculating the distance from a eastern point to a western MBR provides > incorrect results. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6904) Rewrite max bound GeoPointInBBoxQuery to MatchAllDocsQuery
[ https://issues.apache.org/jira/browse/LUCENE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014288#comment-15014288 ] Nicholas Knize commented on LUCENE-6904: /facepalm Just keeping you honest! :) New patch added. > Rewrite max bound GeoPointInBBoxQuery to MatchAllDocsQuery > -- > > Key: LUCENE-6904 > URL: https://issues.apache.org/jira/browse/LUCENE-6904 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: Trunk, 5.4 >Reporter: Nicholas Knize >Priority: Minor > Attachments: LUCENE-6904.patch, LUCENE-6904.patch > > > This simple improvement rewrites a GeoPointInBBoxQuery to a MatchAllDocsQuery > when the min/max lon/lat (or x/y) values are set to their limits (e.g., -180, > 180, -90, 90). This bypasses all unnecessary GeoPointTermsEnum logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6904) Rewrite max bound GeoPointInBBoxQuery to MatchAllDocsQuery
[ https://issues.apache.org/jira/browse/LUCENE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6904: --- Attachment: LUCENE-6904.patch Switching to FieldValueQuery. > Rewrite max bound GeoPointInBBoxQuery to MatchAllDocsQuery > -- > > Key: LUCENE-6904 > URL: https://issues.apache.org/jira/browse/LUCENE-6904 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: Trunk, 5.4 >Reporter: Nicholas Knize >Priority: Minor > Attachments: LUCENE-6904.patch, LUCENE-6904.patch > > > This simple improvement rewrites a GeoPointInBBoxQuery to a MatchAllDocsQuery > when the min/max lon/lat (or x/y) values are set to their limits (e.g., -180, > 180, -90, 90). This bypasses all unnecessary GeoPointTermsEnum logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6904) Rewrite max bound GeoPointInBBoxQuery to FieldValueQuery
[ https://issues.apache.org/jira/browse/LUCENE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6904: --- Description: This simple improvement rewrites a GeoPointInBBoxQuery to a FieldValueQuery when the min/max lon/lat (or x/y) values are set to their limits (e.g., -180, 180, -90, 90). This bypasses all unnecessary GeoPointTermsEnum logic. (was: This simple improvement rewrites a GeoPointInBBoxQuery to a MatchAllDocsQuery when the min/max lon/lat (or x/y) values are set to their limits (e.g., -180, 180, -90, 90). This bypasses all unnecessary GeoPointTermsEnum logic.) > Rewrite max bound GeoPointInBBoxQuery to FieldValueQuery > > > Key: LUCENE-6904 > URL: https://issues.apache.org/jira/browse/LUCENE-6904 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: Trunk, 5.4 >Reporter: Nicholas Knize >Priority: Minor > Attachments: LUCENE-6904.patch, LUCENE-6904.patch > > > This simple improvement rewrites a GeoPointInBBoxQuery to a FieldValueQuery > when the min/max lon/lat (or x/y) values are set to their limits (e.g., -180, > 180, -90, 90). This bypasses all unnecessary GeoPointTermsEnum logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6904) Rewrite max bound GeoPointInBBoxQuery to FieldValueQuery
[ https://issues.apache.org/jira/browse/LUCENE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6904: --- Summary: Rewrite max bound GeoPointInBBoxQuery to FieldValueQuery (was: Rewrite max bound GeoPointInBBoxQuery to MatchAllDocsQuery) > Rewrite max bound GeoPointInBBoxQuery to FieldValueQuery > > > Key: LUCENE-6904 > URL: https://issues.apache.org/jira/browse/LUCENE-6904 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: Trunk, 5.4 >Reporter: Nicholas Knize >Priority: Minor > Attachments: LUCENE-6904.patch, LUCENE-6904.patch > > > This simple improvement rewrites a GeoPointInBBoxQuery to a MatchAllDocsQuery > when the min/max lon/lat (or x/y) values are set to their limits (e.g., -180, > 180, -90, 90). This bypasses all unnecessary GeoPointTermsEnum logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
Nicholas Knize created LUCENE-6905: -- Summary: GeoPointDistanceQuery using wrapped lon for dateline crossing query Key: LUCENE-6905 URL: https://issues.apache.org/jira/browse/LUCENE-6905 Project: Lucene - Core Issue Type: Improvement Reporter: Nicholas Knize Fix For: Trunk, 6.0, 5.4 GeoPointDistanceQuery handles dateline crossing by splitting the MBR into east/west ranges and rewriting to a Boolean SHOULD. PostFiltering is accomplished by calculating the distance from the center point to the candidate point field. Unfortunately the center point is wrapped such that calculating the distance from a eastern point to a western MBR provides incorrect results. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[ https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014762#comment-15014762 ] Nicholas Knize edited comment on LUCENE-6905 at 11/20/15 5:04 AM: -- Simple patch that unwraps the center longitude such that distance is correctly computed. Also corrects maxRadialDistance for center location at the poles. This fixes build failure #14669 and passes a 200 iteration beast test.. was (Author: nknize): Simple patch that unwraps the center longitude such that distance is correctly computed. Also corrects maxRadialDistance for center location at the poles. This is fixes build failure #14669 and passes a 200 iteration beast test.. > GeoPointDistanceQuery using wrapped lon for dateline crossing query > --- > > Key: LUCENE-6905 > URL: https://issues.apache.org/jira/browse/LUCENE-6905 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Nicholas Knize > Fix For: Trunk, 6.0, 5.4 > > Attachments: LUCENE-6905.patch, LUCENE-6905.patch > > > GeoPointDistanceQuery handles dateline crossing by splitting the MBR into > east/west ranges and rewriting to a Boolean SHOULD. PostFiltering is > accomplished by calculating the distance from the center point to the > candidate point field. Unfortunately the center point is wrapped such that > calculating the distance from a eastern point to a western MBR provides > incorrect results. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6905:
---
Attachment: LUCENE-6905.patch
Updated patch that moves unwrapping to GeoUtils.
{{TestGeoUtils.testGeoRelations}} is also reenabled and updated for BKD
verification. /cc [~mikemccand]
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the MBR into
> east/west ranges and rewriting to a Boolean SHOULD. PostFiltering is
> accomplished by calculating the distance from the center point to the
> candidate point field. Unfortunately the center point is wrapped such that
> calculating the distance from a eastern point to a western MBR provides
> incorrect results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6897) Fix maxRadius at pole for GeoPointDistanceQuery
Nicholas Knize created LUCENE-6897: -- Summary: Fix maxRadius at pole for GeoPointDistanceQuery Key: LUCENE-6897 URL: https://issues.apache.org/jira/browse/LUCENE-6897 Project: Lucene - Core Issue Type: Bug Affects Versions: Trunk, 6.0, 5.4 Reporter: Nicholas Knize At the moment GeoPointDistanceQuery throws and IllegalArgumentException if the distance exceeds the maximum radial distance on the earth's surface. At the pole, however, the radial distance should be no greater than the maximum meridian distance on the ellipsoid. This issue will correct the maximum radius check to handle center points at the poles. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6859) GeoPointInPolygonQuery occasionally fails with incorrect ranges
[ https://issues.apache.org/jira/browse/LUCENE-6859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize resolved LUCENE-6859. Resolution: Fixed Fix Version/s: 5.4 Trunk > GeoPointInPolygonQuery occasionally fails with incorrect ranges > --- > > Key: LUCENE-6859 > URL: https://issues.apache.org/jira/browse/LUCENE-6859 > Project: Lucene - Core > Issue Type: Bug >Reporter: Nicholas Knize > Fix For: Trunk, 5.4 > > Attachments: LUCENE-6859.patch > > > With high resolution polygons (small sizes) GeoPolygonTermsEnum occasionally > fails to compute the correct number of ranges. In certain cases the TermsEnum > is completely empty. This leads to incorrect query results in the form of > both false positives and negatives. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
