Fix north-south flip in FFT filters for descending-coordinate grids

[gaoflow]

Fixes #586

Problem

The FFT-based filters (derivative_*, upward_continuation, reduction_to_pole, etc., all routed through apply_filter) silently produced an output flipped along a dimension when the input grid stored that coordinate in descending order. This happens for grids read from some file formats (e.g. ERMapper/ERS) where the northing decreases with row index. @santisoler reproduced this in the issue.

Root cause

In harmonica/filters/_utils.py::apply_filter, the inverse FFT (xrft.ifft) always returns the grid in ascending coordinate order. The code then did:

filtered_grid = filtered_grid.assign_coords(
    {dims[1]: grid[dims[1]], dims[0]: grid[dims[0]]}
)

assigning the original (descending) coordinates onto the ascending result — mislabelling every row/column so the data ends up flipped relative to its coordinates. (The frequency coordinates built by xrft also assume positive sample spacing.)

Fix

Sort the grid to ascending order before transforming, and restore the original coordinate order afterwards via reindex. Grids already in ascending order take the same path as before (no sortby/reindex), so their results are unchanged.

Reproduction / verification

A minimal synthetic check (no external data needed): apply a filter to a grid and to the same physical grid with one coordinate reversed; after aligning on that coordinate the two results must be identical.

filter	rel. mismatch (desc vs asc), before → after
derivative_upward	~1.0 (flipped) → 0.0
upward_continuation	~1.0 → 0.0
reduction_to_pole	~1.0 → 0.0

• Added a parametrised regression test (northing and easting) in test/test_transformations.py that fails on main and passes with the fix.
• Full test/test_transformations.py + test/test_filters.py suite: 62 passed (was 60). ruff check / ruff format --check clean.

[santisoler]

Hi @gaoflow. Thanks for opening the PR. I'm suspecting this contribution made significant use of generative AI software to produce the code and the PR description text. Could you confirm this is the case? Could you disclose how generative AI software was used in the process of opening this PR?

[gaoflow]

Yes — you're right, and thanks for asking directly.

I work with an AI coding agent (Anthropic's Claude). It helps me locate and reproduce the bug, drafts the patch and the tests, and drafted this PR description. It runs under my GitHub account and my direction: I review the diff before it goes out, the tests are run locally, and I'm accountable for what's submitted. The mismatch numbers in the table are from real runs, not written prose.

The description is also too long, which is the other half of what you picked up on. That one's a fair hit — I'll keep them shorter.

If Harmonica or Fatiando would prefer not to accept AI-assisted contributions, or wants the disclosure recorded in the commit message or changelog, say which and I'll comply — including closing this if that's the call. #586 is your issue and the fix is four lines, so nothing is lost if you'd rather write it yourself.