Improving StitchNodes "merging" and node "stealing"

[zarzycki]

Currently, StitchNodes takes a candidate node and then marches forward in time, gluing nodes together to form a trajectory. If successful, these nodes are removed from being available to potential "future" cyclones.

This can lead to problems like the below where an earlier storm (e.g., traj 1 on left) can merge with a nearby vortex that is part of a subsequent storm (traj 2 on right). TE still provides two trajectories, but the "merge" of the overlapping points is added to traj 1 when it should be added to traj 2. This causes unphysical movement with traj 1 and can also lead to discontinuity (here, traj 2 is much stronger than traj 1 and traj 1 "jumps" in its intensity time trace, watch the X denoting storm center on the left).

This can be partly alleviated by reducing --range, although this can then arbitrary break trajectories that are "real" if one reduces range too much.

Ideally, if a candidate at a given time N can be claimed by two trajectories, we should prioritize the one that is closest (either in space or as measured by some quantity like PSL) and assign the candidate to that trajectory. I can envision three ways to do this. One would require trajectories to be built up in parallel in StitchNodes (i.e., traj 1 and traj 2 are both incrementally built, then when we get to time N and a candidate is claimed by both traj, we make a decision). Two, we do not remove candidates from the pool of candidates available to future trajectories and then eliminate "overlapping" points that occur in multiple trajectories after one pass of the stitching is done. Three, we perform a pass after StitchNodes is completed to rearrange tracks if it's obvious that the end of traj 1 should belong to the end of traj 2, for example.

[paullric]

How would you handle it if maxgap is greater than 1 and there is a candidate which is closer but is not present at the immediately previous timestep? Would it be beneficial to do forward projection of the traj so as to allow mergedist to be smaller?

…

On Aug 28, 2023, at 2:33 PM, zarzycki ***@***.***> wrote: Currently, StitchNodes takes a candidate node and then marches forward in time, gluing nodes together to form a trajectory. If successful, these nodes are removed from being available to potential "future" cyclones. This can lead to problems like the below where an earlier storm (e.g., traj 1 on left) can merge with a nearby vortex that is part of a subsequent storm (traj 2 on right). TE still provides two trajectories, but the "merge" of the overlapping points is added to traj 1 when it should be added to traj 2. This causes unphysical movement with traj 1 and can also lead to discontinuity (here, traj 2 is much stronger than traj 1 and traj 1 "jumps" in its intensity time trace, watch the X denoting storm center on the left). <https://user-images.githubusercontent.com/10341827/263839227-5cf74a81-8ae0-40cf-afa9-188a4c0d3243.gif> This can be partly alleviated by reducing --range, although this can then arbitrary break trajectories that are "real" if one reduces range too much. Ideally, if a candidate at a given time N can be claimed by two trajectories, we should prioritize the one that is closest (either in space or as measured by some quantity like PSL) and assign the candidate to that trajectory. I can envision three ways to do this. One would require trajectories to be built up in parallel in StitchNodes (i.e., traj 1 and traj 2 are both incrementally built, then when we get to time N and a candidate is claimed by both traj, we make a decision). Two, we do not remove candidates from the pool of future trajectories and then eliminate "overlapping" points after one pass of the stitching is done. Three, we perform a pass after StitchNodes is completed to rearrange tracks if it's obvious that the end of traj 1 should belong to the end of traj 2, for example. — Reply to this email directly, view it on GitHub <#62>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIVPZCYLUDWJHHIYHOK7PLXXUFDJANCNFSM6AAAAAA4CABRLU>. You are receiving this because you are subscribed to this thread.

[zarzycki]

The forward projection of the track could reduce the --range needs in StitchNodes.

I already do something similar in ExTraTrack -- extrapolating a first guess of the next point allows me to reduce the search radius (--range) to about 1/3 of it's default value:
https://github.com/zarzycki/ExTraTrack/blob/4a0842a92a8391efdcf8febf19b7153845f62d84/et-tracker/ExTraTrack.ncl#L773
https://github.com/zarzycki/ExTraTrack/blob/main/functions/extrap_latlon.ncl

Not sure how that'd work with maxgap, although I suppose you could just project dist*N where N is some timestep integer (i.e., if you anticipate the gap being 12 hours instead of 6, you project twice as far out).