CRS change crashes with grid-based projections when layer resolution limits are configured #12627

[rowheat02]

Description

This PR fixes the CRS change when the target projection uses a datum grid and some layers have minResolution or maxResolution configured.

The resolution conversion was transforming a point to the target CRS and then using it with the source projection. This could generate invalid coordinates and crash the CRS change when the target projection requires a datum-grid correction.

While fixing this, we also found an issue when switching the CRS back and forth. For example:

EPSG:25830 → EPSG:4326 → EPSG:25830

The converted resolution limits were snapped to the resolution list, so they did not return to their original values. Because of this, layers that were visible before the CRS change could become invisible after switching back.

The limits are now converted using the meters-per-unit ratio without snapping, making the conversion reversible.

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/geosolutions-it/MapStore2/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (check one with "x", remove the others)

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

Issue

What is the current behavior?

#12627
The CRS change can fail with datum-grid projections when layer resolution limits are configured. Switching the CRS back and forth can also change the limits and make visible layers invisible.

What is the new behavior?

The CRS changes without crashing, and layer resolution limits remain stable after multiple CRS changes.

Breaking change

Does this PR introduce a breaking change? (check one with "x", remove the other)

• Yes, and I documented them in migration notes
• No

Other useful information

[tdipisa]

Converted to draft waiting for 2026.02.00 to be out

[offtherailz]

Good,
Two things before merge in inline suggestions you can apply:

1. guard + warning if conversion fails
2. fix to the unit coneversion (if passing, for instance, from meeters to degrees etc). I attached a test. Please verify that makes sense to you too.

Could you please verify that the changes I suggested still fits our use case and they work well also in different latitude with inverse conversion @rowheat02 ? thank you.

[offtherailz]

Pushed a commit on top of yours with the fix for the problem you found.

The conversion itself was fine after the suggestions; what broke the round trip was the snap.
snapToResolution used getResolutions(targetCRS), and that returns whatever is in
mapOptions.view.resolutions for any SRS because
updateMapResolutionsOnCrsChangeEpic writes that array with view.projection stripped. Since the
thunk runs before that epic, on the way back the limits in metres were snapped onto the previous
CRS ladder in degrees: maxResolution became ~0.703125 metres, i.e. the layer only showed up below
1:2657. Snapping between two ladders is also a ratchet, so the limits shrank on every switch.

So the limits are now converted through the meters-per-unit ratio of the two CRS - the same ratio
closestMatchedZoom uses to keep the map scale, which is what keeps the layer's relation with the
view resolution - and they are no longer snapped, so the conversion is reversible. No point
transform is involved anymore, which also removes the original #12627 crash at the root.

What to test:

• a map in EPSG:25830 with a layer having min/maxResolution, switch to EPSG:4326 and back: the
  layer stays visible and the limits return to the original values (repeat a few times, they must
  not drift);
• the Visibility limits panel in the layer settings must keep showing the same scale denominators
  in every CRS (the limit is a scale, only its unit changes);
• after the round trip, zooming out past the max scale must still hide the layer, so the threshold
  is still where it was.

Two pre-existing problems came up while testing this, unrelated to the PR; I will open them
separately: the map scale drifts one zoom level per CRS switch, and mapOptions.view.resolutions
is saved without `view.projectis lying for any other caller.

[offtherailz]

Backport failed for 2026.02.xx: couldn't find remote ref 2026.02.xx.
Please ensure that this GitHub repo has a branch named 2026.02.xx.

[allyoucanmap]

@rowheat02 the automatic backport failed, please provide a new backport

[rowheat02]

Backport for 2026.02.xx has been created manually: #12762