[jira] [Assigned] (LUCENE-8621) Move LatLonShape and XYShape out of sandbox
[
https://issues.apache.org/jira/browse/LUCENE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize reassigned LUCENE-8621:
--
Assignee: Nicholas Knize
> Move LatLonShape and XYShape out of sandbox
> ---
>
> Key: LUCENE-8621
> URL: https://issues.apache.org/jira/browse/LUCENE-8621
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Nicholas Knize
>Priority: Minor
>
> LatLonShape has matured a lot over the last months, I'd like to start
> thinking about moving it out of sandbox so that it doesn't stay there for too
> long like what happened to LatLonPoint. I am pretty happy with the current
> encoding. To my knowledge, we might just need to do a minor modification
> because of
> LUCENE-8620.
> {{XYShape}} and foundation classes will also need to be refactored.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8621) Move LatLonShape and XYShape out of sandbox
[
https://issues.apache.org/jira/browse/LUCENE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907653#comment-16907653
]
Nicholas Knize commented on LUCENE-8621:
Per LUCENE-8369 I'll take the task of refactoring {{LatLonShape}}, {{XYShape}},
and all foundation, utility, and query classes
> Move LatLonShape and XYShape out of sandbox
> ---
>
> Key: LUCENE-8621
> URL: https://issues.apache.org/jira/browse/LUCENE-8621
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> LatLonShape has matured a lot over the last months, I'd like to start
> thinking about moving it out of sandbox so that it doesn't stay there for too
> long like what happened to LatLonPoint. I am pretty happy with the current
> encoding. To my knowledge, we might just need to do a minor modification
> because of
> LUCENE-8620.
> {{XYShape}} and foundation classes will also need to be refactored.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8621) Move LatLonShape and XYShape out of sandbox
[
https://issues.apache.org/jira/browse/LUCENE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-8621:
---
Description:
LatLonShape has matured a lot over the last months, I'd like to start thinking
about moving it out of sandbox so that it doesn't stay there for too long like
what happened to LatLonPoint. I am pretty happy with the current encoding. To
my knowledge, we might just need to do a minor modification because of
LUCENE-8620.
{{XYShape}} and foundation classes will also need to be refactored.
was:
LatLonShape has matured a lot over the last months, I'd like to start thinking
about moving it out of sandbox so that it doesn't stay there for too long like
what happened to LatLonPoint. I am pretty happy with the current encoding. To
my knowledge, we might just need to do a minor modification because of
LUCENE-8620.
> Move LatLonShape and XYShape out of sandbox
> ---
>
> Key: LUCENE-8621
> URL: https://issues.apache.org/jira/browse/LUCENE-8621
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> LatLonShape has matured a lot over the last months, I'd like to start
> thinking about moving it out of sandbox so that it doesn't stay there for too
> long like what happened to LatLonPoint. I am pretty happy with the current
> encoding. To my knowledge, we might just need to do a minor modification
> because of
> LUCENE-8620.
> {{XYShape}} and foundation classes will also need to be refactored.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8369) Remove the spatial module as it is obsolete
[
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907651#comment-16907651
]
Nicholas Knize edited comment on LUCENE-8369 at 8/14/19 9:50 PM:
-
Sounds good to me. Thanks [~mikemccand] and [~simonw]
[~dsmiley] I think we're good to go on this patch then to remove the spatial
module? I'll handle refactoring {{LatLonShape}} and {{XYShape}} classes to
{{core}} in LUCENE-8621
was (Author: nknize):
Sounds good to me. Thanks [~mikemccand] and [~simonw]
[~dsmiley] I think we're good to go on this patch then to remove the spatial
module? I'll handle refactoring {{LatLonShape}} and {{XYShape}} classes to
{{core}} in a separate issue.
> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple
> utilities that aren't used by anything in the entire codebase --
> GeoRelationUtils, and MortonEncoder. Perhaps it should have been removed
> earlier in LUCENE-7664 which was the removal of GeoPointField which was
> essentially why the module existed. Better late than never.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8621) Move LatLonShape and XYShape out of sandbox
[ https://issues.apache.org/jira/browse/LUCENE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-8621: --- Summary: Move LatLonShape and XYShape out of sandbox (was: Move LatLonShape out of sandbox) > Move LatLonShape and XYShape out of sandbox > --- > > Key: LUCENE-8621 > URL: https://issues.apache.org/jira/browse/LUCENE-8621 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > > LatLonShape has matured a lot over the last months, I'd like to start > thinking about moving it out of sandbox so that it doesn't stay there for too > long like what happened to LatLonPoint. I am pretty happy with the current > encoding. To my knowledge, we might just need to do a minor modification > because of > LUCENE-8620. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete
[
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907651#comment-16907651
]
Nicholas Knize commented on LUCENE-8369:
Sounds good to me. Thanks [~mikemccand] and [~simonw]
[~dsmiley] I think we're good to go on this patch then to remove the spatial
module? I'll handle refactoring {{LatLonShape}} and {{XYShape}} classes to
{{core}} in a separate issue.
> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple
> utilities that aren't used by anything in the entire codebase --
> GeoRelationUtils, and MortonEncoder. Perhaps it should have been removed
> earlier in LUCENE-7664 which was the removal of GeoPointField which was
> essentially why the module existed. Better late than never.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8369) Remove the spatial module as it is obsolete
[
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903204#comment-16903204
]
Nicholas Knize edited comment on LUCENE-8369 at 8/8/19 6:14 PM:
As a side note: the two classes in the spatial module are no longer used and
can be removed; leaving the spatial module empty.
So it sounds like we're converging on three options then:
1. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to core;
delete spatial module and maintain package private visibility on dependency
classes
2. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module; make dependency classes in core public and label w/ _@lucene.internal_
3. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module for Lucene 9 release; keep core dependency class visibility package
private and use [java modules|https://www.jcp.org/en/jsr/detail?id=376] to
expose package private classes to the spatial module?
I introduce the third option here because a. I think it might strike a nice
balance between separating "esoteric" shape features (whatever that means) to
the spatial module while maintaining proper API visibility, and b. with the
move to Java 11 we can introduce the Java Platform Module system to achieve
proper visibility.
I'll admit I'm no expert when it comes to the Java Module System but I seem to
recall a conversation around this topic a few years back when Java 9 was
released?
We could also do 2. above for the next Lucene 8.x release, and explore the
module option as a separate issue for the 9.0 release?
was (Author: nknize):
As a side note: the two classes in the spatial module are no longer used and
can be removed; leaving the spatial module empty.
So it sounds like we're converging on three options then:
1. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to core;
delete spatial module and maintain package private visibility on dependency
classes
2. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module; make dependency classes in core public and label w/ _@lucene.internal_
3. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module for Lucene 9 release; keep core dependency class visibility package
private and use [java modules|https://www.jcp.org/en/jsr/detail?id=376] to
expose package private classes to the spatial module?
I introduce the third option here because a. I think it might strike a nice
balance between separating "esoteric" shape features (whatever that means) to
the spatial module while maintaining proper API visibility, and b. with the
move to Java 11 we can introduce the Java Platform Module system to achieve
proper visibility.
I'll admit I'm no expert when it comes to the Java Module System but I seem to
recall a conversation around this topic a few years back when Java 9 was
released?
> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple
> utilities that aren't used by anything in the entire codebase --
> GeoRelationUtils, and MortonEncoder. Perhaps it should have been removed
> earlier in LUCENE-7664 which was the removal of GeoPointField which was
> essentially why the module existed. Better late than never.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8369) Remove the spatial module as it is obsolete
[
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903204#comment-16903204
]
Nicholas Knize edited comment on LUCENE-8369 at 8/8/19 6:12 PM:
As a side note: the two classes in the spatial module are no longer used and
can be removed; leaving the spatial module empty.
So it sounds like we're converging on three options then:
1. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to core;
delete spatial module and maintain package private visibility on dependency
classes
2. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module; make dependency classes in core public and label w/ _@lucene.internal_
3. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module for Lucene 9 release; keep core dependency class visibility package
private and use [java modules|https://www.jcp.org/en/jsr/detail?id=376] to
expose package private classes to the spatial module?
I introduce the third option here because a. I think it might strike a nice
balance between separating "esoteric" shape features (whatever that means) to
the spatial module while maintaining proper API visibility, and b. with the
move to Java 11 we can introduce the Java Platform Module system to achieve
proper visibility.
I'll admit I'm no expert when it comes to the Java Module System but I seem to
recall a conversation around this topic a few years back when Java 9 was
released?
was (Author: nknize):
As a side note: the two classes in the spatial module are no longer used and
can be removed; leaving the spatial module empty.
So it sounds like we're converging on three options then:
1. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to core;
delete spatial module and maintain package private visibility on dependency
classes
2. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module; make dependency classes in core public and label w/ _@lucene.internal_
3. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module for Lucene 9 release; leave core dependency class visibility alone and
use [java modules|https://www.jcp.org/en/jsr/detail?id=376] to expose package
private classes to the spatial module?
I introduce the third option here because a. I think it might strike a nice
balance between separating "esoteric" shape features (whatever that means) to
the spatial module while maintaining proper API visibility, and b. with the
move to Java 11 we can introduce the Java Platform Module system to achieve
proper visibility.
I'll admit I'm no expert when it comes to the Java Module System but I seem to
recall a conversation around this topic a few years back when Java 9 was
released?
> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple
> utilities that aren't used by anything in the entire codebase --
> GeoRelationUtils, and MortonEncoder. Perhaps it should have been removed
> earlier in LUCENE-7664 which was the removal of GeoPointField which was
> essentially why the module existed. Better late than never.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8369) Remove the spatial module as it is obsolete
[
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903204#comment-16903204
]
Nicholas Knize edited comment on LUCENE-8369 at 8/8/19 6:11 PM:
As a side note: the two classes in the spatial module are no longer used and
can be removed; leaving the spatial module empty.
So it sounds like we're converging on three options then:
1. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to core;
delete spatial module and maintain package private visibility on dependency
classes
2. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module; make dependency classes in core public and label w/ _@lucene.internal_
3. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module for Lucene 9 release; leave core dependency class visibility alone and
use [java modules|https://www.jcp.org/en/jsr/detail?id=376] to expose package
private classes to the spatial module?
I introduce the third option here because a. I think it might strike a nice
balance between separating "esoteric" shape features (whatever that means) to
the spatial module while maintaining proper API visibility, and b. with the
move to Java 11 we can introduce the Java Platform Module system to achieve
proper visibility.
I'll admit I'm no expert when it comes to the Java Module System but I seem to
recall a conversation around this topic a few years back when Java 9 was
released?
was (Author: nknize):
As a side note: the two classes in the spatial module are no longer used and
can be removed; leaving the spatial module empty.
So it sounds like we're converging on three options then:
1. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to core;
delete spatial module
2. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module; make dependency classes in core public and label w/ _@lucene.internal_
3. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module for Lucene 9 release; leave core dependency class visibility alone and
use [java modules|https://www.jcp.org/en/jsr/detail?id=376] to expose package
private classes to the spatial module?
I introduce the third option here because a. I think it might strike a nice
balance between separating "esoteric" shape features (whatever that means) to
the spatial module while maintaining proper API visibility, and b. with the
move to Java 11 we can introduce the Java Platform Module system to achieve
proper visibility.
I'll admit I'm no expert when it comes to the Java Module System but I seem to
recall a conversation around this topic a few years back when Java 9 was
released?
> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple
> utilities that aren't used by anything in the entire codebase --
> GeoRelationUtils, and MortonEncoder. Perhaps it should have been removed
> earlier in LUCENE-7664 which was the removal of GeoPointField which was
> essentially why the module existed. Better late than never.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete
[
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903204#comment-16903204
]
Nicholas Knize commented on LUCENE-8369:
As a side note: the two classes in the spatial module are no longer used and
can be removed; leaving the spatial module empty.
So it sounds like we're converging on three options then:
1. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to core;
delete spatial module
2. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module; make dependency classes in core public and label w/ _@lucene.internal_
3. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module for Lucene 9 release; leave core dependency class visibility alone and
use [java modules|https://www.jcp.org/en/jsr/detail?id=376] to expose package
private classes to the spatial module?
I introduce the third option here because a. I think it might strike a nice
balance between separating "esoteric" shape features (whatever that means) to
the spatial module while maintaining proper API visibility, and b. with the
move to Java 11 we can introduce the Java Platform Module system to achieve
proper visibility.
I'll admit I'm no expert when it comes to the Java Module System but I seem to
recall a conversation around this topic a few years back when Java 9 was
released?
> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple
> utilities that aren't used by anything in the entire codebase --
> GeoRelationUtils, and MortonEncoder. Perhaps it should have been removed
> earlier in LUCENE-7664 which was the removal of GeoPointField which was
> essentially why the module existed. Better late than never.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete
[
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896516#comment-16896516
]
Nicholas Knize commented on LUCENE-8369:
[~dsmiley] yeah, that seems to be the case more often than not. So under that
construct we would move {{LatLonPointInPolygonQuery}} to the spatial module
which even further fragments everything.
Seems this discussion gains some activity for a short bit, stalls for a year or
two, gains some more activity, then stalls again. I know it's no fun to engage
in the bikeshed activity, but it would be nice to figure out a path forward;
even if that means find a solution for the 9.0 release and just leave
{{LatLonShape}} and {{XYShape}} in sandbox for the rest of the 8.x releases.
> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple
> utilities that aren't used by anything in the entire codebase --
> GeoRelationUtils, and MortonEncoder. Perhaps it should have been removed
> earlier in LUCENE-7664 which was the removal of GeoPointField which was
> essentially why the module existed. Better late than never.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete
[
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893211#comment-16893211
]
Nicholas Knize commented on LUCENE-8369:
{quote}Can we simply make the necessary APIs public and marked
{{@lucene.internal}} in our core spatial classes?
{quote}
I think that's what we were trying to avoid because it largely feels like a cop
out to making a foundation class package private vice keeping it exposed. One
example is {{EdgeTree}} this can (and probably should) stay package private to
{{org.apache.lucene.geo}}. But it's used for {{XYShape}}, {{LatLonShape}}, and
{{LatLonPoint}}. So if we fragment those classes between the {{core}} and
{{spatial}} module we are forcing ourselves to keep it public and mark it
{{@lucene.internal}}. Which, again, feels like a cop out to doing (in my
opinion) the "right" thing and making it package private.
> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple
> utilities that aren't used by anything in the entire codebase --
> GeoRelationUtils, and MortonEncoder. Perhaps it should have been removed
> earlier in LUCENE-7664 which was the removal of GeoPointField which was
> essentially why the module existed. Better late than never.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete
[
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892820#comment-16892820
]
Nicholas Knize commented on LUCENE-8369:
{quote}Such core use cases should work easily for users without wading thru
extra jars, third party dependencies, crazy licensing, or crazy class
hierarchies.
{quote}
I agree. That's why the `spatial` module should remain dependency free and
apache licensed.
{quote}I don't think adding esoteric functionality (like non-WGS shapes)
{quote}
Except esoteric is in the eye of the beholder so claiming someone will
understand or prefer latitude longitude search any more than basic x, y is
assumptive.
{quote}My fear of having LatLonPoint in a different package to other spatial
fields is code sharing
{quote}
I agree. When we only had LatLonPoint I leaned toward it moving to the spatial
module because of how we could advance the foundation. But since we weren't
there yet, I could understand the argument for having "...basic functionality
in core that solves the 90% geo use case". Now we've added geo shapes and a
cartesian coordinate system and it's quickly becoming a fragmentation issue
impeding development. IMHO it's clearer and cleaner for the dependency free
spatial code to all exist together in the same module called {{spatial}}. Is
there any technical downside or argument against removing it from core? Or is
it all a matter of opinion?
> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple
> utilities that aren't used by anything in the entire codebase --
> GeoRelationUtils, and MortonEncoder. Perhaps it should have been removed
> earlier in LUCENE-7664 which was the removal of GeoPointField which was
> essentially why the module existed. Better late than never.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete
[
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892091#comment-16892091
]
Nicholas Knize commented on LUCENE-8369:
Since the merge of XYShape I wanted to quickly resurrect this conversation.
Given so much of the {{LatLonShape}} foundation is shared between
{{LatLonPoint}} and {{XYShape}} and we have a {{spatial}} module that is
basically empty. I tend to agree with [~dsmiley]'s original proposal to
refactor {{LatLonPoint}}, {{LatLonShape}}, {{XYShape}}, and all query, support,
and util classes currently spread between {{core}} and {{sandbox}} to the
{{spatial}} module.
We can keep the {{spatial}} module dependency free, and still use
{{spatial-extras}} to build on the foundation classes with third-party
dependencies. I think the only major ramification is that {{Geo3d}} will have
to be updated to depend on the spatial module. But I don't see that as a major
blocker.
Comments, thoughts, objections? /cc [~mikemccand] [~jpountz] [~rcmuir]
[~ivera]
> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple
> utilities that aren't used by anything in the entire codebase --
> GeoRelationUtils, and MortonEncoder. Perhaps it should have been removed
> earlier in LUCENE-7664 which was the removal of GeoPointField which was
> essentially why the module existed. Better late than never.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8913) Reproducing failure in various TestLatLon* equals/hashcode tests
[
https://issues.apache.org/jira/browse/LUCENE-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16884541#comment-16884541
]
Nicholas Knize commented on LUCENE-8913:
Thanks [~gh_at] It couple be a result of the refactor work to support XYShape.
Will look into it.
> Reproducing failure in various TestLatLon* equals/hashcode tests
> -
>
> Key: LUCENE-8913
> URL: https://issues.apache.org/jira/browse/LUCENE-8913
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/other
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Priority: Major
>
> Bumped into this while running tests locally
> ant clean test -Dtests.seed=41D0C5A80C823307 -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=es-CL
> -Dtests.timezone=Pacific/Rarotonga -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
> reliably produces:
>
> {code:java}
> Tests with failures [seed: 41D0C5A80C823307]:
>[junit4] -
> org.apache.lucene.document.TestLatLonPointShapeQueries.testBoxQueryEqualsAndHashcode
>[junit4] -
> org.apache.lucene.document.TestLatLonMultiPointShapeQueries.testBoxQueryEqualsAndHashcode
>[junit4] -
> org.apache.lucene.document.TestLatLonLineShapeQueries.testBoxQueryEqualsAndHashcode
>[junit4] -
> org.apache.lucene.document.TestLatLonPolygonShapeQueries.testBoxQueryEqualsAndHashcode
>[junit4] -
> org.apache.lucene.document.TestLatLonMultiPolygonShapeQueries.testBoxQueryEqualsAndHashcode
>[junit4] -
> org.apache.lucene.document.TestLatLonMultiLineShapeQueries.testBoxQueryEqualsAndHashcode{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8632) XYShape: Adapt LatLonShape tessellator, field type, and queries to non-geo shapes
[
https://issues.apache.org/jira/browse/LUCENE-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize resolved LUCENE-8632.
Resolution: Implemented
> XYShape: Adapt LatLonShape tessellator, field type, and queries to non-geo
> shapes
> -
>
> Key: LUCENE-8632
> URL: https://issues.apache.org/jira/browse/LUCENE-8632
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently the tessellator is tightly coupled with latitude and longitude
> (WGS84) geospatial coordinates. This issue will explore generalizing the
> tessellator, {{LatLonShape}} field and {{LatLonShapeQuery}} to non geospatial
> (cartesian) coordinate systems so lucene can provide the index & search
> capability for general geometry / non GIS type use cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8632) XYShape: Adapt LatLonShape tessellator, field type, and queries to non-geo shapes
[
https://issues.apache.org/jira/browse/LUCENE-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865858#comment-16865858
]
Nicholas Knize commented on LUCENE-8632:
Opened a PR for adding the ability to index and search non Geo / GIS Geometries
by leveraging and abstracting much of the LatLonShape foundation. I chose the
PR route since the number of lines is quite big and I figured it would be
easier to review instead of attaching a patch.
> XYShape: Adapt LatLonShape tessellator, field type, and queries to non-geo
> shapes
> -
>
> Key: LUCENE-8632
> URL: https://issues.apache.org/jira/browse/LUCENE-8632
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently the tessellator is tightly coupled with latitude and longitude
> (WGS84) geospatial coordinates. This issue will explore generalizing the
> tessellator, {{LatLonShape}} field and {{LatLonShapeQuery}} to non geospatial
> (cartesian) coordinate systems so lucene can provide the index & search
> capability for general geometry / non GIS type use cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8632) XYShape: Adapt LatLonShape tessellator, field type, and queries to non-geo shapes
[
https://issues.apache.org/jira/browse/LUCENE-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-8632:
---
Description: Currently the tessellator is tightly coupled with latitude and
longitude (WGS84) geospatial coordinates. This issue will explore generalizing
the tessellator, {{LatLonShape}} field and {{LatLonShapeQuery}} to non
geospatial (cartesian) coordinate systems so lucene can provide the index &
search capability for general geometry / non GIS type use cases. (was:
Currently the tessellator is tightly coupled with latitude and longitude
(WGS84) geospatial coordinates. This issue will explore generalizing the
tessellator to non geospatial coordinate systems so lucene can handle arbitrary
projections in vector space.)
> XYShape: Adapt LatLonShape tessellator, field type, and queries to non-geo
> shapes
> -
>
> Key: LUCENE-8632
> URL: https://issues.apache.org/jira/browse/LUCENE-8632
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
>
> Currently the tessellator is tightly coupled with latitude and longitude
> (WGS84) geospatial coordinates. This issue will explore generalizing the
> tessellator, {{LatLonShape}} field and {{LatLonShapeQuery}} to non geospatial
> (cartesian) coordinate systems so lucene can provide the index & search
> capability for general geometry / non GIS type use cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8632) XYShape: Adapt LatLonShape tessellator, field type, and queries to non-geo shapes
[ https://issues.apache.org/jira/browse/LUCENE-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-8632: --- Summary: XYShape: Adapt LatLonShape tessellator, field type, and queries to non-geo shapes (was: Adapt LatLonShape tessellator, field type, and queries to non-geo shapes) > XYShape: Adapt LatLonShape tessellator, field type, and queries to non-geo > shapes > - > > Key: LUCENE-8632 > URL: https://issues.apache.org/jira/browse/LUCENE-8632 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Nicholas Knize >Assignee: Nicholas Knize >Priority: Major > > Currently the tessellator is tightly coupled with latitude and longitude > (WGS84) geospatial coordinates. This issue will explore generalizing the > tessellator to non geospatial coordinate systems so lucene can handle > arbitrary projections in vector space. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8632) Adapt LatLonShape tessellator, field type, and queries to non-geo shapes
[ https://issues.apache.org/jira/browse/LUCENE-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-8632: --- Summary: Adapt LatLonShape tessellator, field type, and queries to non-geo shapes (was: Adapt LatLonShape tessellator to non-geo shapes) > Adapt LatLonShape tessellator, field type, and queries to non-geo shapes > > > Key: LUCENE-8632 > URL: https://issues.apache.org/jira/browse/LUCENE-8632 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Nicholas Knize >Assignee: Nicholas Knize >Priority: Major > > Currently the tessellator is tightly coupled with latitude and longitude > (WGS84) geospatial coordinates. This issue will explore generalizing the > tessellator to non geospatial coordinate systems so lucene can handle > arbitrary projections in vector space. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8736) LatLonShapePolygonQuery returning incorrect WITHIN results with shared boundaries
[
https://issues.apache.org/jira/browse/LUCENE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822007#comment-16822007
]
Nicholas Knize commented on LUCENE-8736:
bq. If the behavior were to differ, practically speaking, would it be noticed?
By the general user, maybe not. I suppose we will find out. Though I would say
the same about the minor performance change and I still think correctness
trumps performance.
bq. Points are the common use case by far.
All the more reason I think we should be following Geospatial specifications,
for a geo field, like the rest of the geo community but if that's not the
consensus and the 1-2qps performance change is unacceptable I'll split the
logic changes out to shapes only and revert points.
> LatLonShapePolygonQuery returning incorrect WITHIN results with shared
> boundaries
> -
>
> Key: LUCENE-8736
> URL: https://issues.apache.org/jira/browse/LUCENE-8736
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8736.patch, LUCENE-8736.patch,
> adaptive-decoding.patch
>
>
> Triangles that are {{WITHIN}} a target polygon query that also share a
> boundary with the polygon are incorrectly reported as {{CROSSES}} instead of
> {{INSIDE}}. This leads to incorrect {{WITHIN}} query results as demonstrated
> in the following test:
> {code:java}
> public void testWithinFailure() throws Exception {
> Directory dir = newDirectory();
> RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> // test polygons:
> Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {6d, 7d, 7d, 6d, 6d});
> Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {0d, 1d, 1d, 0d, 0d});
> // index polygons:
> Document doc;
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
> w.addDocument(doc);
> / search //
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d,
> 0d, 0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
> Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN,
> searchPoly);
> assertEquals(4, searcher.count(q));
> IOUtils.close(w, reader, dir);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8736) LatLonShapePolygonQuery returning incorrect WITHIN results with shared boundaries
[
https://issues.apache.org/jira/browse/LUCENE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821496#comment-16821496
]
Nicholas Knize commented on LUCENE-8736:
{quote}that document is about shapes,
{quote}
That document is the "OpenGIS® Implementation Standard for Geographic
information - Simple feature access - Part 1: Common architecture". It's about
Geospatial Data and includes sections on spatial relations / predicates such as
Point in Polygon search (and other geospatial geometries); not just shapes. I
think it's important for a field such as *LatLon*Point (which is developed for
geospatial search) follows community standards; it benefits the project as a
whole and helps to be taken serious by the Geospatial community. Furthermore,
the crossing number algorithm doc itself even says it considers topological and
point-set theory delimitations for simplicity. The GIS specification does not
share these requirements.
I'm also concerned about deviating behavior between {{LatLonPoint}} and
{{LatLonShape}}. I think they should complement each other, and follow OGC
standards, to avoid confusion. Again, just my opinion.
> LatLonShapePolygonQuery returning incorrect WITHIN results with shared
> boundaries
> -
>
> Key: LUCENE-8736
> URL: https://issues.apache.org/jira/browse/LUCENE-8736
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8736.patch, LUCENE-8736.patch,
> adaptive-decoding.patch
>
>
> Triangles that are {{WITHIN}} a target polygon query that also share a
> boundary with the polygon are incorrectly reported as {{CROSSES}} instead of
> {{INSIDE}}. This leads to incorrect {{WITHIN}} query results as demonstrated
> in the following test:
> {code:java}
> public void testWithinFailure() throws Exception {
> Directory dir = newDirectory();
> RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> // test polygons:
> Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {6d, 7d, 7d, 6d, 6d});
> Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {0d, 1d, 1d, 0d, 0d});
> // index polygons:
> Document doc;
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
> w.addDocument(doc);
> / search //
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d,
> 0d, 0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
> Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN,
> searchPoly);
> assertEquals(4, searcher.count(q));
> IOUtils.close(w, reader, dir);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8736) LatLonShapePolygonQuery returning incorrect WITHIN results with shared boundaries
[
https://issues.apache.org/jira/browse/LUCENE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818019#comment-16818019
]
Nicholas Knize edited comment on LUCENE-8736 at 4/15/19 4:06 PM:
-
{quote}it would be good to have an example where the determinant overflows as I
haven't been able to exercise such an error.
{quote}
I'll see if I can grab an example. As expected, it doesn't occur when computing
on encoded integer space; only decoded 64 bit double space.
{quote}I guess I don't see them as boundary failures.
{quote}
The concern I have is the behavior of excluding boundary points does not follow
[OGC specifications;|http://portal.opengeospatial.org/files/?artifact_id=25355]
(pg 37, "touches" relationship) which is the standard that geo systems _should_
follow; and the standard I think we should follow.
{quote}this patch really really hurts points
{quote}
Looking at the benchmarks I don't know that it _really_ _really_ hurts points.
For me it's most important the behavior is correct. Then we can look at ways to
improve performance? In this instance I think following the OGC community
definition is probably best for defining "correct" behavior.
was (Author: nknize):
{quote}it would be good to have an example where the determinant overflows as I
haven't been able to exercise such an error.
{quote}
I'll see if I can grab an example. As expected, it doesn't occur when computing
on encoded integer space; only decoded 64 bit double space.
{quote}I guess I don't see them as boundary failures.
{quote}
The issue I have is the behavior of excluding boundary points does not follow
[OGC specifications;|http://portal.opengeospatial.org/files/?artifact_id=25355]
(pg 37, "touches" relationship) which is the standard that geo systems _should_
follow; and the standard I think we should follow.
{quote}this patch really really hurts points
{quote}
Looking at the benchmarks I don't know that it _really_ _really_ hurts points.
For me it's most important the behavior is correct. Then we can look at ways to
improve performance? In this instance I think following the OGC community
definition is probably best for defining "correct" behavior.
> LatLonShapePolygonQuery returning incorrect WITHIN results with shared
> boundaries
> -
>
> Key: LUCENE-8736
> URL: https://issues.apache.org/jira/browse/LUCENE-8736
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8736.patch, LUCENE-8736.patch,
> adaptive-decoding.patch
>
>
> Triangles that are {{WITHIN}} a target polygon query that also share a
> boundary with the polygon are incorrectly reported as {{CROSSES}} instead of
> {{INSIDE}}. This leads to incorrect {{WITHIN}} query results as demonstrated
> in the following test:
> {code:java}
> public void testWithinFailure() throws Exception {
> Directory dir = newDirectory();
> RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> // test polygons:
> Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {6d, 7d, 7d, 6d, 6d});
> Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {0d, 1d, 1d, 0d, 0d});
> // index polygons:
> Document doc;
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
> w.addDocument(doc);
> / search //
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d,
> 0d, 0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
> Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN,
> searchPoly);
> assertEquals(4, searcher.count(q));
> IOUtils.close(w, reader, dir);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8736) LatLonShapePolygonQuery returning incorrect WITHIN results with shared boundaries
[
https://issues.apache.org/jira/browse/LUCENE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818019#comment-16818019
]
Nicholas Knize edited comment on LUCENE-8736 at 4/15/19 2:43 PM:
-
{quote}it would be good to have an example where the determinant overflows as I
haven't been able to exercise such an error.
{quote}
I'll see if I can grab an example. As expected, it doesn't occur when computing
on encoded integer space; only decoded 64 bit double space.
{quote}I guess I don't see them as boundary failures.
{quote}
The issue I have is the behavior of excluding boundary points does not follow
[OGC specifications;|http://portal.opengeospatial.org/files/?artifact_id=25355]
(pg 37, "touches" relationship) which is the standard that geo systems _should_
follow; and the standard I think we should follow.
{quote}this patch really really hurts points
{quote}
Looking at the benchmarks I don't know that it _really_ _really_ hurts points.
For me it's most important the behavior is correct. Then we can look at ways to
improve performance? In this instance I think following the OGC community
definition is probably best for defining "correct" behavior.
was (Author: nknize):
{quote}it would be good to have an example where the determinant overflows as I
haven't been able to exercise such an error.
{quote}
I'll see if I can grab an example. As expected, it doesn't occur when computing
on encoded integer space; only decoded 64 bit double space.
{quote}I guess I don't see them as boundary failures.
{quote}
The issue I have is the behavior of excluding boundary points does not follow
[OGC specifications;|http://portal.opengeospatial.org/files/?artifact_id=25355]
which is the standard that geo systems _should_ follow; and the standard I
think we should follow.
{quote}this patch really really hurts points
{quote}
Looking at the benchmarks I don't know that it _really_ _really_ hurts points.
For me it's most important the behavior is correct. Then we can look at ways to
improve performance? In this instance I think following the OGC community
definition is probably best for defining "correct" behavior.
> LatLonShapePolygonQuery returning incorrect WITHIN results with shared
> boundaries
> -
>
> Key: LUCENE-8736
> URL: https://issues.apache.org/jira/browse/LUCENE-8736
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8736.patch, LUCENE-8736.patch,
> adaptive-decoding.patch
>
>
> Triangles that are {{WITHIN}} a target polygon query that also share a
> boundary with the polygon are incorrectly reported as {{CROSSES}} instead of
> {{INSIDE}}. This leads to incorrect {{WITHIN}} query results as demonstrated
> in the following test:
> {code:java}
> public void testWithinFailure() throws Exception {
> Directory dir = newDirectory();
> RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> // test polygons:
> Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {6d, 7d, 7d, 6d, 6d});
> Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {0d, 1d, 1d, 0d, 0d});
> // index polygons:
> Document doc;
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
> w.addDocument(doc);
> / search //
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d,
> 0d, 0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
> Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN,
> searchPoly);
> assertEquals(4, searcher.count(q));
> IOUtils.close(w, reader, dir);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8736) LatLonShapePolygonQuery returning incorrect WITHIN results with shared boundaries
[
https://issues.apache.org/jira/browse/LUCENE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818019#comment-16818019
]
Nicholas Knize edited comment on LUCENE-8736 at 4/15/19 2:42 PM:
-
{quote}it would be good to have an example where the determinant overflows as I
haven't been able to exercise such an error.
{quote}
I'll see if I can grab an example. As expected, it doesn't occur when computing
on encoded integer space; only decoded 64 bit double space.
{quote}I guess I don't see them as boundary failures.
{quote}
The issue I have is the behavior of excluding boundary points does not follow
[OGC specifications;|http://portal.opengeospatial.org/files/?artifact_id=25355]
which is the standard that geo systems _should_ follow; and the standard I
think we should follow.
{quote}this patch really really hurts points
{quote}
Looking at the benchmarks I don't know that it _really_ _really_ hurts points.
For me it's most important the behavior is correct. Then we can look at ways to
improve performance? In this instance I think following the OGC community
definition is probably best for defining "correct" behavior.
was (Author: nknize):
{quote}it would be good to have an example where the determinant overflows as I
haven't been able to exercise such an error.
{quote}
I'll see if I can grab an example. As expected, it doesn't occur when computing
on encoded integer space; only decoded 64 bit double space.
{quote}I guess I don't see them as boundary failures.
{quote}
The issue I have is the behavior of excluding boundary points does not follow
[OGC specifications;|https://www.opengeospatial.org/standards/sfa] which is the
standard that geo systems _should_ follow; and the standard I think we should
follow.
{quote}this patch really really hurts points
{quote}
Looking at the benchmarks I don't know that it _really_ _really_ hurts points.
For me it's most important the behavior is correct. Then we can look at ways to
improve performance? In this instance I think following the OGC community
definition is probably best for defining "correct" behavior.
> LatLonShapePolygonQuery returning incorrect WITHIN results with shared
> boundaries
> -
>
> Key: LUCENE-8736
> URL: https://issues.apache.org/jira/browse/LUCENE-8736
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8736.patch, LUCENE-8736.patch,
> adaptive-decoding.patch
>
>
> Triangles that are {{WITHIN}} a target polygon query that also share a
> boundary with the polygon are incorrectly reported as {{CROSSES}} instead of
> {{INSIDE}}. This leads to incorrect {{WITHIN}} query results as demonstrated
> in the following test:
> {code:java}
> public void testWithinFailure() throws Exception {
> Directory dir = newDirectory();
> RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> // test polygons:
> Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {6d, 7d, 7d, 6d, 6d});
> Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {0d, 1d, 1d, 0d, 0d});
> // index polygons:
> Document doc;
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
> w.addDocument(doc);
> / search //
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d,
> 0d, 0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
> Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN,
> searchPoly);
> assertEquals(4, searcher.count(q));
> IOUtils.close(w, reader, dir);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8736) LatLonShapePolygonQuery returning incorrect WITHIN results with shared boundaries
[
https://issues.apache.org/jira/browse/LUCENE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818019#comment-16818019
]
Nicholas Knize commented on LUCENE-8736:
{quote}it would be good to have an example where the determinant overflows as I
haven't been able to exercise such an error.
{quote}
I'll see if I can grab an example. As expected, it doesn't occur when computing
on encoded integer space; only decoded 64 bit double space.
{quote}I guess I don't see them as boundary failures.
{quote}
The issue I have is the behavior of excluding boundary points does not follow
[OGC specifications;|https://www.opengeospatial.org/standards/sfa] which is the
standard that geo systems _should_ follow; and the standard I think we should
follow.
{quote}this patch really really hurts points
{quote}
Looking at the benchmarks I don't know that it _really_ _really_ hurts points.
For me it's most important the behavior is correct. Then we can look at ways to
improve performance? In this instance I think following the OGC community
definition is probably best for defining "correct" behavior.
> LatLonShapePolygonQuery returning incorrect WITHIN results with shared
> boundaries
> -
>
> Key: LUCENE-8736
> URL: https://issues.apache.org/jira/browse/LUCENE-8736
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8736.patch, LUCENE-8736.patch,
> adaptive-decoding.patch
>
>
> Triangles that are {{WITHIN}} a target polygon query that also share a
> boundary with the polygon are incorrectly reported as {{CROSSES}} instead of
> {{INSIDE}}. This leads to incorrect {{WITHIN}} query results as demonstrated
> in the following test:
> {code:java}
> public void testWithinFailure() throws Exception {
> Directory dir = newDirectory();
> RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> // test polygons:
> Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {6d, 7d, 7d, 6d, 6d});
> Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {0d, 1d, 1d, 0d, 0d});
> // index polygons:
> Document doc;
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
> w.addDocument(doc);
> / search //
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d,
> 0d, 0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
> Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN,
> searchPoly);
> assertEquals(4, searcher.count(q));
> IOUtils.close(w, reader, dir);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-8736) LatLonShapePolygonQuery returning incorrect WITHIN results with shared boundaries
[
https://issues.apache.org/jira/browse/LUCENE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize reopened LUCENE-8736:
Assignee: Nicholas Knize
Lucene Fields: New (was: New,Patch Available)
[~rcmuir] yeah I was thinking about that while working these changes. On the
one hand explicitly accepting boundary failures (especially for such common
cases as shown here and in the test) is annoying (though I get the reasoning).
On the other hand, the determinant equality approach could also [suffer from
overflow|https://www.cs.cmu.edu/~quake/robust.html]. The problem with the
latter is that we don't have a good feel for the rate at which overflow occurs
or the percentage of false positives for when points outside the polygon are
erroneously determined as colinear by an overflowed determinant. I think that
deserves some further exploration.
So for now, I can revert the change for points but I'm curious to your thoughts
around exploring the [adaptive
orientation|https://www.cs.cmu.edu/afs/cs/project/quake/public/code/predicates.c]
(_orient2dadap_) approach to solve the overflow issue. I have a [very rough
port|https://gist.github.com/nknize/dd1dc8a1ccaa8900b70c478cce846f29] that I
can experiment with for points in a separate issue?
> LatLonShapePolygonQuery returning incorrect WITHIN results with shared
> boundaries
> -
>
> Key: LUCENE-8736
> URL: https://issues.apache.org/jira/browse/LUCENE-8736
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8736.patch, LUCENE-8736.patch,
> adaptive-decoding.patch
>
>
> Triangles that are {{WITHIN}} a target polygon query that also share a
> boundary with the polygon are incorrectly reported as {{CROSSES}} instead of
> {{INSIDE}}. This leads to incorrect {{WITHIN}} query results as demonstrated
> in the following test:
> {code:java}
> public void testWithinFailure() throws Exception {
> Directory dir = newDirectory();
> RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> // test polygons:
> Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {6d, 7d, 7d, 6d, 6d});
> Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {0d, 1d, 1d, 0d, 0d});
> // index polygons:
> Document doc;
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
> w.addDocument(doc);
> / search //
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d,
> 0d, 0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
> Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN,
> searchPoly);
> assertEquals(4, searcher.count(q));
> IOUtils.close(w, reader, dir);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8736) LatLonShapePolygonQuery returning incorrect WITHIN results with shared boundaries
[
https://issues.apache.org/jira/browse/LUCENE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-8736:
---
Fix Version/s: master (9.0)
8.1
> LatLonShapePolygonQuery returning incorrect WITHIN results with shared
> boundaries
> -
>
> Key: LUCENE-8736
> URL: https://issues.apache.org/jira/browse/LUCENE-8736
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8736.patch, LUCENE-8736.patch,
> adaptive-decoding.patch
>
>
> Triangles that are {{WITHIN}} a target polygon query that also share a
> boundary with the polygon are incorrectly reported as {{CROSSES}} instead of
> {{INSIDE}}. This leads to incorrect {{WITHIN}} query results as demonstrated
> in the following test:
> {code:java}
> public void testWithinFailure() throws Exception {
> Directory dir = newDirectory();
> RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> // test polygons:
> Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {6d, 7d, 7d, 6d, 6d});
> Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {0d, 1d, 1d, 0d, 0d});
> // index polygons:
> Document doc;
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
> w.addDocument(doc);
> / search //
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d,
> 0d, 0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
> Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN,
> searchPoly);
> assertEquals(4, searcher.count(q));
> IOUtils.close(w, reader, dir);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8736) LatLonShapePolygonQuery returning incorrect WITHIN results with shared boundaries
[
https://issues.apache.org/jira/browse/LUCENE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize resolved LUCENE-8736.
Resolution: Fixed
> LatLonShapePolygonQuery returning incorrect WITHIN results with shared
> boundaries
> -
>
> Key: LUCENE-8736
> URL: https://issues.apache.org/jira/browse/LUCENE-8736
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8736.patch, LUCENE-8736.patch,
> adaptive-decoding.patch
>
>
> Triangles that are {{WITHIN}} a target polygon query that also share a
> boundary with the polygon are incorrectly reported as {{CROSSES}} instead of
> {{INSIDE}}. This leads to incorrect {{WITHIN}} query results as demonstrated
> in the following test:
> {code:java}
> public void testWithinFailure() throws Exception {
> Directory dir = newDirectory();
> RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> // test polygons:
> Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {6d, 7d, 7d, 6d, 6d});
> Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {0d, 1d, 1d, 0d, 0d});
> // index polygons:
> Document doc;
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
> w.addDocument(doc);
> / search //
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d,
> 0d, 0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
> Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN,
> searchPoly);
> assertEquals(4, searcher.count(q));
> IOUtils.close(w, reader, dir);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8736) LatLonShapePolygonQuery returning incorrect WITHIN results with shared boundaries
[
https://issues.apache.org/jira/browse/LUCENE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801806#comment-16801806
]
Nicholas Knize commented on LUCENE-8736:
Thanks [~ivera]!
bq. I have tried to quantize the query polygon but that seems to add other
issues
Indeed, the patch doesn't fix incorrect results related to quantization
differences; which, as you pointed out, is related to the example test failure
I posted. I think we can investigate and address that in a separate issue?
Also, related to this ticket is a similar issue w/
{{Polygon2D.componentRelate}} which uses the same faulty logic as
{{componentRelateTriangle}}. I'll add a similar fix and tighten up the testing
in this patch so it better characterizes what this change is doing.
> LatLonShapePolygonQuery returning incorrect WITHIN results with shared
> boundaries
> -
>
> Key: LUCENE-8736
> URL: https://issues.apache.org/jira/browse/LUCENE-8736
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8736.patch
>
>
> Triangles that are {{WITHIN}} a target polygon query that also share a
> boundary with the polygon are incorrectly reported as {{CROSSES}} instead of
> {{INSIDE}}. This leads to incorrect {{WITHIN}} query results as demonstrated
> in the following test:
> {code:java}
> public void testWithinFailure() throws Exception {
> Directory dir = newDirectory();
> RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> // test polygons:
> Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {6d, 7d, 7d, 6d, 6d});
> Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {0d, 1d, 1d, 0d, 0d});
> // index polygons:
> Document doc;
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
> w.addDocument(doc);
> / search //
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d,
> 0d, 0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
> Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN,
> searchPoly);
> assertEquals(4, searcher.count(q));
> IOUtils.close(w, reader, dir);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8736) LatLonShapePolygonQuery returning incorrect WITHIN results with shared boundaries
Nicholas Knize created LUCENE-8736:
--
Summary: LatLonShapePolygonQuery returning incorrect WITHIN
results with shared boundaries
Key: LUCENE-8736
URL: https://issues.apache.org/jira/browse/LUCENE-8736
Project: Lucene - Core
Issue Type: Bug
Reporter: Nicholas Knize
Triangles that are {{WITHIN}} a target polygon query that also share a boundary
with the polygon are incorrectly reported as {{CROSSES}} instead of {{INSIDE}}.
This leads to incorrect {{WITHIN}} query results as demonstrated in the
following test:
{code:java}
public void testWithinFailure() throws Exception {
Directory dir = newDirectory();
RandomIndexWriter w = new RandomIndexWriter(random(), dir);
// test polygons:
Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new
double[] {3d, 4d, 4d, 3d, 3d});
Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
double[] {6d, 7d, 7d, 6d, 6d});
Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new
double[] {3d, 4d, 4d, 3d, 3d});
Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
double[] {0d, 1d, 1d, 0d, 0d});
// index polygons:
Document doc;
addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
w.addDocument(doc);
addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
w.addDocument(doc);
addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
w.addDocument(doc);
addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
w.addDocument(doc);
/ search //
IndexReader reader = w.getReader();
w.close();
IndexSearcher searcher = newSearcher(reader);
Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d, 0d,
0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN,
searchPoly);
assertEquals(4, searcher.count(q));
IOUtils.close(w, reader, dir);
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8721) LatLonShapePolygon and LineQuery fail on shared dateline queries
[
https://issues.apache.org/jira/browse/LUCENE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16790781#comment-16790781
]
Nicholas Knize commented on LUCENE-8721:
bq. Should we check whether there is an intersection between the range of
latitudes of the query and of the box/triangle?
Yes. I posted the wrong patch. Corrected in the new one.
bq. the coordinates are on the encoded space.
The coordinates are in the decoded space but they have been quantized so I've
corrected maxLon to use its quantized variant.
bq. +1 to simplify the logic on EdgeTree. It is trivial to merge the methods
relate & internalComponentRelate and it makes sense. I will open an issue.
+1 to simplify. I went ahead and started by merging the two methods in this
patch since it made sense. The new issue can explore further refactoring the
logic for clarity.
> LatLonShapePolygon and LineQuery fail on shared dateline queries
>
>
> Key: LUCENE-8721
> URL: https://issues.apache.org/jira/browse/LUCENE-8721
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8721.patch, LUCENE-8721.patch
>
>
> Indexed shapes should be returned with search geometries that share the
> dateline on the opposite hemisphere.
> For example:
> {code:java}
> public void testSharedDateline() throws Exception {
> index /
> Directory dir = newDirectory();
> RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> Document doc = new Document();
> // index western hemisphere geometry
> Polygon indexPoly = new Polygon(
> new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
> new double[] {-180d, -180d, -176d, -176d, -180d}
> );
> Field[] fields = LatLonShape.createIndexableFields("test", indexPoly);
> for (Field f : fields) {
> doc.add(f);
> }
> w.addDocument(doc);
> w.forceMerge(1);
> / search //
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> // search w/ eastern hemisphere geometry that shares the dateline
> Polygon searchPoly = new Polygon(new double[] {-7.5d, 15d, 15d, 0d,
> -7.5d},
> new double[] {180d, 180d, 170d, 170d, 180d});
> Query q = LatLonShape.newPolygonQuery("test", QueryRelation.INTERSECTS,
> searchPoly);
> assertEquals(1, searcher.count(q));
> IOUtils.close(w, reader, dir);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8721) LatLonShapePolygon and LineQuery fail on shared dateline queries
Nicholas Knize created LUCENE-8721:
--
Summary: LatLonShapePolygon and LineQuery fail on shared dateline
queries
Key: LUCENE-8721
URL: https://issues.apache.org/jira/browse/LUCENE-8721
Project: Lucene - Core
Issue Type: Bug
Reporter: Nicholas Knize
Indexed shapes should be returned with search geometries that share the
dateline on the opposite hemisphere.
For example:
{code:java}
public void testSharedDateline() throws Exception {
index /
Directory dir = newDirectory();
RandomIndexWriter w = new RandomIndexWriter(random(), dir);
Document doc = new Document();
// index western hemisphere geometry
Polygon indexPoly = new Polygon(
new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
new double[] {-180d, -180d, -176d, -176d, -180d}
);
Field[] fields = LatLonShape.createIndexableFields("test", indexPoly);
for (Field f : fields) {
doc.add(f);
}
w.addDocument(doc);
w.forceMerge(1);
/ search //
IndexReader reader = w.getReader();
w.close();
IndexSearcher searcher = newSearcher(reader);
// search w/ eastern hemisphere geometry that shares the dateline
Polygon searchPoly = new Polygon(new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
new double[] {180d, 180d, 170d, 170d, 180d});
Query q = LatLonShape.newPolygonQuery("test", QueryRelation.INTERSECTS,
searchPoly);
assertEquals(1, searcher.count(q));
IOUtils.close(w, reader, dir);
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8712) Polygon2D does not detect crossings in some cases
[
https://issues.apache.org/jira/browse/LUCENE-8712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16789880#comment-16789880
]
Nicholas Knize commented on LUCENE-8712:
bq. reverts the crossing logic and handles the dateline crossings by skipping
edges that belongs to the dateline
+1. In essence it treats the dateline as +/- INFINITY. I like this approach as
it cleans up the code quite a bit and helps out w/ CONTAINS.
> Polygon2D does not detect crossings in some cases
> -
>
> Key: LUCENE-8712
> URL: https://issues.apache.org/jira/browse/LUCENE-8712
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8712.patch, LUCENE-8712.patch, LUCENE-8712.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Polygon2D does not detect crossing if the triangle crosses through points of
> the polygon and none of the points are inside it. For example:
>
> {code:java}
> public void testLineCrossingPolygonPoints() {
> Polygon p = new Polygon(new double[] {0, -1, 0, 1, 0}, new double[] {-1, 0,
> 1, 0, -1});
> Polygon2D polygon2D = Polygon2D.create(p);
> PointValues.Relation rel =
> polygon2D.relateTriangle(GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(-1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)),
> GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)),
>
> GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(-1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)));
> assertEquals(PointValues.Relation.CELL_CROSSES_QUERY, rel);
> }{code}
> [~nknize] you might want to look at this as I am not sure what to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8712) Polygon2D does not detect crossings in some cases
[
https://issues.apache.org/jira/browse/LUCENE-8712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16784760#comment-16784760
]
Nicholas Knize edited comment on LUCENE-8712 at 3/5/19 6:47 PM:
I took a quick look at this and agree the test case posted exposes a bug in
{{EdgeTree.relateTriangle}}. The problem is in LUCENE-8679 we added a binary
condition that returns {{CELL_OUTSIDE_QUERY}} unless {{insideEdges == 3}}. When
Instead, in the case that {{insideEdges != 3}} but {{insideEdges > 0}} should
return {{CELL_CROSSES}} query.
Another important thing to note, {{GeoUtils.lineRelateLine}} satisfies the
commutative property. So line order does not matter: line 1 terminating at line
2 == line 2 terminating at line 1 == {{CELL_INSIDE_QUERY}} So
{{testLineRelateLine}} will always fail because its assuming order will change
the result.
I've posted a quick patch that corrects the bug posted. There's also some code
refactoring that renames all instances of {{min/max}} {{lat/lon}} for the
triangle to {{triMin/triMax }} {{lat/lon}} to avoid confusion w/ the bounding
box of the polygon.
was (Author: nknize):
I took a quick look at this and agree the test case posted exposes a bug in
{{EdgeTree.relateTriangle}}. The problem is in LUCENE-8679 we added a binary
condition that returns {{CELL_OUTSIDE_QUERY}} unless {{insideEdges == 3}}. When
Instead, in the case that {{insideEdges != 3}} but {{insideEdges > 0}} should
return {{CELL_CROSSES}} query.
Another important thing to note, {{GeoUtils.lineRelateLine}} satisfies the
commutative property. So line order does not matter: line 1 terminating at line
2 == line 2 terminating at line 1 == {{CELL_INSIDE_QUERY}}
I've posted a quick patch that corrects the bug posted. There's also some code
refactoring that renames all instances of {{min/max}} {{lat/lon}} for the
triangle to {{triMin/triMax }} {{lat/lon}} to avoid confusion w/ the bounding
box of the polygon.
> Polygon2D does not detect crossings in some cases
> -
>
> Key: LUCENE-8712
> URL: https://issues.apache.org/jira/browse/LUCENE-8712
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8712.patch, LUCENE-8712.patch
>
>
> Polygon2D does not detect crossing if the triangle crosses through points of
> the polygon and none of the points are inside it. For example:
>
> {code:java}
> public void testLineCrossingPolygonPoints() {
> Polygon p = new Polygon(new double[] {0, -1, 0, 1, 0}, new double[] {-1, 0,
> 1, 0, -1});
> Polygon2D polygon2D = Polygon2D.create(p);
> PointValues.Relation rel =
> polygon2D.relateTriangle(GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(-1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)),
> GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)),
>
> GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(-1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)));
> assertEquals(PointValues.Relation.CELL_CROSSES_QUERY, rel);
> }{code}
> [~nknize] you might want to look at this as I am not sure what to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8712) Polygon2D does not detect crossings in some cases
[
https://issues.apache.org/jira/browse/LUCENE-8712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16784760#comment-16784760
]
Nicholas Knize edited comment on LUCENE-8712 at 3/5/19 6:41 PM:
I took a quick look at this and agree the test case posted exposes a bug in
{{EdgeTree.relateTriangle}}. The problem is in LUCENE-8679 we added a binary
condition that returns {{CELL_OUTSIDE_QUERY}} unless {{insideEdges == 3}}. When
Instead, in the case that {{insideEdges != 3}} but {{insideEdges > 0}} should
return {{CELL_CROSSES}} query.
Another important thing to note, {{GeoUtils.lineRelateLine}} satisfies the
commutative property. So line order does not matter: line 1 terminating at line
2 == line 2 terminating at line 1 == {{CELL_INSIDE_QUERY}}
I've posted a quick patch that corrects the bug posted. There's also some code
refactoring that renames all instances of {{min/max}} {{lat/lon}} for the
triangle to {{triMin/triMax }} {{lat/lon}} to avoid confusion w/ the bounding
box of the polygon.
was (Author: nknize):
I took a quick look at this and agree the test case posted exposes a bug in
{{EdgeTree.relateTriangle}}. The problem is in LUCENE-8679 we added a binary
condition that {{CELL_OUTSIDE_QUERY}} unless {{insideEdges == 3}}. Instead,
{{insideEdges != 3}} but {{insideEdges > 0}} should return {{CELL_CROSSES}}
query.
Another important thing to note, {{GeoUtils.lineRelateLine}} satisfies the
commutative property. So line order does not matter: line 1 terminating at line
2 == line 2 terminating at line 1 == {{CELL_INSIDE_QUERY}}
> Polygon2D does not detect crossings in some cases
> -
>
> Key: LUCENE-8712
> URL: https://issues.apache.org/jira/browse/LUCENE-8712
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8712.patch, LUCENE-8712.patch
>
>
> Polygon2D does not detect crossing if the triangle crosses through points of
> the polygon and none of the points are inside it. For example:
>
> {code:java}
> public void testLineCrossingPolygonPoints() {
> Polygon p = new Polygon(new double[] {0, -1, 0, 1, 0}, new double[] {-1, 0,
> 1, 0, -1});
> Polygon2D polygon2D = Polygon2D.create(p);
> PointValues.Relation rel =
> polygon2D.relateTriangle(GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(-1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)),
> GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)),
>
> GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(-1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)));
> assertEquals(PointValues.Relation.CELL_CROSSES_QUERY, rel);
> }{code}
> [~nknize] you might want to look at this as I am not sure what to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8712) Polygon2D does not detect crossings in some cases
[
https://issues.apache.org/jira/browse/LUCENE-8712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16784760#comment-16784760
]
Nicholas Knize commented on LUCENE-8712:
I took a quick look at this and agree the test case posted exposes a bug in
{{EdgeTree.relateTriangle}}. The problem is in LUCENE-8679 we added a binary
condition that {{CELL_OUTSIDE_QUERY}} unless {{insideEdges == 3}}. Instead,
{{insideEdges != 3}} but {{insideEdges > 0}} should return {{CELL_CROSSES}}
query.
Another important thing to note, {{GeoUtils.lineRelateLine}} satisfies the
commutative property. So line order does not matter: line 1 terminating at line
2 == line 2 terminating at line 1 == {{CELL_INSIDE_QUERY}}
> Polygon2D does not detect crossings in some cases
> -
>
> Key: LUCENE-8712
> URL: https://issues.apache.org/jira/browse/LUCENE-8712
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8712.patch, LUCENE-8712.patch
>
>
> Polygon2D does not detect crossing if the triangle crosses through points of
> the polygon and none of the points are inside it. For example:
>
> {code:java}
> public void testLineCrossingPolygonPoints() {
> Polygon p = new Polygon(new double[] {0, -1, 0, 1, 0}, new double[] {-1, 0,
> 1, 0, -1});
> Polygon2D polygon2D = Polygon2D.create(p);
> PointValues.Relation rel =
> polygon2D.relateTriangle(GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(-1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)),
> GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)),
>
> GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(-1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)));
> assertEquals(PointValues.Relation.CELL_CROSSES_QUERY, rel);
> }{code}
> [~nknize] you might want to look at this as I am not sure what to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8712) Polygon2D does not detect crossings in some cases
[
https://issues.apache.org/jira/browse/LUCENE-8712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-8712:
---
Attachment: LUCENE-8712.patch
> Polygon2D does not detect crossings in some cases
> -
>
> Key: LUCENE-8712
> URL: https://issues.apache.org/jira/browse/LUCENE-8712
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8712.patch, LUCENE-8712.patch
>
>
> Polygon2D does not detect crossing if the triangle crosses through points of
> the polygon and none of the points are inside it. For example:
>
> {code:java}
> public void testLineCrossingPolygonPoints() {
> Polygon p = new Polygon(new double[] {0, -1, 0, 1, 0}, new double[] {-1, 0,
> 1, 0, -1});
> Polygon2D polygon2D = Polygon2D.create(p);
> PointValues.Relation rel =
> polygon2D.relateTriangle(GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(-1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)),
> GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)),
>
> GeoEncodingUtils.decodeLongitude(GeoEncodingUtils.encodeLongitude(-1.5)),
> GeoEncodingUtils.decodeLatitude(GeoEncodingUtils.encodeLatitude(0)));
> assertEquals(PointValues.Relation.CELL_CROSSES_QUERY, rel);
> }{code}
> [~nknize] you might want to look at this as I am not sure what to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8685) Refactor LatLonShape tests
[
https://issues.apache.org/jira/browse/LUCENE-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772040#comment-16772040
]
Nicholas Knize commented on LUCENE-8685:
+1 Sorry for the delay on this and thanks for separating these tests [~ivera]
> Refactor LatLonShape tests
> --
>
> Key: LUCENE-8685
> URL: https://issues.apache.org/jira/browse/LUCENE-8685
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Ignacio Vera
>Priority: Trivial
> Attachments: LUCENE-8685.patch
>
>
> The test class {{TestLatLonShape}} is becoming pretty big and it has a
> mixture of test. I would like to put the test that are focus on the encoding
> in its own test class.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8686) TestTaxonomySumValueSource.testRandom Failure
Nicholas Knize created LUCENE-8686:
--
Summary: TestTaxonomySumValueSource.testRandom Failure
Key: LUCENE-8686
URL: https://issues.apache.org/jira/browse/LUCENE-8686
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 8.x
Reporter: Nicholas Knize
Reproducible test failure:
{{NOTE: reproduce with: ant test -Dtestcase=TestTaxonomyFacetSumValueSource
-Dtests.method=testRandom -Dtests.seed=7F625DA1A252DF8E -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=hu -Dtests.timezone=America/Boa_Vista
-Dtests.asserts=true -Dtests.file.encoding=UTF8}}
Stacktrace:
{code:java}
10:45:46[junit4] FAILURE 0.24s J3 |
TestTaxonomyFacetSumValueSource.testRandom <<<
10:45:46[junit4]> Throwable #1: java.lang.AssertionError: expected:<4>
but was:<3>
10:45:46[junit4]> at
__randomizedtesting.SeedInfo.seed([7F625DA1A252DF8E:D2E78AE133269FD]:0)
10:45:46[junit4]> at
org.apache.lucene.facet.FacetTestCase.assertFloatValuesEquals(FacetTestCase.java:200)
10:45:46[junit4]> at
org.apache.lucene.facet.FacetTestCase.assertFloatValuesEquals(FacetTestCase.java:193)
10:45:46[junit4]> at
org.apache.lucene.facet.taxonomy.TestTaxonomyFacetSumValueSource.testRandom(TestTaxonomyFacetSumValueSource.java:477)
10:45:46[junit4]> at java.lang.Thread.run(Thread.java:748)
10:45:46[junit4] 2> NOTE: test params are: codec=Asserting(Lucene80):
{$full_path$=PostingsFormat(name=Direct),
$facets=PostingsFormat(name=LuceneVarGapDocFreqInterval),
$payloads$=PostingsFormat(name=Direct), f=PostingsFormat(name=LuceneFixedGap),
$facets2=PostingsFormat(name=LuceneFixedGap),
$b=PostingsFormat(name=LuceneFixedGap),
content=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128)))},
docValues:{$facets=DocValuesFormat(name=Asserting),
price=DocValuesFormat(name=Lucene80), num=DocValuesFormat(name=Direct),
$facets2=DocValuesFormat(name=Direct), value=DocValuesFormat(name=Lucene80),
$b=DocValuesFormat(name=Direct)}, maxPointsInLeafNode=1902,
maxMBSortInHeap=6.164841106101889,
sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@27ff3281),
locale=hu, timezone=America/Boa_Vista
10:45:46[junit4] 2> NOTE: Linux 4.15.0-1027-gcp amd64/Oracle Corporation
1.8.0_191 (64-bit)/cpus=16,threads=1,free=394275096,total=523239424
10:45:46[junit4] 2> NOTE: All tests run in this JVM: [TestFacetsConfig,
TestRandomSamplingFacetsCollector, TestTaxonomyFacetSumValueSource]
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8680) Refactor EdgeTree#relateTriangle method
[ https://issues.apache.org/jira/browse/LUCENE-8680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762775#comment-16762775 ] Nicholas Knize commented on LUCENE-8680: +1 Thanks [~ivera]! > Refactor EdgeTree#relateTriangle method > --- > > Key: LUCENE-8680 > URL: https://issues.apache.org/jira/browse/LUCENE-8680 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Priority: Minor > Attachments: LUCENE-8680.patch > > > This proposal moves all the spatial logic for a component to Polygon2D and > Line2D. It improves readability of how each object behaves. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8679) Test failure in LatLonShape
[
https://issues.apache.org/jira/browse/LUCENE-8679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16758448#comment-16758448
]
Nicholas Knize commented on LUCENE-8679:
+1 Thx [~ivera] Ran some further testing and it LGTM.
> Test failure in LatLonShape
> ---
>
> Key: LUCENE-8679
> URL: https://issues.apache.org/jira/browse/LUCENE-8679
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8679.patch, LUCENE-8679.patch
>
>
> Error and reproducible seed:
>
> {code:java}
> [junit4] Suite: org.apache.lucene.document.TestLatLonShape
> [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestLatLonShape
> -Dtests.method=testRandomPolygonEncoding -Dtests.seed=E92F1FD44199EFBE
> -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=no-NO
> -Dtests.timezone=America/North_Dakota/Center -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
> [junit4] FAILURE 0.04s J2 | TestLatLonShape.testRandomPolygonEncoding <<<
> [junit4] > Throwable #1: java.lang.AssertionError
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([E92F1FD44199EFBE:2C3EDB8695100930]:0)
> [junit4] > at
> org.apache.lucene.document.TestLatLonShape.verifyEncoding(TestLatLonShape.java:774)
> [junit4] > at
> org.apache.lucene.document.TestLatLonShape.testRandomPolygonEncoding(TestLatLonShape.java:726)
> [junit4] > at java.lang.Thread.run(Thread.java:748)
> [junit4] 2> NOTE: leaving temporary files on disk at:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/sandbox/test/J2/temp/lucene.document.TestLatLonShape_E92F1FD44199EFBE-001
> [junit4] 2> NOTE: test params are: codec=Asserting(Lucene80): {},
> docValues:{}, maxPointsInLeafNode=1441, maxMBSortInHeap=7.577899936070286,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@419db2df),
> locale=no-NO, timezone=America/North_Dakota/Center
> [junit4] 2> NOTE: Linux 4.4.0-137-generic amd64/Oracle Corporation
> 1.8.0_191 (64-bit)/cpus=4,threads=1,free=168572480,total=309854208
> [junit4] 2> NOTE: All tests run in this JVM: [TestIntervals,
> TestLatLonLineShapeQueries, TestLatLonShape]
> [junit4] Completed [10/27 (1!)] on J2 in 14.55s, 25 tests, 1 failure, 1
> skipped <<< FAILURES!{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8669) LatLonShape WITHIN queries fail with Multiple search Polygons that share the dateline
[
https://issues.apache.org/jira/browse/LUCENE-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize resolved LUCENE-8669.
Resolution: Fixed
> LatLonShape WITHIN queries fail with Multiple search Polygons that share the
> dateline
> -
>
> Key: LUCENE-8669
> URL: https://issues.apache.org/jira/browse/LUCENE-8669
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 8.0, 7.7
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Blocker
> Attachments: LUCENE-8669.patch
>
>
> {{LatLonShape.newPolygonQuery}} does not support dateline crossing polygons.
> It is therefore up to the calling application / user to split dateline
> crossing polygons into a {{MultiPolygon}} query with two search polygons that
> share the dateline. This, however, does not produce expected results because
> {{EdgeTree.internalComponentRelateTriangle}} does not differentiate between a
> triangle that {{CROSSES}} or is {{WITHIN}} the target polygon. Therefore
> {{MultiPolygon}} {{WITHIN}} queries that share the dateline behave as an
> {{INTERSECT}} and will therefore produce incorrect results.
> Consider the following test, for example:
> {code:java}
> // index
> // western poly
> Polygon indexPoly1 = new Polygon(
> new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
> new double[] {-180d, -180d, -176d, -176d, -180d}
> );
> // eastern poly
> Polygon indexPoly2 = new Polygon(
> new double[] {15d, -7.5d, -15d, -10d, 15d, 15d},
> new double[] {180d, 180d, 176d, 174d, 176d, 180d}
> );
> index
> Field[] fields = LatLonShape.createIndexableFields("test", indexPoly1);
> for (Field f : fields) {
> doc.add(f);
> }
> fields = LatLonShape.createIndexableFields("test", indexPoly2);
> for (Field f : fields) {
> doc.add(f);
> }
> writer.addDocument(doc);
> / search //
> Polygon[] searchPoly = new Polygon[] {
> new Polygon(new double[] {-20d, 20d, 20d, -20d, -20d},
> new double[] {-180d, -180d, -170d, -170d, -180d}),
> new Polygon(new double[] {20d, -20d, -20d, 20d, 20d},
> new double[] {180d, 180d, 170d, 170d, 180d})
> };
> Query q = LatLonShape.newPolygonQuery("test", QueryRelation.WITHIN,
> searchPoly);
> assertEquals(1, searcher.count(q));
> {code}
>
> In the example above, a dateline spanning polygon is indexed as a
> {{MultiPolygon}} with two polygons that share the dateline. Similarly, a
> polygon that spans the dateline is provided as two polygons that share the
> dateline in a {{WITHIN}} query. The indexed polygon should be returned as a
> match; but it does not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8669) LatLonShape WITHIN queries fail with Multiple search Polygons that share the dateline
[
https://issues.apache.org/jira/browse/LUCENE-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757765#comment-16757765
]
Nicholas Knize commented on LUCENE-8669:
Thanks [~ivera] I agree on the testing. With this one being a blocker I'll go
ahead and commit as is then add some more thorough randomized testing beyond
the simple explicit testing that is provided.
> LatLonShape WITHIN queries fail with Multiple search Polygons that share the
> dateline
> -
>
> Key: LUCENE-8669
> URL: https://issues.apache.org/jira/browse/LUCENE-8669
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 8.0, 7.7
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Blocker
> Attachments: LUCENE-8669.patch
>
>
> {{LatLonShape.newPolygonQuery}} does not support dateline crossing polygons.
> It is therefore up to the calling application / user to split dateline
> crossing polygons into a {{MultiPolygon}} query with two search polygons that
> share the dateline. This, however, does not produce expected results because
> {{EdgeTree.internalComponentRelateTriangle}} does not differentiate between a
> triangle that {{CROSSES}} or is {{WITHIN}} the target polygon. Therefore
> {{MultiPolygon}} {{WITHIN}} queries that share the dateline behave as an
> {{INTERSECT}} and will therefore produce incorrect results.
> Consider the following test, for example:
> {code:java}
> // index
> // western poly
> Polygon indexPoly1 = new Polygon(
> new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
> new double[] {-180d, -180d, -176d, -176d, -180d}
> );
> // eastern poly
> Polygon indexPoly2 = new Polygon(
> new double[] {15d, -7.5d, -15d, -10d, 15d, 15d},
> new double[] {180d, 180d, 176d, 174d, 176d, 180d}
> );
> index
> Field[] fields = LatLonShape.createIndexableFields("test", indexPoly1);
> for (Field f : fields) {
> doc.add(f);
> }
> fields = LatLonShape.createIndexableFields("test", indexPoly2);
> for (Field f : fields) {
> doc.add(f);
> }
> writer.addDocument(doc);
> / search //
> Polygon[] searchPoly = new Polygon[] {
> new Polygon(new double[] {-20d, 20d, 20d, -20d, -20d},
> new double[] {-180d, -180d, -170d, -170d, -180d}),
> new Polygon(new double[] {20d, -20d, -20d, 20d, 20d},
> new double[] {180d, 180d, 170d, 170d, 180d})
> };
> Query q = LatLonShape.newPolygonQuery("test", QueryRelation.WITHIN,
> searchPoly);
> assertEquals(1, searcher.count(q));
> {code}
>
> In the example above, a dateline spanning polygon is indexed as a
> {{MultiPolygon}} with two polygons that share the dateline. Similarly, a
> polygon that spans the dateline is provided as two polygons that share the
> dateline in a {{WITHIN}} query. The indexed polygon should be returned as a
> match; but it does not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8669) LatLonShape WITHIN queries fail with Multiple search Polygons that share the dateline
[
https://issues.apache.org/jira/browse/LUCENE-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-8669:
---
Affects Version/s: (was: 7.6)
7.7
8.0
> LatLonShape WITHIN queries fail with Multiple search Polygons that share the
> dateline
> -
>
> Key: LUCENE-8669
> URL: https://issues.apache.org/jira/browse/LUCENE-8669
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 8.0, 7.7
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Blocker
> Attachments: LUCENE-8669.patch
>
>
> {{LatLonShape.newPolygonQuery}} does not support dateline crossing polygons.
> It is therefore up to the calling application / user to split dateline
> crossing polygons into a {{MultiPolygon}} query with two search polygons that
> share the dateline. This, however, does not produce expected results because
> {{EdgeTree.internalComponentRelateTriangle}} does not differentiate between a
> triangle that {{CROSSES}} or is {{WITHIN}} the target polygon. Therefore
> {{MultiPolygon}} {{WITHIN}} queries that share the dateline behave as an
> {{INTERSECT}} and will therefore produce incorrect results.
> Consider the following test, for example:
> {code:java}
> // index
> // western poly
> Polygon indexPoly1 = new Polygon(
> new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
> new double[] {-180d, -180d, -176d, -176d, -180d}
> );
> // eastern poly
> Polygon indexPoly2 = new Polygon(
> new double[] {15d, -7.5d, -15d, -10d, 15d, 15d},
> new double[] {180d, 180d, 176d, 174d, 176d, 180d}
> );
> index
> Field[] fields = LatLonShape.createIndexableFields("test", indexPoly1);
> for (Field f : fields) {
> doc.add(f);
> }
> fields = LatLonShape.createIndexableFields("test", indexPoly2);
> for (Field f : fields) {
> doc.add(f);
> }
> writer.addDocument(doc);
> / search //
> Polygon[] searchPoly = new Polygon[] {
> new Polygon(new double[] {-20d, 20d, 20d, -20d, -20d},
> new double[] {-180d, -180d, -170d, -170d, -180d}),
> new Polygon(new double[] {20d, -20d, -20d, 20d, 20d},
> new double[] {180d, 180d, 170d, 170d, 180d})
> };
> Query q = LatLonShape.newPolygonQuery("test", QueryRelation.WITHIN,
> searchPoly);
> assertEquals(1, searcher.count(q));
> {code}
>
> In the example above, a dateline spanning polygon is indexed as a
> {{MultiPolygon}} with two polygons that share the dateline. Similarly, a
> polygon that spans the dateline is provided as two polygons that share the
> dateline in a {{WITHIN}} query. The indexed polygon should be returned as a
> match; but it does not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8669) LatLonShape WITHIN queries fail with Multiple search Polygons that share the dateline
[
https://issues.apache.org/jira/browse/LUCENE-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-8669:
---
Priority: Blocker (was: Major)
> LatLonShape WITHIN queries fail with Multiple search Polygons that share the
> dateline
> -
>
> Key: LUCENE-8669
> URL: https://issues.apache.org/jira/browse/LUCENE-8669
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.6
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Blocker
> Attachments: LUCENE-8669.patch
>
>
> {{LatLonShape.newPolygonQuery}} does not support dateline crossing polygons.
> It is therefore up to the calling application / user to split dateline
> crossing polygons into a {{MultiPolygon}} query with two search polygons that
> share the dateline. This, however, does not produce expected results because
> {{EdgeTree.internalComponentRelateTriangle}} does not differentiate between a
> triangle that {{CROSSES}} or is {{WITHIN}} the target polygon. Therefore
> {{MultiPolygon}} {{WITHIN}} queries that share the dateline behave as an
> {{INTERSECT}} and will therefore produce incorrect results.
> Consider the following test, for example:
> {code:java}
> // index
> // western poly
> Polygon indexPoly1 = new Polygon(
> new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
> new double[] {-180d, -180d, -176d, -176d, -180d}
> );
> // eastern poly
> Polygon indexPoly2 = new Polygon(
> new double[] {15d, -7.5d, -15d, -10d, 15d, 15d},
> new double[] {180d, 180d, 176d, 174d, 176d, 180d}
> );
> index
> Field[] fields = LatLonShape.createIndexableFields("test", indexPoly1);
> for (Field f : fields) {
> doc.add(f);
> }
> fields = LatLonShape.createIndexableFields("test", indexPoly2);
> for (Field f : fields) {
> doc.add(f);
> }
> writer.addDocument(doc);
> / search //
> Polygon[] searchPoly = new Polygon[] {
> new Polygon(new double[] {-20d, 20d, 20d, -20d, -20d},
> new double[] {-180d, -180d, -170d, -170d, -180d}),
> new Polygon(new double[] {20d, -20d, -20d, 20d, 20d},
> new double[] {180d, 180d, 170d, 170d, 180d})
> };
> Query q = LatLonShape.newPolygonQuery("test", QueryRelation.WITHIN,
> searchPoly);
> assertEquals(1, searcher.count(q));
> {code}
>
> In the example above, a dateline spanning polygon is indexed as a
> {{MultiPolygon}} with two polygons that share the dateline. Similarly, a
> polygon that spans the dateline is provided as two polygons that share the
> dateline in a {{WITHIN}} query. The indexed polygon should be returned as a
> match; but it does not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-8670) Add LatLonShapePointQuery to support Point / MultiPoint queries on indexed LatLonShape fields
[
https://issues.apache.org/jira/browse/LUCENE-8670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize reassigned LUCENE-8670:
--
Assignee: Nicholas Knize
> Add LatLonShapePointQuery to support Point / MultiPoint queries on indexed
> LatLonShape fields
> -
>
> Key: LUCENE-8670
> URL: https://issues.apache.org/jira/browse/LUCENE-8670
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8670.patch
>
>
> Similar to {{LatLonShapeBoundingBoxQuery}}, {{LatLonShapeLineQuery}}, and
> {{LatLonShapePolygonQuery}} this introduces {{LatLonShapePointQuery}} that
> will return all indexed {{LatLonShape}} fields that intersect the provided
> point(s). {{MultiPoint}} is supported by providing an array of points.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8670) Add LatLonShapePointQuery to support Point / MultiPoint queries on indexed LatLonShape fields
Nicholas Knize created LUCENE-8670:
--
Summary: Add LatLonShapePointQuery to support Point / MultiPoint
queries on indexed LatLonShape fields
Key: LUCENE-8670
URL: https://issues.apache.org/jira/browse/LUCENE-8670
Project: Lucene - Core
Issue Type: Improvement
Reporter: Nicholas Knize
Similar to {{LatLonShapeBoundingBoxQuery}}, {{LatLonShapeLineQuery}}, and
{{LatLonShapePolygonQuery}} this introduces {{LatLonShapePointQuery}} that will
return all indexed {{LatLonShape}} fields that intersect the provided point(s).
{{MultiPoint}} is supported by providing an array of points.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8669) LatLonShape WITHIN queries fail with Multiple search Polygons that share the dateline
[
https://issues.apache.org/jira/browse/LUCENE-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-8669:
---
Affects Version/s: (was: 7.7)
7.6
> LatLonShape WITHIN queries fail with Multiple search Polygons that share the
> dateline
> -
>
> Key: LUCENE-8669
> URL: https://issues.apache.org/jira/browse/LUCENE-8669
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.6
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8669.patch
>
>
> {{LatLonShape.newPolygonQuery}} does not support dateline crossing polygons.
> It is therefore up to the calling application / user to split dateline
> crossing polygons into a {{MultiPolygon}} query with two search polygons that
> share the dateline. This, however, does not produce expected results because
> {{EdgeTree.internalComponentRelateTriangle}} does not differentiate between a
> triangle that {{CROSSES}} or is {{WITHIN}} the target polygon. Therefore
> {{MultiPolygon}} {{WITHIN}} queries that share the dateline behave as an
> {{INTERSECT}} and will therefore produce incorrect results.
> Consider the following test, for example:
> {code:java}
> // index
> // western poly
> Polygon indexPoly1 = new Polygon(
> new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
> new double[] {-180d, -180d, -176d, -176d, -180d}
> );
> // eastern poly
> Polygon indexPoly2 = new Polygon(
> new double[] {15d, -7.5d, -15d, -10d, 15d, 15d},
> new double[] {180d, 180d, 176d, 174d, 176d, 180d}
> );
> index
> Field[] fields = LatLonShape.createIndexableFields("test", indexPoly1);
> for (Field f : fields) {
> doc.add(f);
> }
> fields = LatLonShape.createIndexableFields("test", indexPoly2);
> for (Field f : fields) {
> doc.add(f);
> }
> writer.addDocument(doc);
> / search //
> Polygon[] searchPoly = new Polygon[] {
> new Polygon(new double[] {-20d, 20d, 20d, -20d, -20d},
> new double[] {-180d, -180d, -170d, -170d, -180d}),
> new Polygon(new double[] {20d, -20d, -20d, 20d, 20d},
> new double[] {180d, 180d, 170d, 170d, 180d})
> };
> Query q = LatLonShape.newPolygonQuery("test", QueryRelation.WITHIN,
> searchPoly);
> assertEquals(1, searcher.count(q));
> {code}
>
> In the example above, a dateline spanning polygon is indexed as a
> {{MultiPolygon}} with two polygons that share the dateline. Similarly, a
> polygon that spans the dateline is provided as two polygons that share the
> dateline in a {{WITHIN}} query. The indexed polygon should be returned as a
> match; but it does not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8669) LatLonShape WITHIN queries fail with Multiple search Polygons that share the dateline
[
https://issues.apache.org/jira/browse/LUCENE-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-8669:
---
Priority: Major (was: Blocker)
> LatLonShape WITHIN queries fail with Multiple search Polygons that share the
> dateline
> -
>
> Key: LUCENE-8669
> URL: https://issues.apache.org/jira/browse/LUCENE-8669
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.7
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8669.patch
>
>
> {{LatLonShape.newPolygonQuery}} does not support dateline crossing polygons.
> It is therefore up to the calling application / user to split dateline
> crossing polygons into a {{MultiPolygon}} query with two search polygons that
> share the dateline. This, however, does not produce expected results because
> {{EdgeTree.internalComponentRelateTriangle}} does not differentiate between a
> triangle that {{CROSSES}} or is {{WITHIN}} the target polygon. Therefore
> {{MultiPolygon}} {{WITHIN}} queries that share the dateline behave as an
> {{INTERSECT}} and will therefore produce incorrect results.
> Consider the following test, for example:
> {code:java}
> // index
> // western poly
> Polygon indexPoly1 = new Polygon(
> new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
> new double[] {-180d, -180d, -176d, -176d, -180d}
> );
> // eastern poly
> Polygon indexPoly2 = new Polygon(
> new double[] {15d, -7.5d, -15d, -10d, 15d, 15d},
> new double[] {180d, 180d, 176d, 174d, 176d, 180d}
> );
> index
> Field[] fields = LatLonShape.createIndexableFields("test", indexPoly1);
> for (Field f : fields) {
> doc.add(f);
> }
> fields = LatLonShape.createIndexableFields("test", indexPoly2);
> for (Field f : fields) {
> doc.add(f);
> }
> writer.addDocument(doc);
> / search //
> Polygon[] searchPoly = new Polygon[] {
> new Polygon(new double[] {-20d, 20d, 20d, -20d, -20d},
> new double[] {-180d, -180d, -170d, -170d, -180d}),
> new Polygon(new double[] {20d, -20d, -20d, 20d, 20d},
> new double[] {180d, 180d, 170d, 170d, 180d})
> };
> Query q = LatLonShape.newPolygonQuery("test", QueryRelation.WITHIN,
> searchPoly);
> assertEquals(1, searcher.count(q));
> {code}
>
> In the example above, a dateline spanning polygon is indexed as a
> {{MultiPolygon}} with two polygons that share the dateline. Similarly, a
> polygon that spans the dateline is provided as two polygons that share the
> dateline in a {{WITHIN}} query. The indexed polygon should be returned as a
> match; but it does not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8669) LatLonShape WITHIN queries fail with Multiple search Polygons that share the dateline
[
https://issues.apache.org/jira/browse/LUCENE-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-8669:
---
Affects Version/s: 7.7
> LatLonShape WITHIN queries fail with Multiple search Polygons that share the
> dateline
> -
>
> Key: LUCENE-8669
> URL: https://issues.apache.org/jira/browse/LUCENE-8669
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.7
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Blocker
> Attachments: LUCENE-8669.patch
>
>
> {{LatLonShape.newPolygonQuery}} does not support dateline crossing polygons.
> It is therefore up to the calling application / user to split dateline
> crossing polygons into a {{MultiPolygon}} query with two search polygons that
> share the dateline. This, however, does not produce expected results because
> {{EdgeTree.internalComponentRelateTriangle}} does not differentiate between a
> triangle that {{CROSSES}} or is {{WITHIN}} the target polygon. Therefore
> {{MultiPolygon}} {{WITHIN}} queries that share the dateline behave as an
> {{INTERSECT}} and will therefore produce incorrect results.
> Consider the following test, for example:
> {code:java}
> // index
> // western poly
> Polygon indexPoly1 = new Polygon(
> new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
> new double[] {-180d, -180d, -176d, -176d, -180d}
> );
> // eastern poly
> Polygon indexPoly2 = new Polygon(
> new double[] {15d, -7.5d, -15d, -10d, 15d, 15d},
> new double[] {180d, 180d, 176d, 174d, 176d, 180d}
> );
> index
> Field[] fields = LatLonShape.createIndexableFields("test", indexPoly1);
> for (Field f : fields) {
> doc.add(f);
> }
> fields = LatLonShape.createIndexableFields("test", indexPoly2);
> for (Field f : fields) {
> doc.add(f);
> }
> writer.addDocument(doc);
> / search //
> Polygon[] searchPoly = new Polygon[] {
> new Polygon(new double[] {-20d, 20d, 20d, -20d, -20d},
> new double[] {-180d, -180d, -170d, -170d, -180d}),
> new Polygon(new double[] {20d, -20d, -20d, 20d, 20d},
> new double[] {180d, 180d, 170d, 170d, 180d})
> };
> Query q = LatLonShape.newPolygonQuery("test", QueryRelation.WITHIN,
> searchPoly);
> assertEquals(1, searcher.count(q));
> {code}
>
> In the example above, a dateline spanning polygon is indexed as a
> {{MultiPolygon}} with two polygons that share the dateline. Similarly, a
> polygon that spans the dateline is provided as two polygons that share the
> dateline in a {{WITHIN}} query. The indexed polygon should be returned as a
> match; but it does not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-8669) LatLonShape WITHIN queries fail with Multiple search Polygons that share the dateline
[
https://issues.apache.org/jira/browse/LUCENE-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize reassigned LUCENE-8669:
--
Assignee: Nicholas Knize
> LatLonShape WITHIN queries fail with Multiple search Polygons that share the
> dateline
> -
>
> Key: LUCENE-8669
> URL: https://issues.apache.org/jira/browse/LUCENE-8669
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8669.patch
>
>
> {{LatLonShape.newPolygonQuery}} does not support dateline crossing polygons.
> It is therefore up to the calling application / user to split dateline
> crossing polygons into a {{MultiPolygon}} query with two search polygons that
> share the dateline. This, however, does not produce expected results because
> {{EdgeTree.internalComponentRelateTriangle}} does not differentiate between a
> triangle that {{CROSSES}} or is {{WITHIN}} the target polygon. Therefore
> {{MultiPolygon}} {{WITHIN}} queries that share the dateline behave as an
> {{INTERSECT}} and will therefore produce incorrect results.
> Consider the following test, for example:
> {code:java}
> // index
> // western poly
> Polygon indexPoly1 = new Polygon(
> new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
> new double[] {-180d, -180d, -176d, -176d, -180d}
> );
> // eastern poly
> Polygon indexPoly2 = new Polygon(
> new double[] {15d, -7.5d, -15d, -10d, 15d, 15d},
> new double[] {180d, 180d, 176d, 174d, 176d, 180d}
> );
> index
> Field[] fields = LatLonShape.createIndexableFields("test", indexPoly1);
> for (Field f : fields) {
> doc.add(f);
> }
> fields = LatLonShape.createIndexableFields("test", indexPoly2);
> for (Field f : fields) {
> doc.add(f);
> }
> writer.addDocument(doc);
> / search //
> Polygon[] searchPoly = new Polygon[] {
> new Polygon(new double[] {-20d, 20d, 20d, -20d, -20d},
> new double[] {-180d, -180d, -170d, -170d, -180d}),
> new Polygon(new double[] {20d, -20d, -20d, 20d, 20d},
> new double[] {180d, 180d, 170d, 170d, 180d})
> };
> Query q = LatLonShape.newPolygonQuery("test", QueryRelation.WITHIN,
> searchPoly);
> assertEquals(1, searcher.count(q));
> {code}
>
> In the example above, a dateline spanning polygon is indexed as a
> {{MultiPolygon}} with two polygons that share the dateline. Similarly, a
> polygon that spans the dateline is provided as two polygons that share the
> dateline in a {{WITHIN}} query. The indexed polygon should be returned as a
> match; but it does not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8669) LatLonShape WITHIN queries fail with Multiple search Polygons that share the dateline
[
https://issues.apache.org/jira/browse/LUCENE-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-8669:
---
Priority: Blocker (was: Major)
> LatLonShape WITHIN queries fail with Multiple search Polygons that share the
> dateline
> -
>
> Key: LUCENE-8669
> URL: https://issues.apache.org/jira/browse/LUCENE-8669
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Blocker
> Attachments: LUCENE-8669.patch
>
>
> {{LatLonShape.newPolygonQuery}} does not support dateline crossing polygons.
> It is therefore up to the calling application / user to split dateline
> crossing polygons into a {{MultiPolygon}} query with two search polygons that
> share the dateline. This, however, does not produce expected results because
> {{EdgeTree.internalComponentRelateTriangle}} does not differentiate between a
> triangle that {{CROSSES}} or is {{WITHIN}} the target polygon. Therefore
> {{MultiPolygon}} {{WITHIN}} queries that share the dateline behave as an
> {{INTERSECT}} and will therefore produce incorrect results.
> Consider the following test, for example:
> {code:java}
> // index
> // western poly
> Polygon indexPoly1 = new Polygon(
> new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
> new double[] {-180d, -180d, -176d, -176d, -180d}
> );
> // eastern poly
> Polygon indexPoly2 = new Polygon(
> new double[] {15d, -7.5d, -15d, -10d, 15d, 15d},
> new double[] {180d, 180d, 176d, 174d, 176d, 180d}
> );
> index
> Field[] fields = LatLonShape.createIndexableFields("test", indexPoly1);
> for (Field f : fields) {
> doc.add(f);
> }
> fields = LatLonShape.createIndexableFields("test", indexPoly2);
> for (Field f : fields) {
> doc.add(f);
> }
> writer.addDocument(doc);
> / search //
> Polygon[] searchPoly = new Polygon[] {
> new Polygon(new double[] {-20d, 20d, 20d, -20d, -20d},
> new double[] {-180d, -180d, -170d, -170d, -180d}),
> new Polygon(new double[] {20d, -20d, -20d, 20d, 20d},
> new double[] {180d, 180d, 170d, 170d, 180d})
> };
> Query q = LatLonShape.newPolygonQuery("test", QueryRelation.WITHIN,
> searchPoly);
> assertEquals(1, searcher.count(q));
> {code}
>
> In the example above, a dateline spanning polygon is indexed as a
> {{MultiPolygon}} with two polygons that share the dateline. Similarly, a
> polygon that spans the dateline is provided as two polygons that share the
> dateline in a {{WITHIN}} query. The indexed polygon should be returned as a
> match; but it does not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8669) LatLonShape WITHIN queries fail with Multiple search Polygons that share the dateline
[
https://issues.apache.org/jira/browse/LUCENE-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-8669:
---
Issue Type: Bug (was: Improvement)
> LatLonShape WITHIN queries fail with Multiple search Polygons that share the
> dateline
> -
>
> Key: LUCENE-8669
> URL: https://issues.apache.org/jira/browse/LUCENE-8669
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Priority: Major
>
> {{LatLonShape.newPolygonQuery}} does not support dateline crossing polygons.
> It is therefore up to the calling application / user to split dateline
> crossing polygons into a {{MultiPolygon}} query with two search polygons that
> share the dateline. This, however, does not produce expected results because
> {{EdgeTree.internalComponentRelateTriangle}} does not differentiate between a
> triangle that {{CROSSES}} or is {{WITHIN}} the target polygon. Therefore
> {{MultiPolygon}} {{WITHIN}} queries that share the dateline behave as an
> {{INTERSECT}} and will therefore produce incorrect results.
> Consider the following test, for example:
> {code:java}
> // index
> // western poly
> Polygon indexPoly1 = new Polygon(
> new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
> new double[] {-180d, -180d, -176d, -176d, -180d}
> );
> // eastern poly
> Polygon indexPoly2 = new Polygon(
> new double[] {15d, -7.5d, -15d, -10d, 15d, 15d},
> new double[] {180d, 180d, 176d, 174d, 176d, 180d}
> );
> index
> Field[] fields = LatLonShape.createIndexableFields("test", indexPoly1);
> for (Field f : fields) {
> doc.add(f);
> }
> fields = LatLonShape.createIndexableFields("test", indexPoly2);
> for (Field f : fields) {
> doc.add(f);
> }
> writer.addDocument(doc);
> / search //
> Polygon[] searchPoly = new Polygon[] {
> new Polygon(new double[] {-20d, 20d, 20d, -20d, -20d},
> new double[] {-180d, -180d, -170d, -170d, -180d}),
> new Polygon(new double[] {20d, -20d, -20d, 20d, 20d},
> new double[] {180d, 180d, 170d, 170d, 180d})
> };
> Query q = LatLonShape.newPolygonQuery("test", QueryRelation.WITHIN,
> searchPoly);
> assertEquals(1, searcher.count(q));
> {code}
>
> In the example above, a dateline spanning polygon is indexed as a
> {{MultiPolygon}} with two polygons that share the dateline. Similarly, a
> polygon that spans the dateline is provided as two polygons that share the
> dateline in a {{WITHIN}} query. The indexed polygon should be returned as a
> match; but it does not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8669) LatLonShape WITHIN queries fail with Multiple search Polygons that share the dateline
Nicholas Knize created LUCENE-8669:
--
Summary: LatLonShape WITHIN queries fail with Multiple search
Polygons that share the dateline
Key: LUCENE-8669
URL: https://issues.apache.org/jira/browse/LUCENE-8669
Project: Lucene - Core
Issue Type: Improvement
Reporter: Nicholas Knize
{{LatLonShape.newPolygonQuery}} does not support dateline crossing polygons. It
is therefore up to the calling application / user to split dateline crossing
polygons into a {{MultiPolygon}} query with two search polygons that share the
dateline. This, however, does not produce expected results because
{{EdgeTree.internalComponentRelateTriangle}} does not differentiate between a
triangle that {{CROSSES}} or is {{WITHIN}} the target polygon. Therefore
{{MultiPolygon}} {{WITHIN}} queries that share the dateline behave as an
{{INTERSECT}} and will therefore produce incorrect results.
Consider the following test, for example:
{code:java}
// index
// western poly
Polygon indexPoly1 = new Polygon(
new double[] {-7.5d, 15d, 15d, 0d, -7.5d},
new double[] {-180d, -180d, -176d, -176d, -180d}
);
// eastern poly
Polygon indexPoly2 = new Polygon(
new double[] {15d, -7.5d, -15d, -10d, 15d, 15d},
new double[] {180d, 180d, 176d, 174d, 176d, 180d}
);
index
Field[] fields = LatLonShape.createIndexableFields("test", indexPoly1);
for (Field f : fields) {
doc.add(f);
}
fields = LatLonShape.createIndexableFields("test", indexPoly2);
for (Field f : fields) {
doc.add(f);
}
writer.addDocument(doc);
/ search //
Polygon[] searchPoly = new Polygon[] {
new Polygon(new double[] {-20d, 20d, 20d, -20d, -20d},
new double[] {-180d, -180d, -170d, -170d, -180d}),
new Polygon(new double[] {20d, -20d, -20d, 20d, 20d},
new double[] {180d, 180d, 170d, 170d, 180d})
};
Query q = LatLonShape.newPolygonQuery("test", QueryRelation.WITHIN,
searchPoly);
assertEquals(1, searcher.count(q));
{code}
In the example above, a dateline spanning polygon is indexed as a
{{MultiPolygon}} with two polygons that share the dateline. Similarly, a
polygon that spans the dateline is provided as two polygons that share the
dateline in a {{WITHIN}} query. The indexed polygon should be returned as a
match; but it does not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8634) LatLonShape: Query with the same polygon that is indexed might not match
[
https://issues.apache.org/jira/browse/LUCENE-8634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752482#comment-16752482
]
Nicholas Knize commented on LUCENE-8634:
For clarity I'll separate the issues being discussed here:
1. Sub centimeter polygons: I think we document the spatial resolution of the
encoding fairly well. 1e-7 dec deg ~= 1.11cm. Any polygon defined with vertex
distances <= 1e-7 dec deg (like the one in the example here) should not be
expected to index with the same accuracy as provided. So subcentimeter polygons
in the WGS84 lat/lon projection are not supported and may result in an
unexpected invalid shape. This is why I opened LUCENE-8632 to lay groundwork
for alternative projections. If a user wants to index subcentimeter shapes they
should do so using the right spatial reference system for the job.
2. "Should we keep lines and polygons in the encoded space like boxes?"
So I made a simple decision (occam's razor) when handling this in the first
iteration of development. For point, line, and polygon query, rather than
quantize the search shape in the query constructor (like BoundingBox does) I
quantized the query shape in the test before invoking the query. Right or wrong
I chose this route for two reasons: a. consistency with
{{LatLonPointInPolygonQuery}} which we discussed this topic at length across
several issues, and b. we have no formal support for the EqualTo relation
operation, only INTERSECT, DISJOINT, WITHIN. In hindsight INTERSECT does fill
this void so a false negative using INTERSECT query on an indexed shape that is
equalTo the query shape could/should probably be considered a bug. Furthermore,
{{LatLonPointInPolygonQuery}} doesn't have the complexities to contend with
like relating lines and polygons. I think this change probably deserves a bit
more thought / consideration.
> LatLonShape: Query with the same polygon that is indexed might not match
>
>
> Key: LUCENE-8634
> URL: https://issues.apache.org/jira/browse/LUCENE-8634
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/sandbox
>Affects Versions: 8.0, 7.7, master (9.0)
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8634.patch, LUCENE-8634.patch
>
>
> If a polygon with a degenerated dimension is indexed and then an intersect
> query is performed with the same polygon, it might result in an empty result.
> For example this polygon with degenerated longitude:
> POLYGON((1.401298464324817E-45 22.0, 1.401298464324817E-45 69.0,
> 4.8202184588118395E-40 69.0, 4.8202184588118395E-40 22.0,
> 1.401298464324817E-45 22.0))
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8620) Add CONTAINS support for LatLonShape
[
https://issues.apache.org/jira/browse/LUCENE-8620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-8620:
---
Fix Version/s: 7.7
8.0
> Add CONTAINS support for LatLonShape
>
>
> Key: LUCENE-8620
> URL: https://issues.apache.org/jira/browse/LUCENE-8620
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Fix For: 8.0, 7.7
>
> Attachments: LUCENE-8620.patch
>
>
> Currently the only spatial operation that cannot be performed using
> {{LatLonShape}} is CONTAINS. This issue will add such capability by tracking
> if an edge of a generated triangle from the {{Tessellator}} is an edge of the
> polygon.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-8632) Adapt LatLonShape tessellator to non-geo shapes
[ https://issues.apache.org/jira/browse/LUCENE-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize reassigned LUCENE-8632: -- Assignee: Nicholas Knize > Adapt LatLonShape tessellator to non-geo shapes > --- > > Key: LUCENE-8632 > URL: https://issues.apache.org/jira/browse/LUCENE-8632 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Nicholas Knize >Assignee: Nicholas Knize >Priority: Major > > Currently the tessellator is tightly coupled with latitude and longitude > (WGS84) geospatial coordinates. This issue will explore generalizing the > tessellator to non geospatial coordinate systems so lucene can handle > arbitrary projections in vector space. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8632) Adapt LatLonShape tessellator to non-geo shapes
Nicholas Knize created LUCENE-8632: -- Summary: Adapt LatLonShape tessellator to non-geo shapes Key: LUCENE-8632 URL: https://issues.apache.org/jira/browse/LUCENE-8632 Project: Lucene - Core Issue Type: New Feature Reporter: Nicholas Knize Currently the tessellator is tightly coupled with latitude and longitude (WGS84) geospatial coordinates. This issue will explore generalizing the tessellator to non geospatial coordinate systems so lucene can handle arbitrary projections in vector space. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8621) Move LatLonShape out of sandbox
[ https://issues.apache.org/jira/browse/LUCENE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732616#comment-16732616 ] Nicholas Knize commented on LUCENE-8621: Ah. Thank you [~dsmiley] I had forgotten about that issue. +1 for the removal to be done for 8.0 > Move LatLonShape out of sandbox > --- > > Key: LUCENE-8621 > URL: https://issues.apache.org/jira/browse/LUCENE-8621 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > > LatLonShape has matured a lot over the last months, I'd like to start > thinking about moving it out of sandbox so that it doesn't stay there for too > long like what happened to LatLonPoint. I am pretty happy with the current > encoding. To my knowledge, we might just need to do a minor modification > because of > LUCENE-8620. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8621) Move LatLonShape out of sandbox
[
https://issues.apache.org/jira/browse/LUCENE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732295#comment-16732295
]
Nicholas Knize edited comment on LUCENE-8621 at 1/2/19 6:33 PM:
+1
I can take this one. I vote:
# Move {{LatLonShape}} to {{core}} as a companion to {{LatLonPoint}}
# In a separate issue, refactor (or remove where appropriate) the two
remaining classes ( {{GeoRelationUtils}} && {{MortonEncoder}} ) from the
{{spatial}} module to either the {{core}} or {{spatial-extras module}}
# Remove the {{spatial}} module
We can do the refactor for 8.0 and keep it in sandbox for 7.7 leaving the 7.x
line consistent?
was (Author: nknize):
+1
I can take this one. I vote:
# Move {{LatLonShape}} to {{core}} as a companion to {{LatLonPoint}}
# In a separate issue, refactor (or remove where appropriate) the two
remaining classes ({{GeoRelationUtils && {{MortonEncoder) from the
{{spatial}} module to either the {{core}} or {{spatial-extras module}}
# Remove the {{spatial}} module
We can do the refactor for 8.0 and keep it in sandbox for 7.7 leaving the 7.x
line consistent?
> Move LatLonShape out of sandbox
> ---
>
> Key: LUCENE-8621
> URL: https://issues.apache.org/jira/browse/LUCENE-8621
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> LatLonShape has matured a lot over the last months, I'd like to start
> thinking about moving it out of sandbox so that it doesn't stay there for too
> long like what happened to LatLonPoint. I am pretty happy with the current
> encoding. To my knowledge, we might just need to do a minor modification
> because of
> LUCENE-8620.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8621) Move LatLonShape out of sandbox
[
https://issues.apache.org/jira/browse/LUCENE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732295#comment-16732295
]
Nicholas Knize commented on LUCENE-8621:
+1
I can take this one. I vote:
# Move {{LatLonShape}} to {{core}} as a companion to {{LatLonPoint}}
# In a separate issue, refactor (or remove where appropriate) the two
remaining classes ({{GeoRelationUtils && {{MortonEncoder) from the
{{spatial}} module to either the {{core}} or {{spatial-extras module}}
# Remove the {{spatial}} module
We can do the refactor for 8.0 and keep it in sandbox for 7.7 leaving the 7.x
line consistent?
> Move LatLonShape out of sandbox
> ---
>
> Key: LUCENE-8621
> URL: https://issues.apache.org/jira/browse/LUCENE-8621
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> LatLonShape has matured a lot over the last months, I'd like to start
> thinking about moving it out of sandbox so that it doesn't stay there for too
> long like what happened to LatLonPoint. I am pretty happy with the current
> encoding. To my knowledge, we might just need to do a minor modification
> because of
> LUCENE-8620.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-8581) Change LatLonShape encoding to use 4 BYTES Per Dimension
[
https://issues.apache.org/jira/browse/LUCENE-8581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize reassigned LUCENE-8581:
--
Assignee: Ignacio Vera (was: Nicholas Knize)
> Change LatLonShape encoding to use 4 BYTES Per Dimension
>
>
> Key: LUCENE-8581
> URL: https://issues.apache.org/jira/browse/LUCENE-8581
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch,
> LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch,
> LUCENE-8581.patch
>
>
> {{LatLonShape}} tessellated triangles currently use a relatively naive
> encoding with the first four dimensions as the bounding box of the triangle
> and the last three dimensions as the vertices of the triangle. To encode the
> {{x,y}} vertices in the last three dimensions requires {{bytesPerDim}} to be
> set to 8, with 4 bytes for the x & y axis, respectively. We can reduce
> {{bytesPerDim}} to 4 by encoding the index(es) of the vertices shared by the
> bounding box along with the orientation of the triangle. This also opens the
> door for supporting {{CONTAINS}} queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8581) Change LatLonShape encoding to use 4 BYTES Per Dimension
[
https://issues.apache.org/jira/browse/LUCENE-8581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724178#comment-16724178
]
Nicholas Knize commented on LUCENE-8581:
Thanks for all of your work on this [~ivera]. This LGTM!
> Change LatLonShape encoding to use 4 BYTES Per Dimension
>
>
> Key: LUCENE-8581
> URL: https://issues.apache.org/jira/browse/LUCENE-8581
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch,
> LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch,
> LUCENE-8581.patch
>
>
> {{LatLonShape}} tessellated triangles currently use a relatively naive
> encoding with the first four dimensions as the bounding box of the triangle
> and the last three dimensions as the vertices of the triangle. To encode the
> {{x,y}} vertices in the last three dimensions requires {{bytesPerDim}} to be
> set to 8, with 4 bytes for the x & y axis, respectively. We can reduce
> {{bytesPerDim}} to 4 by encoding the index(es) of the vertices shared by the
> bounding box along with the orientation of the triangle. This also opens the
> door for supporting {{CONTAINS}} queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-8581) Change LatLonShape encoding to use 4 BYTES Per Dimension
[
https://issues.apache.org/jira/browse/LUCENE-8581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize reassigned LUCENE-8581:
--
Assignee: Nicholas Knize (was: Ignacio Vera)
> Change LatLonShape encoding to use 4 BYTES Per Dimension
>
>
> Key: LUCENE-8581
> URL: https://issues.apache.org/jira/browse/LUCENE-8581
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch,
> LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch,
> LUCENE-8581.patch
>
>
> {{LatLonShape}} tessellated triangles currently use a relatively naive
> encoding with the first four dimensions as the bounding box of the triangle
> and the last three dimensions as the vertices of the triangle. To encode the
> {{x,y}} vertices in the last three dimensions requires {{bytesPerDim}} to be
> set to 8, with 4 bytes for the x & y axis, respectively. We can reduce
> {{bytesPerDim}} to 4 by encoding the index(es) of the vertices shared by the
> bounding box along with the orientation of the triangle. This also opens the
> door for supporting {{CONTAINS}} queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8581) Change LatLonShape encoding to use 4 BYTES Per Dimension
[
https://issues.apache.org/jira/browse/LUCENE-8581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723352#comment-16723352
]
Nicholas Knize commented on LUCENE-8581:
Everything's looking good. +1 to merge once these last two changes are in place
/cc [~ivera]
> Change LatLonShape encoding to use 4 BYTES Per Dimension
>
>
> Key: LUCENE-8581
> URL: https://issues.apache.org/jira/browse/LUCENE-8581
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch,
> LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch
>
>
> {{LatLonShape}} tessellated triangles currently use a relatively naive
> encoding with the first four dimensions as the bounding box of the triangle
> and the last three dimensions as the vertices of the triangle. To encode the
> {{x,y}} vertices in the last three dimensions requires {{bytesPerDim}} to be
> set to 8, with 4 bytes for the x & y axis, respectively. We can reduce
> {{bytesPerDim}} to 4 by encoding the index(es) of the vertices shared by the
> bounding box along with the orientation of the triangle. This also opens the
> door for supporting {{CONTAINS}} queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8581) Change LatLonShape encoding to use 4 BYTES Per Dimension
[
https://issues.apache.org/jira/browse/LUCENE-8581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723224#comment-16723224
]
Nicholas Knize commented on LUCENE-8581:
{quote}Then let's also rename constants so that they enumerate coordinates in
CCW order
{quote}
+1
> Change LatLonShape encoding to use 4 BYTES Per Dimension
>
>
> Key: LUCENE-8581
> URL: https://issues.apache.org/jira/browse/LUCENE-8581
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch,
> LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch
>
>
> {{LatLonShape}} tessellated triangles currently use a relatively naive
> encoding with the first four dimensions as the bounding box of the triangle
> and the last three dimensions as the vertices of the triangle. To encode the
> {{x,y}} vertices in the last three dimensions requires {{bytesPerDim}} to be
> set to 8, with 4 bytes for the x & y axis, respectively. We can reduce
> {{bytesPerDim}} to 4 by encoding the index(es) of the vertices shared by the
> bounding box along with the orientation of the triangle. This also opens the
> door for supporting {{CONTAINS}} queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8581) Change LatLonShape encoding to use 4 BYTES Per Dimension
[
https://issues.apache.org/jira/browse/LUCENE-8581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723186#comment-16723186
]
Nicholas Knize commented on LUCENE-8581:
{quote}I got you, new patch rotates edges and indeed simplifies the logic.
{quote}
++1 this is great
{quote}whether to go with CW or CCW order?
{quote}
Right hand rule is the typical convention and part of the standard. So let's go
w/ CCW.
> Change LatLonShape encoding to use 4 BYTES Per Dimension
>
>
> Key: LUCENE-8581
> URL: https://issues.apache.org/jira/browse/LUCENE-8581
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch,
> LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch
>
>
> {{LatLonShape}} tessellated triangles currently use a relatively naive
> encoding with the first four dimensions as the bounding box of the triangle
> and the last three dimensions as the vertices of the triangle. To encode the
> {{x,y}} vertices in the last three dimensions requires {{bytesPerDim}} to be
> set to 8, with 4 bytes for the x & y axis, respectively. We can reduce
> {{bytesPerDim}} to 4 by encoding the index(es) of the vertices shared by the
> bounding box along with the orientation of the triangle. This also opens the
> door for supporting {{CONTAINS}} queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13039) BadApples for 7.6 Release
[
https://issues.apache.org/jira/browse/SOLR-13039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated SOLR-13039:
--
Description:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{{o.a.solr.TestDistributedSearch}}
{{o.a.solr.client.solrj.impl.CloudSolrClientTest}}
{{o.a.solr.cloud.api.collections.CustomCollectionTest}}
{{o.a.solr.cloud.api.collections.ShardSplitTest}}
{{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
{{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
{{o.a.solr.cloud.DocValuesNotIndexedTest}}
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.handler.component.DistributedMLTComponentTest}}
{{o.a.solr.metrics.reporters.solr.SolrJmxReportCloudTest}}
{{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
{{o.a.solr.rest.TestManagedResourceStorage}}
{{o.a.solr.schema.SchemaApiFailureTest}}
{{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
Note: this issue relates to SOLR-12028
was:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{{o.a.solr.client.solrj.impl.CloudSolrClientTest}}
{{o.a.solr.cloud.api.collections.CustomCollectionTest}}
{{o.a.solr.cloud.api.collections.ShardSplitTest}}
{{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
{{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
{{o.a.solr.cloud.DocValuesNotIndexedTest}}
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.handler.component.DistributedMLTComponentTest}}
{{o.a.solr.metrics.reporters.solr.SolrJmxReportCloudTest}}
{{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
{{o.a.solr.rest.TestManagedResourceStorage}}
{{o.a.solr.schema.SchemaApiFailureTest}}
{{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
Note: this issue relates to SOLR-12028
> BadApples for 7.6 Release
> -
>
> Key: SOLR-13039
> URL: https://issues.apache.org/jira/browse/SOLR-13039
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6
>Reporter: Nicholas Knize
>Priority: Blocker
> Attachments: SOLR-13039.patch, SOLR-13039.patch, SOLR-13039.patch
>
>
> To build the 7.6 release candidate the following test cases need to be
> annotated as {{BadApple}} (Each of these tests have multiple known CI
> failures over an extended period of time):
> {{o.a.solr.TestDistributedSearch}}
> {{o.a.solr.client.solrj.impl.CloudSolrClientTest}}
> {{o.a.solr.cloud.api.collections.CustomCollectionTest}}
> {{o.a.solr.cloud.api.collections.ShardSplitTest}}
> {{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
> {{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
> {{o.a.solr.cloud.DocValuesNotIndexedTest}}
> {{o.a.solr.cloud.SplitShardTest}}
> {{o.a.solr.cloud.TestCloudRecovery}}
> {{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
> {{o.a.solr.cloud.TestTlogReplica}}
> {{o.a.solr.cloud.TestUtilizeNode}}
> {{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
> {{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
> {{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
> {{o.a.solr.handler.component.DistributedMLTComponentTest}}
> {{o.a.solr.metrics.reporters.solr.SolrJmxReportCloudTest}}
> {{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
> {{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
> {{o.a.solr.rest.TestManagedResourceStorage}}
> {{o.a.solr.schema.SchemaApiFailureTest}}
>
[jira] [Updated] (SOLR-13039) BadApples for 7.6 Release
[
https://issues.apache.org/jira/browse/SOLR-13039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated SOLR-13039:
--
Description:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{{o.a.solr.client.solrj.impl.CloudSolrClientTest}}
{{o.a.solr.cloud.api.collections.CustomCollectionTest}}
{{o.a.solr.cloud.api.collections.ShardSplitTest}}
{{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
{{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
{{o.a.solr.cloud.DocValuesNotIndexedTest}}
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.handler.component.DistributedMLTComponentTest}}
{{o.a.solr.metrics.reporters.solr.SolrJmxReportCloudTest}}
{{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
{{o.a.solr.rest.TestManagedResourceStorage}}
{{o.a.solr.schema.SchemaApiFailureTest}}
{{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
Note: this issue relates to SOLR-12028
was:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{\{o.a.solr.client.solrj.impl.CloudSolrClientTest}}
{{o.a.solr.cloud.api.collections.ShardSplitTest}}
{{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
{{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
{{o.a.solr.cloud.DocValuesNotIndexedTest}}
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.metrics.reporters.solr.SolrJmxReportCloudTest}}
{{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
{{o.a.solr.rest.TestManagedResourceStorage}}
{{o.a.solr.schema.SchemaApiFailureTest}}
{{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
Note: this issue relates to SOLR-12028
> BadApples for 7.6 Release
> -
>
> Key: SOLR-13039
> URL: https://issues.apache.org/jira/browse/SOLR-13039
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6
>Reporter: Nicholas Knize
>Priority: Blocker
> Attachments: SOLR-13039.patch, SOLR-13039.patch, SOLR-13039.patch
>
>
> To build the 7.6 release candidate the following test cases need to be
> annotated as {{BadApple}} (Each of these tests have multiple known CI
> failures over an extended period of time):
> {{o.a.solr.client.solrj.impl.CloudSolrClientTest}}
> {{o.a.solr.cloud.api.collections.CustomCollectionTest}}
> {{o.a.solr.cloud.api.collections.ShardSplitTest}}
> {{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
> {{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
> {{o.a.solr.cloud.DocValuesNotIndexedTest}}
> {{o.a.solr.cloud.SplitShardTest}}
> {{o.a.solr.cloud.TestCloudRecovery}}
> {{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
> {{o.a.solr.cloud.TestTlogReplica}}
> {{o.a.solr.cloud.TestUtilizeNode}}
> {{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
> {{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
> {{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
> {{o.a.solr.handler.component.DistributedMLTComponentTest}}
> {{o.a.solr.metrics.reporters.solr.SolrJmxReportCloudTest}}
> {{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
> {{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
> {{o.a.solr.rest.TestManagedResourceStorage}}
> {{o.a.solr.schema.SchemaApiFailureTest}}
> {{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
> Note: this issue relates to SOLR-12028
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
[jira] [Updated] (SOLR-13039) BadApples for 7.6 Release
[
https://issues.apache.org/jira/browse/SOLR-13039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated SOLR-13039:
--
Description:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{\{o.a.solr.client.solrj.impl.CloudSolrClientTest}}
{{o.a.solr.cloud.api.collections.ShardSplitTest}}
{{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
{{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
{{o.a.solr.cloud.DocValuesNotIndexedTest}}
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.metrics.reporters.solr.SolrJmxReportCloudTest}}
{{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
{{o.a.solr.rest.TestManagedResourceStorage}}
{{o.a.solr.schema.SchemaApiFailureTest}}
{{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
Note: this issue relates to SOLR-12028
was:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{{o.a.solr.cloud.api.collections.ShardSplitTest}}
{{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
{{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
{{o.a.solr.cloud.DocValuesNotIndexedTest}}
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.metrics.reporters.solr.SolrJmxReportCloudTest}}
{{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
{{o.a.solr.rest.TestManagedResourceStorage}}
{{o.a.solr.schema.SchemaApiFailureTest}}
{{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
Note: this issue relates to SOLR-12028
> BadApples for 7.6 Release
> -
>
> Key: SOLR-13039
> URL: https://issues.apache.org/jira/browse/SOLR-13039
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6
>Reporter: Nicholas Knize
>Priority: Blocker
> Attachments: SOLR-13039.patch, SOLR-13039.patch
>
>
> To build the 7.6 release candidate the following test cases need to be
> annotated as {{BadApple}} (Each of these tests have multiple known CI
> failures over an extended period of time):
> {\{o.a.solr.client.solrj.impl.CloudSolrClientTest}}
> {{o.a.solr.cloud.api.collections.ShardSplitTest}}
> {{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
> {{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
> {{o.a.solr.cloud.DocValuesNotIndexedTest}}
> {{o.a.solr.cloud.SplitShardTest}}
> {{o.a.solr.cloud.TestCloudRecovery}}
> {{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
> {{o.a.solr.cloud.TestTlogReplica}}
> {{o.a.solr.cloud.TestUtilizeNode}}
> {{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
> {{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
> {{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
> {{o.a.solr.metrics.reporters.solr.SolrJmxReportCloudTest}}
> {{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
> {{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
> {{o.a.solr.rest.TestManagedResourceStorage}}
> {{o.a.solr.schema.SchemaApiFailureTest}}
> {{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
> Note: this issue relates to SOLR-12028
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13039) BadApples for 7.6 Release
[
https://issues.apache.org/jira/browse/SOLR-13039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated SOLR-13039:
--
Description:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{{o.a.solr.cloud.api.collections.ShardSplitTest}}
{{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
{{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
{{o.a.solr.cloud.DocValuesNotIndexedTest}}
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.metrics.reporters.solr.SolrJmxReportCloudTest}}
{{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
{{o.a.solr.rest.TestManagedResourceStorage}}
{{o.a.solr.schema.SchemaApiFailureTest}}
{{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
Note: this issue relates to SOLR-12028
was:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{{o.a.solr.cloud.api.collections.ShardSplitTest}}
{{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
{{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
{{o.a.solr.cloud.DocValuesNotIndexedTest}}
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
{{o.a.solr.rest.TestManagedResourceStorage}}
{{o.a.solr.schema.SchemaApiFailureTest}}
{{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
Note: this issue relates to SOLR-12028
> BadApples for 7.6 Release
> -
>
> Key: SOLR-13039
> URL: https://issues.apache.org/jira/browse/SOLR-13039
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6
>Reporter: Nicholas Knize
>Priority: Blocker
> Attachments: SOLR-13039.patch, SOLR-13039.patch
>
>
> To build the 7.6 release candidate the following test cases need to be
> annotated as {{BadApple}} (Each of these tests have multiple known CI
> failures over an extended period of time):
> {{o.a.solr.cloud.api.collections.ShardSplitTest}}
> {{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
> {{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
> {{o.a.solr.cloud.DocValuesNotIndexedTest}}
> {{o.a.solr.cloud.SplitShardTest}}
> {{o.a.solr.cloud.TestCloudRecovery}}
> {{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
> {{o.a.solr.cloud.TestTlogReplica}}
> {{o.a.solr.cloud.TestUtilizeNode}}
> {{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
> {{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
> {{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
> {{o.a.solr.metrics.reporters.solr.SolrJmxReportCloudTest}}
> {{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
> {{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
> {{o.a.solr.rest.TestManagedResourceStorage}}
> {{o.a.solr.schema.SchemaApiFailureTest}}
> {{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
> Note: this issue relates to SOLR-12028
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13039) BadApples for 7.6 Release
[
https://issues.apache.org/jira/browse/SOLR-13039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated SOLR-13039:
--
Description:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{{o.a.solr.cloud.api.collections.ShardSplitTest}}
{{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
{{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
{{o.a.solr.cloud.DocValuesNotIndexedTest}}
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
{{o.a.solr.rest.TestManagedResourceStorage}}
{{o.a.solr.schema.SchemaApiFailureTest}}
{{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
Note: this issue relates to SOLR-12028
was:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{{o.a.solr.cloud.api.collections.ShardSplitTest}}
{{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
{{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
{{o.a.solr.cloud.DocValuesNotIndexedTest}}
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
{{o.a.solr.rest.TestManagedResourceStorage}}
{{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
Note: this issue relates to SOLR-12028
> BadApples for 7.6 Release
> -
>
> Key: SOLR-13039
> URL: https://issues.apache.org/jira/browse/SOLR-13039
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6
>Reporter: Nicholas Knize
>Priority: Blocker
> Attachments: SOLR-13039.patch, SOLR-13039.patch
>
>
> To build the 7.6 release candidate the following test cases need to be
> annotated as {{BadApple}} (Each of these tests have multiple known CI
> failures over an extended period of time):
> {{o.a.solr.cloud.api.collections.ShardSplitTest}}
> {{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
> {{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
> {{o.a.solr.cloud.DocValuesNotIndexedTest}}
> {{o.a.solr.cloud.SplitShardTest}}
> {{o.a.solr.cloud.TestCloudRecovery}}
> {{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
> {{o.a.solr.cloud.TestTlogReplica}}
> {{o.a.solr.cloud.TestUtilizeNode}}
> {{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
> {{o.a.solr.cloud.autoscaling.TestPolicyCloud}}
> {{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
> {{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
> {{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
> {{o.a.solr.rest.TestManagedResourceStorage}}
> {{o.a.solr.schema.SchemaApiFailureTest}}
> {{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
> Note: this issue relates to SOLR-12028
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13039) BadApples for 7.6 Release
[
https://issues.apache.org/jira/browse/SOLR-13039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated SOLR-13039:
--
Description:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{{o.a.solr.cloud.api.collections.ShardSplitTest}}
{{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
{{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
{{o.a.solr.cloud.DocValuesNotIndexedTest}}
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
{{o.a.solr.rest.TestManagedResourceStorage}}
{{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
Note: this issue relates to SOLR-12028
was:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{{o.a.solr.cloud.api.collections.ShardSplitTest}}
{{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
{{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
Note: this issue relates to SOLR-12028
> BadApples for 7.6 Release
> -
>
> Key: SOLR-13039
> URL: https://issues.apache.org/jira/browse/SOLR-13039
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6
>Reporter: Nicholas Knize
>Priority: Blocker
> Attachments: SOLR-13039.patch, SOLR-13039.patch
>
>
> To build the 7.6 release candidate the following test cases need to be
> annotated as {{BadApple}} (Each of these tests have multiple known CI
> failures over an extended period of time):
> {{o.a.solr.cloud.api.collections.ShardSplitTest}}
> {{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
> {{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
> {{o.a.solr.cloud.DocValuesNotIndexedTest}}
> {{o.a.solr.cloud.SplitShardTest}}
> {{o.a.solr.cloud.TestCloudRecovery}}
> {{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
> {{o.a.solr.cloud.TestTlogReplica}}
> {{o.a.solr.cloud.TestUtilizeNode}}
> {{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
> {{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
> {{o.a.solr.metrics.reporters.solr.SolrCloudReportersTest}}
> {{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
> {{o.a.solr.rest.TestManagedResourceStorage}}
> {{o.a.solr.servlet.HttpSolrCallGetCoreTest}}
> Note: this issue relates to SOLR-12028
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8581) Change LatLonShape encoding to use 4 BYTES Per Dimension
[
https://issues.apache.org/jira/browse/LUCENE-8581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709022#comment-16709022
]
Nicholas Knize commented on LUCENE-8581:
{quote}Just for my curiosity. when creating a triangle in the tessellator
points get order. is that really needed? what is the purpose?
{quote}
That can be removed. It's legacy from before the selective indexing approach
was used. It sounds like that will solve a big part of the problem
+1 for using 2^3 constants. And I also think we can continue to iterate on the
readability part in a separate patch. I don't think it should hold up the
bigger benefit of a smaller index.
> Change LatLonShape encoding to use 4 BYTES Per Dimension
>
>
> Key: LUCENE-8581
> URL: https://issues.apache.org/jira/browse/LUCENE-8581
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8581.patch, LUCENE-8581.patch
>
>
> {{LatLonShape}} tessellated triangles currently use a relatively naive
> encoding with the first four dimensions as the bounding box of the triangle
> and the last three dimensions as the vertices of the triangle. To encode the
> {{x,y}} vertices in the last three dimensions requires {{bytesPerDim}} to be
> set to 8, with 4 bytes for the x & y axis, respectively. We can reduce
> {{bytesPerDim}} to 4 by encoding the index(es) of the vertices shared by the
> bounding box along with the orientation of the triangle. This also opens the
> door for supporting {{CONTAINS}} queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13039) BadApples for 7.6 Release
[
https://issues.apache.org/jira/browse/SOLR-13039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated SOLR-13039:
--
Description:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{{o.a.solr.cloud.api.collections.ShardSplitTest}}
{{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
{{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
Note: this issue relates to SOLR-12028
was:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
Note: this issue relates to SOLR-12028
> BadApples for 7.6 Release
> -
>
> Key: SOLR-13039
> URL: https://issues.apache.org/jira/browse/SOLR-13039
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6
>Reporter: Nicholas Knize
>Priority: Blocker
> Attachments: SOLR-13039.patch
>
>
> To build the 7.6 release candidate the following test cases need to be
> annotated as {{BadApple}} (Each of these tests have multiple known CI
> failures over an extended period of time):
> {{o.a.solr.cloud.api.collections.ShardSplitTest}}
> {{o.a.solr.cloud.api.collections.TestHdfsCloudBackupRestore}}
> {{o.a.solr.cloud.api.collections.TestLocalFSCloudBackupRestore}}
> {{o.a.solr.cloud.SplitShardTest}}
> {{o.a.solr.cloud.TestCloudRecovery}}
> {{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
> {{o.a.solr.cloud.TestTlogReplica}}
> {{o.a.solr.cloud.TestUtilizeNode}}
> {{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
> {{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
> {{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
> Note: this issue relates to SOLR-12028
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13039) BadApples for 7.6 Release
[
https://issues.apache.org/jira/browse/SOLR-13039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated SOLR-13039:
--
Description:
To build the 7.6 release candidate the following test cases need to be
annotated as {{BadApple}} (Each of these tests have multiple known CI failures
over an extended period of time):
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
Note: this issue relates to SOLR-12028
was:
To build the 7.6 release candidate the following test cases need to be marked
with {{BadApple}} (Each of these tests have multiple known CI failures over an
extended period of time):
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
Note: this issue relates to SOLR-12028
> BadApples for 7.6 Release
> -
>
> Key: SOLR-13039
> URL: https://issues.apache.org/jira/browse/SOLR-13039
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6
>Reporter: Nicholas Knize
>Priority: Blocker
>
> To build the 7.6 release candidate the following test cases need to be
> annotated as {{BadApple}} (Each of these tests have multiple known CI
> failures over an extended period of time):
> {{o.a.solr.cloud.SplitShardTest}}
> {{o.a.solr.cloud.TestCloudRecovery}}
> {{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
> {{o.a.solr.cloud.TestTlogReplica}}
> {{o.a.solr.cloud.TestUtilizeNode}}
> {{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
> {{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
> {{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
> Note: this issue relates to SOLR-12028
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13039) BadApples for 7.6 Release
Nicholas Knize created SOLR-13039:
-
Summary: BadApples for 7.6 Release
Key: SOLR-13039
URL: https://issues.apache.org/jira/browse/SOLR-13039
Project: Solr
Issue Type: Test
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Nicholas Knize
To build the 7.6 release candidate the following test cases need to be marked
with {{BadApple}} (Each of these tests have multiple known CI failures over an
extended period of time):
{{o.a.solr.cloud.SplitShardTest}}
{{o.a.solr.cloud.TestCloudRecovery}}
{{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
{{o.a.solr.cloud.TestTlogReplica}}
{{o.a.solr.cloud.TestUtilizeNode}}
{{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
{{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
{{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
{{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
Note: this issue relates to SOLR-12028
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13039) BadApples for 7.6 Release
[
https://issues.apache.org/jira/browse/SOLR-13039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated SOLR-13039:
--
Affects Version/s: 7.6
> BadApples for 7.6 Release
> -
>
> Key: SOLR-13039
> URL: https://issues.apache.org/jira/browse/SOLR-13039
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6
>Reporter: Nicholas Knize
>Priority: Blocker
>
> To build the 7.6 release candidate the following test cases need to be marked
> with {{BadApple}} (Each of these tests have multiple known CI failures over
> an extended period of time):
> {{o.a.solr.cloud.SplitShardTest}}
> {{o.a.solr.cloud.TestCloudRecovery}}
> {{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
> {{o.a.solr.cloud.TestTlogReplica}}
> {{o.a.solr.cloud.TestUtilizeNode}}
> {{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
> {{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
> {{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
> Note: this issue relates to SOLR-12028
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13039) BadApples for 7.6 Release
[
https://issues.apache.org/jira/browse/SOLR-13039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated SOLR-13039:
--
Priority: Blocker (was: Major)
> BadApples for 7.6 Release
> -
>
> Key: SOLR-13039
> URL: https://issues.apache.org/jira/browse/SOLR-13039
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6
>Reporter: Nicholas Knize
>Priority: Blocker
>
> To build the 7.6 release candidate the following test cases need to be marked
> with {{BadApple}} (Each of these tests have multiple known CI failures over
> an extended period of time):
> {{o.a.solr.cloud.SplitShardTest}}
> {{o.a.solr.cloud.TestCloudRecovery}}
> {{o.a.solr.cloud.TestMiniSolrCloudClusterSSL}}
> {{o.a.solr.cloud.TestTlogReplica}}
> {{o.a.solr.cloud.TestUtilizeNode}}
> {{o.a.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest}}
> {{o.a.solr.cloud.autoscaling.IndexSizeTriggerTest}}
> {{o.a.solr.cloud.autoscaling.sim.TestSimPolicyCloud}}
> {{o.a.solr.update.processor.TimeRoutedAliasUpdateProcessorTest}}
> Note: this issue relates to SOLR-12028
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8583) Make GeoUtils#orientation method more stable
[
https://issues.apache.org/jira/browse/LUCENE-8583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707620#comment-16707620
]
Nicholas Knize commented on LUCENE-8583:
{quote}Since we aren't a geo library that's not a goal we have to strive for
{quote}
+1
{quote}And maybe it should be moved back to a private method in Polygon2D where
it was originally?
{quote}
I agree. I'd also like to point out that we shouldn't need this to be super
accurate in {{LatLonShape}} either. It looks like this is a byproduct of adding
a dependency on orientation in {{LatLonShape.Triangle#encodeTriangle}} we
should remove that dependency and just ensure order of the triangle vertices
are preserved.
> Make GeoUtils#orientation method more stable
>
>
> Key: LUCENE-8583
> URL: https://issues.apache.org/jira/browse/LUCENE-8583
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8583.patch
>
>
> The method GeoUtils#orient is problematic when called with points that are
> almost collinear but not quite. In that case the sign of the determinant is
> not reliable, so for example calling the method with points (a, b, c) and
> with (c, b, a) gives the same orientation.
> There is a complex implementation described here
> (https://www.cs.cmu.edu/~quake/robust.html) where the method becomes more
> reliable. I have been playing with such implementation and still is not 100%
> reliable.
> My proposal is not to be fully precise and define a precision constant for
> this method. Therefore whenever the value of determinant is small to that
> precision, we consider the points to be collinear. In this case the results
> of the method are reliable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8581) Change LatLonShape encoding to use 4 BYTES Per Dimension
[
https://issues.apache.org/jira/browse/LUCENE-8581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707612#comment-16707612
]
Nicholas Knize commented on LUCENE-8581:
Thanks [~ivera]
{{setTriangleValue((aLon), (aLat), (bLon), (bLat), (cLon), (cLat));}}
I think it would be good to keep the calls to {{encodeLatitude}} and
{{encodeLongitude}} here. The tessellator already encodes polygon triangles, so
there's no need to call the encode methods twice.
{{setTriangleValue(t.getLon(0), t.getLat(0), t.getLon(1), t.getLat(1),
t.getLon(2), t.getLat(2));}}
Just keep the calls to {{getEncodedX}} {{getEncodedY}} to unnecessarily encode
twice.
{code:java}
int ccw = GeoUtils.orient(aLon, aLat, bLon, bLat, cLon, cLat);
if (ccw == 1) {
throw new IllegalArgumentException("Orientation of the triangle cannot be
clock-wise");
}{code}
Encoding should be orientation agnostic, but congruent (order preserved). I
think we should remove the orientation dependency.
{code:java}
if (minY == aY && minX == aX) {
...{code}
For maintenance I'd really like to reduce this tree of conditionals. Its pretty
hard to follow. However, I think we could do that in a separate issue/patch
iteration (this is in sandbox after all). For now, lets at least make sure this
code is well documented so it's clear what's going on.
> Change LatLonShape encoding to use 4 BYTES Per Dimension
>
>
> Key: LUCENE-8581
> URL: https://issues.apache.org/jira/browse/LUCENE-8581
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8581.patch
>
>
> {{LatLonShape}} tessellated triangles currently use a relatively naive
> encoding with the first four dimensions as the bounding box of the triangle
> and the last three dimensions as the vertices of the triangle. To encode the
> {{x,y}} vertices in the last three dimensions requires {{bytesPerDim}} to be
> set to 8, with 4 bytes for the x & y axis, respectively. We can reduce
> {{bytesPerDim}} to 4 by encoding the index(es) of the vertices shared by the
> bounding box along with the orientation of the triangle. This also opens the
> door for supporting {{CONTAINS}} queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-8581) Change LatLonShape encoding to use 4 BYTES Per Dimension
[
https://issues.apache.org/jira/browse/LUCENE-8581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize reassigned LUCENE-8581:
--
Assignee: Ignacio Vera
> Change LatLonShape encoding to use 4 BYTES Per Dimension
>
>
> Key: LUCENE-8581
> URL: https://issues.apache.org/jira/browse/LUCENE-8581
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Ignacio Vera
>Priority: Major
>
> {{LatLonShape}} tessellated triangles currently use a relatively naive
> encoding with the first four dimensions as the bounding box of the triangle
> and the last three dimensions as the vertices of the triangle. To encode the
> {{x,y}} vertices in the last three dimensions requires {{bytesPerDim}} to be
> set to 8, with 4 bytes for the x & y axis, respectively. We can reduce
> {{bytesPerDim}} to 4 by encoding the index(es) of the vertices shared by the
> bounding box along with the orientation of the triangle. This also opens the
> door for supporting {{CONTAINS}} queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8581) Change LatLonShape encoding to use 4 BYTES Per Dimension
Nicholas Knize created LUCENE-8581:
--
Summary: Change LatLonShape encoding to use 4 BYTES Per Dimension
Key: LUCENE-8581
URL: https://issues.apache.org/jira/browse/LUCENE-8581
Project: Lucene - Core
Issue Type: New Feature
Reporter: Nicholas Knize
{{LatLonShape}} tessellated triangles currently use a relatively naive encoding
with the first four dimensions as the bounding box of the triangle and the last
three dimensions as the vertices of the triangle. To encode the {{x,y}}
vertices in the last three dimensions requires {{bytesPerDim}} to be set to 8,
with 4 bytes for the x & y axis, respectively. We can reduce {{bytesPerDim}} to
4 by encoding the index(es) of the vertices shared by the bounding box along
with the orientation of the triangle. This also opens the door for supporting
{{CONTAINS}} queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8579) Don't run badapples when building a release
[
https://issues.apache.org/jira/browse/LUCENE-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16703853#comment-16703853
]
Nicholas Knize commented on LUCENE-8579:
+1
> Don't run badapples when building a release
> ---
>
> Key: LUCENE-8579
> URL: https://issues.apache.org/jira/browse/LUCENE-8579
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Major
>
> Nick pinged me because his attempt to build a release failed because of Solr
> test failures. When looking at those, I noticed that a number of them were
> known flaky test that are already tagged as bad apples, eg.
> org.apache.solr.cloud.TestStressInPlaceUpdates.stressTest.
> We should disable badapples in the script to build a release, ie. something
> like
> {code:python}
> diff --git a/dev-tools/scripts/buildAndPushRelease.py
> b/dev-tools/scripts/buildAndPushRelease.py
> index 5a8f5cc..b557da2 100644
> --- a/dev-tools/scripts/buildAndPushRelease.py
> +++ b/dev-tools/scripts/buildAndPushRelease.py
> @@ -105,7 +105,7 @@ def prepare(root, version, gpgKeyID, gpgPassword):
>print(' Check DOAP files')
>checkDOAPfiles(version)
>
> - print(' ant clean test validate documentation-lint')
> + print(' ant -Dtests.badapples=false clean test validate
> documentation-lint')
> - run('ant clean test validate documentation-lint')
> + run('ant -Dtests.badapples=false clean test validate documentation-lint')
>
>open('rev.txt', mode='wb').write(rev.encode('UTF-8'))
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8573) BKDWriter should use FutureArrays#mismatch
[ https://issues.apache.org/jira/browse/LUCENE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700688#comment-16700688 ] Nicholas Knize commented on LUCENE-8573: That would be great [~cbuescher] > BKDWriter should use FutureArrays#mismatch > -- > > Key: LUCENE-8573 > URL: https://issues.apache.org/jira/browse/LUCENE-8573 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > > In a number of places, BKDWriter tries to find the first mismatching byte > between multiple arrays with a for loop. It could use the safer > FutureArrays#mismatch instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8554) Add new LatLonShapeLineQuery
[
https://issues.apache.org/jira/browse/LUCENE-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685543#comment-16685543
]
Nicholas Knize commented on LUCENE-8554:
Just pointing out there was a nice performance improvement side effect from
this patch:
Seen here in
[geobench.html#search-polyMedium|http://people.apache.org/~mikemccand/geobench.html#search-polyMedium]
A simple optimization was added to
[EdgeTree.java#330|https://github.com/apache/lucene-solr/blob/95d01c6583b825b6b87591e4f27002c285ea25fb/lucene/core/src/java/org/apache/lucene/geo/EdgeTree.java#L330]
to check if either end of the polygon's line segment is contained by the
target rectangle. This optimization skips all of the determinant calculations
below giving what appears to be a boost in search performance of ~1.4 QPS for
{{LatLonPoint#newPolygonQuery}}
> Add new LatLonShapeLineQuery
>
>
> Key: LUCENE-8554
> URL: https://issues.apache.org/jira/browse/LUCENE-8554
> Project: Lucene - Core
> Issue Type: New Feature
>Affects Versions: 7.6, master (8.0)
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Blocker
> Attachments: LUCENE-8554.patch, LUCENE-8554.patch
>
>
> Its often useful to be able to query a shape index for documents that either
> {{INTERSECT}} or are {{DISJOINT}} from a given {{LINESTRING}}. Occasionally
> the linestring of interest may also have a distance component, which creates
> a *buffered query* (often used in routing, or shape snapping). This feature
> first adds a new {{LatLonShapeLineQuery}} for querying {{LatLonShape}}
> fields by arbitrary lines. A distance component can then be added in a future
> issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8556) Tessellator: Polygons can fail when using Morton optimisation
[ https://issues.apache.org/jira/browse/LUCENE-8556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680642#comment-16680642 ] Nicholas Knize commented on LUCENE-8556: Patch LGTM!! Thanks [~ivera] > Tessellator: Polygons can fail when using Morton optimisation > - > > Key: LUCENE-8556 > URL: https://issues.apache.org/jira/browse/LUCENE-8556 > Project: Lucene - Core > Issue Type: Bug > Components: modules/sandbox >Affects Versions: 7.6, master (8.0) >Reporter: Ignacio Vera >Priority: Blocker > Attachments: LUCENE-8556.patch, image-2018-11-02-08-48-12-898.png > > > I experience some errors when processing complex polygons. I realised that if > I disable the Morton optimisation, then the errors go away. > I studied one of the cases and it seems that when using the optimisation, it > is possible to create triangles with points inside of them (see picture > attached). There is a point just on the edge of the triangle. When disabling > the optimisation, such a triangle is not created. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8559) Tessellator: isIntersectingPolygon method skip polygon edges
[
https://issues.apache.org/jira/browse/LUCENE-8559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677313#comment-16677313
]
Nicholas Knize commented on LUCENE-8559:
+1 Thank you [~ivera]
> Tessellator: isIntersectingPolygon method skip polygon edges
>
>
> Key: LUCENE-8559
> URL: https://issues.apache.org/jira/browse/LUCENE-8559
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/sandbox
>Affects Versions: 7.6, master (8.0)
>Reporter: Ignacio Vera
>Priority: Blocker
> Attachments: LUCENE-8559.patch
>
>
> The following condition seems wrong:
> {code:java}
> if(node.getX() != x0 && node.getY() != y0 && nextNode.getX() != x0
> && nextNode.getY() != y0 && node.getX() != x1 && node.getY() != y1
> && nextNode.getX() != x1 && nextNode.getY() != y1) {
>//check intersection
> }{code}
> Any node with the same X or Y is skipped.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8555) Add dateline crossing support to LatLonShapeBoundingBoxQuery
[
https://issues.apache.org/jira/browse/LUCENE-8555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize resolved LUCENE-8555.
Resolution: Implemented
> Add dateline crossing support to LatLonShapeBoundingBoxQuery
>
>
> Key: LUCENE-8555
> URL: https://issues.apache.org/jira/browse/LUCENE-8555
> Project: Lucene - Core
> Issue Type: New Feature
>Affects Versions: 7.6, master (8.0)
>Reporter: Nicholas Knize
>Priority: Blocker
> Attachments: LUCENE-8555.patch
>
>
> Instead of rewriting into a {{BooleanQuery}}, {{LatLonShapeBoundingBoxQuery}}
> should handle dateline crossing support directly in the {{IntersectVisitor}}.
> This feature issue will add support for splitting a
> {{LatLonShapeBoundingBoxQuery}} into an east and west box and comparing the
> indexed {{LatLonShape}} fields against each. {{INTERSECTS}}, {{DISJOINT}},
> and {{WITHIN}} will all be handled by the {{LatLonShapeQuery}}
> IntersectVisitor.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8554) Add new LatLonShapeLineQuery
[
https://issues.apache.org/jira/browse/LUCENE-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize resolved LUCENE-8554.
Resolution: Implemented
> Add new LatLonShapeLineQuery
>
>
> Key: LUCENE-8554
> URL: https://issues.apache.org/jira/browse/LUCENE-8554
> Project: Lucene - Core
> Issue Type: New Feature
>Affects Versions: 7.6, master (8.0)
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Blocker
> Attachments: LUCENE-8554.patch, LUCENE-8554.patch
>
>
> Its often useful to be able to query a shape index for documents that either
> {{INTERSECT}} or are {{DISJOINT}} from a given {{LINESTRING}}. Occasionally
> the linestring of interest may also have a distance component, which creates
> a *buffered query* (often used in routing, or shape snapping). This feature
> first adds a new {{LatLonShapeLineQuery}} for querying {{LatLonShape}}
> fields by arbitrary lines. A distance component can then be added in a future
> issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12954) facet.pivot refinement bug when facet.sort=index and mincount > 2*numShards
[
https://issues.apache.org/jira/browse/SOLR-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16673164#comment-16673164
]
Nicholas Knize commented on SOLR-12954:
---
Sounds like we should label as a blocker for 7.6 & 8.0?
> facet.pivot refinement bug when facet.sort=index and mincount > 2*numShards
> ---
>
> Key: SOLR-12954
> URL: https://issues.apache.org/jira/browse/SOLR-12954
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Priority: Major
>
> While testing out SOLR-7804 i discovered a failure in TestCloudPivotFacet
> that indicates a problem with the refinement of (nested?) pivot facets when
> {{facet.sort=index}} and {{facet.pivot.mincount > 2*numShards}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8549) Tessellator should throw an error if all points were not processed
[
https://issues.apache.org/jira/browse/LUCENE-8549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672177#comment-16672177
]
Nicholas Knize commented on LUCENE-8549:
Nice convenience method, and the patch is small and straightforward.
Can you add the explicit testing to {{TestTessellator}}. Then +1 to commit.
> Tessellator should throw an error if all points were not processed
> --
>
> Key: LUCENE-8549
> URL: https://issues.apache.org/jira/browse/LUCENE-8549
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/sandbox
>Affects Versions: 7.6, master (8.0)
>Reporter: Ignacio Vera
>Priority: Blocker
> Attachments: LUCENE-8549.patch
>
>
> Currently, the tessellation in some situations when it has not successfully
> process all points in the polygon, it will still return an incomplete/wrong
> tessellation.
> For example the following code:
> {code:java}
> public void testInvalidPolygon() throws Exception {
> String wkt = "POLYGON((0 0, 1 1, 0 1, 1 0, 0 0))";
> Polygon polygon = (Polygon)SimpleWKTShapeParser.parse(wkt);
> expectThrows( IllegalArgumentException.class, () ->
> {Tessellator.tessellate(polygon); });
> }{code}
> will fail as the tessellator return a wrong tessellation containing one
> triangle.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8550) Tessellator fails when filtering coplanar points when creating linked list
[ https://issues.apache.org/jira/browse/LUCENE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672175#comment-16672175 ] Nicholas Knize commented on LUCENE-8550: +1 great catch! > Tessellator fails when filtering coplanar points when creating linked list > --- > > Key: LUCENE-8550 > URL: https://issues.apache.org/jira/browse/LUCENE-8550 > Project: Lucene - Core > Issue Type: Bug > Components: modules/sandbox >Affects Versions: 7.6, master (8.0) >Reporter: Ignacio Vera >Priority: Blocker > Attachments: LUCENE-8550.patch > > > Currently when creating the linked list on the tessellator, coplanar points > are filtered. The problem is the following: > if we have three coplanar points, the code is actually removing the last > point, instead it should remove the middle one. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8534) Another case of Polygon tessellator going into an infinite loop
[ https://issues.apache.org/jira/browse/LUCENE-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672171#comment-16672171 ] Nicholas Knize commented on LUCENE-8534: Sorry for the delay on this [~ivera] and thanks for addressing these issues. The patch look good to me. > Another case of Polygon tessellator going into an infinite loop > --- > > Key: LUCENE-8534 > URL: https://issues.apache.org/jira/browse/LUCENE-8534 > Project: Lucene - Core > Issue Type: Bug > Components: modules/sandbox >Affects Versions: 7.6, master (8.0) >Reporter: Ignacio Vera >Priority: Blocker > Attachments: LUCENE-8534.patch, LUCENE-8534.patch, LUCENE-8534.patch, > bigPolygon.wkt, image-2018-10-19-12-25-07-849.png > > > Related to LUCENE-8454, another case where tesselator never returns when > processing a polygon. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8534) Another case of Polygon tessellator going into an infinite loop
[ https://issues.apache.org/jira/browse/LUCENE-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-8534: --- Affects Version/s: master (8.0) 7.6 > Another case of Polygon tessellator going into an infinite loop > --- > > Key: LUCENE-8534 > URL: https://issues.apache.org/jira/browse/LUCENE-8534 > Project: Lucene - Core > Issue Type: Bug > Components: modules/sandbox >Affects Versions: 7.6, master (8.0) >Reporter: Ignacio Vera >Priority: Blocker > Attachments: LUCENE-8534.patch, LUCENE-8534.patch, LUCENE-8534.patch, > bigPolygon.wkt, image-2018-10-19-12-25-07-849.png > > > Related to LUCENE-8454, another case where tesselator never returns when > processing a polygon. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8534) Another case of Polygon tessellator going into an infinite loop
[ https://issues.apache.org/jira/browse/LUCENE-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-8534: --- Priority: Blocker (was: Major) > Another case of Polygon tessellator going into an infinite loop > --- > > Key: LUCENE-8534 > URL: https://issues.apache.org/jira/browse/LUCENE-8534 > Project: Lucene - Core > Issue Type: Bug > Components: modules/sandbox >Affects Versions: 7.6, master (8.0) >Reporter: Ignacio Vera >Priority: Blocker > Attachments: LUCENE-8534.patch, LUCENE-8534.patch, LUCENE-8534.patch, > bigPolygon.wkt, image-2018-10-19-12-25-07-849.png > > > Related to LUCENE-8454, another case where tesselator never returns when > processing a polygon. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8550) Tessellator fails when filtering coplanar points when creating linked list
[ https://issues.apache.org/jira/browse/LUCENE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-8550: --- Affects Version/s: master (8.0) 7.6 > Tessellator fails when filtering coplanar points when creating linked list > --- > > Key: LUCENE-8550 > URL: https://issues.apache.org/jira/browse/LUCENE-8550 > Project: Lucene - Core > Issue Type: Bug > Components: modules/sandbox >Affects Versions: 7.6, master (8.0) >Reporter: Ignacio Vera >Priority: Blocker > Attachments: LUCENE-8550.patch > > > Currently when creating the linked list on the tessellator, coplanar points > are filtered. The problem is the following: > if we have three coplanar points, the code is actually removing the last > point, instead it should remove the middle one. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8549) Tessellator should throw an error if all points were not processed
[
https://issues.apache.org/jira/browse/LUCENE-8549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-8549:
---
Affects Version/s: 7.6
> Tessellator should throw an error if all points were not processed
> --
>
> Key: LUCENE-8549
> URL: https://issues.apache.org/jira/browse/LUCENE-8549
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/sandbox
>Affects Versions: 7.6, master (8.0)
>Reporter: Ignacio Vera
>Priority: Blocker
> Attachments: LUCENE-8549.patch
>
>
> Currently, the tessellation in some situations when it has not successfully
> process all points in the polygon, it will still return an incomplete/wrong
> tessellation.
> For example the following code:
> {code:java}
> public void testInvalidPolygon() throws Exception {
> String wkt = "POLYGON((0 0, 1 1, 0 1, 1 0, 0 0))";
> Polygon polygon = (Polygon)SimpleWKTShapeParser.parse(wkt);
> expectThrows( IllegalArgumentException.class, () ->
> {Tessellator.tessellate(polygon); });
> }{code}
> will fail as the tessellator return a wrong tessellation containing one
> triangle.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8550) Tessellator fails when filtering coplanar points when creating linked list
[ https://issues.apache.org/jira/browse/LUCENE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-8550: --- Priority: Blocker (was: Major) > Tessellator fails when filtering coplanar points when creating linked list > --- > > Key: LUCENE-8550 > URL: https://issues.apache.org/jira/browse/LUCENE-8550 > Project: Lucene - Core > Issue Type: Bug > Components: modules/sandbox >Reporter: Ignacio Vera >Priority: Blocker > Attachments: LUCENE-8550.patch > > > Currently when creating the linked list on the tessellator, coplanar points > are filtered. The problem is the following: > if we have three coplanar points, the code is actually removing the last > point, instead it should remove the middle one. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
