GreatCircle.Arc antimeridian split fails at low npoints for mid-arc crossings

[thomas-hervey]

Summary

The fix from #71 resolves antimeridian splitting at npoints=100 but the split logic still fails at low npoints values (such as npoints=10) for routes where the crossing occurs mid-arc.

Affected version:

arc@1.0.0-beta.1

Reproduction

Testing examples on geojson.io shown in this comment on #71 .

You can also test directly with these arcs...

import { GreatCircle } from 'arc';

// FAIL: Returns LineString (should be MultiLineString)
// Tokyo → LAX
new GreatCircle({ x: 139.7798, y: 35.5494 }, { x: -118.4085, y: 33.9416 }).Arc(10, { offset: 10 }).json();

// Shanghai → SFO
new GreatCircle({ x: 121.81, y: 31.14 }, { x: -122.38, y: 37.62 }).Arc(10, { offset: 10 }).json();

// PASS: Returns MultiLineString
//  Auckland → LAX
new GreatCircle({ x: 174.79, y: -36.85 }, { x: -118.41, y: 33.94 }).Arc(10, { offset: 10 }).json();

Root cause hypothesis

• When npoints is low, the step size is large enough that a single step can leap a large number of degrees, such as from e.g. 172° to -175° without the crossing condition being satisfied.

• Auckland possibly passes because the first step already crosses 180° before the step size becomes relevant. The start of the arc is only ~5° longitude from the antimeridian.

@springmeyer @jgravois

[thomas-hervey]

Draft PR: #76 . First commit only contains a new test.

[jgravois]

I'd assume the behavior documented here isn't a regression introduced when the library was ported to TS, but rather existed in 0.1.4 (and prior).

is that correct @thomas-hervey?

[thomas-hervey]

Yes @jgravois — the low-npoints failure is pre-existing in 0.1.4, not a regression from the TypeScript conversion. However, I am continuing to run a few other tests first.

I swapped arc@0.1.4 into @turf/great-circle locally and ran the same npoints=10 test against all three routes:

FAIL  Tokyo → LAX: expected MultiLineString, got LineString
PASS  Auckland → LAX: split at antimeridian, lat=-32.8252
FAIL  Shanghai → SFO: expected MultiLineString, got LineString

Same result as 1.0.0-beta.1. The behavior is identical.

Root cause (in 0.1.4): When npoints is low, the step size is large enough that a single interpolated step leaps from e.g. ~172° to ~-175° — a jump of >180°. The bHasBigDiff flag fires correctly, but the subsequent condition on line 181 of the original arc.js:

if (bHasBigDiff && dfMaxSmallDiffLong < dfDateLineOffset) {

...requires that all non-crossing inter-point diffs stay below dfDateLineOffset (10°). At low npoints the other steps in the arc can have large-but-sub-180° diffs (e.g. ~50° between normal consecutive points), so dfMaxSmallDiffLong exceeds 10° and the entire split path is skipped.

One additional note: in my TS port in PR #55 I had changed the dfMaxSmallDiffLong < dfDateLineOffset guard to dfMaxSmallDiffLong < dfDiffSpace (dfDiffSpace = 350). I believe that this loosened the condition too much and so that change may be worth a closer look separately, but it doesn't affect the core low-npoints failure which exists in both versions.

I'm investigating a fix using an analytical bisection approach (Option B) that finds the exact antimeridian crossing fraction via interpolate() and doesn't rely on the heuristic at all.

[jgravois]

thanks for confirming. 🤙 if you get tangled up and it turns out it would be helpful to publish v1.0.0 as a patch for turf in the interim, just say the word.

[thomas-hervey]

That's not a bad suggestion, I'll let you know. I will be offline through Sunday but will wrap up those tests this on Monday and we can cut a patch either way early next week. Feel free if you wanted to take a stab at it first, but no pressure from my end.

Posting this update on #75 for visibility.

[thomas-hervey]

I forgot to add a comment here, but #76 targets resolving this issue. My current goal is to get #76 merged down, then rebase #77 and pull it out of draft for review.

[thomas-hervey]

This was completed by #76 . Closing.