Update Wfs to use unwrap Antimeridian functionality#6956
Update Wfs to use unwrap Antimeridian functionality#6956nickchooleidos wants to merge 1 commit intocodice:masterfrom
Conversation
|
Choo, Jun Nick [AU-AU] seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
| private JAXBElement<? extends SpatialOpsType> createSpatialOpType( | ||
| String operation, String propertyName, String wkt, Double distance) { | ||
| String adjustedWkt = Antimeridian.normalizeWkt(wkt); | ||
| String adjustedWkt = Antimeridian.unwrapAndSplitWkt(wkt); |
There was a problem hiding this comment.
nice find - didn't realize we already had a method to solve this problem
|
note - this fix is needed into the 2.29.x branch as well |
36698d2 to
ce12583
Compare
|
Build now |
| @Test | ||
| public void testAntimeridianCrossingIsSplitWithNegativeCoordinatesa() { | ||
| String originalWkt = | ||
| "POLYGON ((170 10, -170 10, -170 10, 170 -10, 170 10))"; |
There was a problem hiding this comment.
I don't think this is a valid test, the areas being compared don't appear to be equivalent. You have effectively drawn a triangle here
There was a problem hiding this comment.
Yeah I realised it there 😆 I've updated to be a polygon now
| String originalWkt = | ||
| "POLYGON ((170 10, -170 10, -170 10, 170 -10, 170 10))"; | ||
| String expectedWkt = | ||
| "MULTIPOLYGON (((180 10, 170 10, 170 -10, 180 -10, 180 10)), ((-180 -10, -170 -10, -170, 10, -180 10, -180 -10)))"; |
There was a problem hiding this comment.
this isn't valid WKT, note the -170, -10 in the second polygon
There was a problem hiding this comment.
Yeah I must have added there by accident, I have updated a unit test to fail if it's not a valid WKT
ce12583 to
427e0c5
Compare
427e0c5 to
46a9187
Compare
|
Build now |
What does this PR do?
The cause was that when a polygon crosses the antimeridian (180°/-180° longitude line), the system was treating the coordinates as a continuous range rather than recognizing the wrap-around at the antimeridian. For example, with coordinates [[174°,-4°], [-138°,9°]], the system interpreted this as covering all longitudes from -138° to 174° (spanning 312°), instead of the intended area that wraps around the antimeridian (spanning 48°).
This resulted in queries returning results from the entire middle section between the coordinates, rather than just the intended area that crosses the antimeridian boundary. The solution splits polygons that cross the antimeridian into two separate polygons - one covering -180° to the western longitude, and another from the eastern longitude to 180°, ensuring correct spatial queries across the antimeridian.
There's an existing method that solves this issue but it wasn't invoked anywhere. This PR aims to invoke that method
How should this be tested?
Maven compile this package. Then drop the jar file in a DDF box. Perform location searches and also test in Search Areas. Verify if there are still results returning outside of the drawing
Any background context you want to provide?
What are the relevant tickets?
Screenshots
Checklist:
Notes on Review Process
Please see Notes on Review Process for further guidance on requirements for merging and abbreviated reviews.
Review Comment Legend: