Adding NOAA tide prediction feature to next_pass

[ifenni]

Tis PR includes a new tide prediction feature. By running next-pass with the argument -t, the user will see

1. a new column "Tide in m, MLLW (High/Low) " in the text outputs of next-pass for Sentinel-1 and Sentinel-2 overpasses, and
2. the full tide information (all stations) displayed in the pop-up of the overpasses geometries along with the tide station locations and information in the "satellite_overpasses_map.html" file

In the new "tide_prediction.py" function, we get the tide information through 2 calls:
hourly_resp = session.get(
NOAA_URL, params={**base_params, "product": "predictions", "interval": "h"}, timeout=10
)
hilo_resp = session.get(
NOAA_URL, params={**base_params, "product": "predictions", "interval": "hilo"}, timeout=10
)

• The first call gets us one prediction per hour of the MLLW (Mean Lower Low Water) information in meter. We give the user the interpolated water level value in meters above MLLW from the hourly predictions.
• The second call (hilo) doesn't have a fixed time resolution, it returns only the turning points (high/low tide events), typically 2–4 per day depending on the tidal regime. By calling "_find_nearest_hilo_label" we provide the user with whichever turning point (H, HH, L, LL) is closest in time to the overpass, whether that's before or after it. then "_find_tide_direction" uses the hourly data we already have to detect the phase direction (rising/falling) around the overpass time.

Note that the code displays only the tide information from the closest station to the centroid of the intersection between the AOI and the overpass geometry in the table text output. On the other hand, it lists all stations values ordered the same way as the overpasses dates in the "satellite_overpasses_map.html" file. Along with the tide station location and information, this allows the user the better interpret the tide values and H/L and phase direction information.

[ehavazli]

I found three actionable regressions in this change.

The most important one is that --tide can turn a Sentinel overpass query into a hard failure when NOAA station metadata is unavailable, because the extra station lookup runs outside the existing error-handling path. The other two are backward-compatibility breaks: next_sentinel_pass() now requires a new positional argument, and find_next_overpass() assumes every Namespace already has a tide attribute.

I also reproduced the compatibility regressions locally with pytest -q tests/test_sentinel_pass.py tests/test_next_pass_cli.py, which currently fails on those call sites.

[ehavazli]

This second station lookup is outside the error-handling path used by get_tide_info_batch(). On a fresh checkout we do not ship noaa_stations.json, so the first --tide run will hit NOAA here; if that request fails or times out, next_sentinel_pass() raises instead of returning results without station markers. Please catch RequestException around this call or reuse the already-handled lookup result from the batch helper.

[ehavazli]

Making arg_tide mandatory is a backward-incompatible API change. Existing callers still use the 4-argument form, and the current branch reproduces that as TypeError in the Sentinel tests and the CLI subprocess stub. Defaulting this to False would preserve compatibility while keeping the new feature opt-in.

[ehavazli]

find_next_overpass() used to work with hand-built argparse.Namespace objects that only populated the fields it needed. This direct attribute access now raises AttributeError for existing programmatic callers and tests that haven’t been updated yet. Using getattr(args, 'tide', False) keeps the new flag optional for older call sites.