-
Notifications
You must be signed in to change notification settings - Fork 697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SEDONA-508] Add ST_CrossesDateLine #1259
Conversation
@@ -13,9 +13,11 @@ | |||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please put this one in Functions
. Predicates
are for functions that take two geometries as input and return true/false.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@prantogg Can you address this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
return false; | ||
} | ||
|
||
AtomicBoolean crossesDateLine = new AtomicBoolean(false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why use AtomicBoolean
? I believe the filter functions will be called in a sequential order?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CoordinateSequenceFilter
being an anonymous inner class could not modify a local variable outside its filter scope unless its final
. AtomicBoolean
was a work around because final variable's cannot be modified. I have removed separate handling of GeometryCollection
so I can define a private local variable crossesDateLine
within the filter.
} | ||
}; | ||
|
||
if (geometry instanceof GeometryCollection) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why explicitly do this for GeometryCollection
? Note that: GeometryCollection
can have nested GeometryCollection
inside. We should avoid implementing our own logic to iterate GeometryCollection. If we really want to do it, this should be done via a recursive function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I initially wanted to make sure Every geometry within the GeometryCollection
is handled separately because crossesDateLine
should return true if any geometry is crossing the dateline.
You're right, explicit handling for GeometryCollection
was not required, CoordinateSequenceFilter
is able to handle this well. Have pushed the changes.
} | ||
|
||
|
||
// public static boolean crossesDateLine(Geometry geometry) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove the comments.
* Implement ST_CrossesDateLine * Add docs * Refactor crossesDateLine(); Fix python test * Port ST_CrossesDateLine from Predicates to Functions * Fix typo
Did you read the Contributor Guide?
Is this PR related to a JIRA ticket?
[SEDONA-XXX] my subject
.What changes were proposed in this PR?
Introduces a predicate function,
ST_CrossesDateLine
to determines if a given geometry crosses the International Date Line.true
, elsefalse
.How was this patch tested?
Did this PR include necessary documentation updates?
vX.Y.Z
format.