Skip to content

Update Wfs to use unwrap Antimeridian functionality#6956

Open
nickchooleidos wants to merge 1 commit intocodice:masterfrom
nickchooleidos:fix-antimeridian-support-wfs
Open

Update Wfs to use unwrap Antimeridian functionality#6956
nickchooleidos wants to merge 1 commit intocodice:masterfrom
nickchooleidos:fix-antimeridian-support-wfs

Conversation

@nickchooleidos
Copy link

@nickchooleidos nickchooleidos commented Feb 2, 2026

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

image image

Checklist:

  • Documentation Updated
  • Update / Add Threat Dragon models
  • Update / Add Unit Tests
  • Update / Add Integration Tests

Notes on Review Process

Please see Notes on Review Process for further guidance on requirements for merging and abbreviated reviews.

Review Comment Legend:

  • ✏️ (Pencil) This comment is a nitpick or style suggestion, no action required for approval. This comment should provide a suggestion either as an in line code snippet or a gist.
  • ❓ (Question Mark) This comment is to gain a clearer understanding of design or code choices, clarification is required but action may not be necessary for approval.
  • ❗ (Exclamation Mark) This comment is critical and requires clarification or action before approval.

@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.


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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice find - didn't realize we already had a method to solve this problem

@jlcsmith
Copy link
Member

jlcsmith commented Feb 2, 2026

note - this fix is needed into the 2.29.x branch as well

@nickchooleidos nickchooleidos force-pushed the fix-antimeridian-support-wfs branch from 36698d2 to ce12583 Compare February 3, 2026 00:38
@nickchooleidos
Copy link
Author

Build now

@Test
public void testAntimeridianCrossingIsSplitWithNegativeCoordinatesa() {
String originalWkt =
"POLYGON ((170 10, -170 10, -170 10, 170 -10, 170 10))";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)))";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this isn't valid WKT, note the -170, -10 in the second polygon

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I must have added there by accident, I have updated a unit test to fail if it's not a valid WKT

@nickchooleidos nickchooleidos force-pushed the fix-antimeridian-support-wfs branch from ce12583 to 427e0c5 Compare February 3, 2026 06:09
@nickchooleidos nickchooleidos force-pushed the fix-antimeridian-support-wfs branch from 427e0c5 to 46a9187 Compare February 4, 2026 04:51
@nickchooleidos
Copy link
Author

Build now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants