[matschaer]

The generic path of interp2poi and interp2grid (all KDTree methods, and griddata for linear / cubic) ran in latitude/longitude degrees whenever the grid had lat/lon coordinates, even for native LV95 grids. In Switzerland a degree of longitude is about 0.68 of a degree of latitude, so east–west distances counted about 1.45 times too much. The neighbors, the IDW weights and the triangulations were distorted.

Coordinates are now always in meters:

• Native coordinates first. Native coordinates projected in meters are used even when lat/lon coordinates are present (get_coords_name_crs(prefer_projected=True), only in the generic path).
• CRS choice:
  • if one side (source or target) is in meters, its CRS is used;
  • if both are, the larger grid's CRS;
  • if both are lat/lon, LV95 when the target is within lv95_max_offset (700 km, env GRID_PROCESS__lv95_max_offset) of the LV95 central northing, otherwise earth-centered earth-fixed coordinates (ECEF), which supports global grids.
• linear, linear_3D and cubic raise a clear error in the ECEF case, since a triangulation is degenerate there. For regular lat/lon grids, try_reg=True remains available.
• Altitude column. Height methods no longer force Swiss coordinates; the altitude is always the last coordinate column.

Further fixes found along the way (separate commits):

• Sphere datum. Lat/lon or rotated-pole CRSs on a sphere (CF earth_radius) are treated as WGS84, so the datum shift to LV95 (about 180 m) is applied. parse_grid_mapping builds such CF mappings directly (pyproj.CRS.from_cf took about 0.3 s per call) and caches the other ones.
• Numpy values in grid mappings. set_grid_mapping and parse_grid_mapping accept numpy values (e.g. a standard_parallel array).
• create_dst_grid_from_src now spans exactly the reprojected source domain. Before, it was e.g. 80 km too wide for ICON-CH2 in LV95 and missed 28 km of IFS.
• Longitude convention and 360° seam. With lat/lon sources whose longitude convention (0..360 or −180..180) differs from the target's, the source was sliced to the wrong longitudes (wrong values in the generic path) and try_reg=True returned NaN. Global grids are now also interpolated across their 360° seam. The longitude buffer of the slicing is widened by 1/cos(latitude).
• Flat neighborhoods in temp. POIs whose neighbors all have the same altitude (pole rows of lat/lon grids, flat orography) now use the fixed lapse rate fallback instead of raising an error.
• Unstructured destinations. interp2grid raises a clear error for an unstructured destination grid (not supported).
• Two global example notebooks:
  • GFS 2 m temperature to 33 stations worldwide, compared with GHCN-hourly observations;
  • ERA5 2 m temperature to the IFS 0.1° grid.

Behaviour changes

• Values change slightly for grids previously searched in lat/lon: neighbors at about one grid spacing, the IDW weights, and linear/cubic results. This includes native LV95 grids with lat/lon coordinates.
• linear, linear_3D and cubic raise an error for geographic domains beyond lv95_max_offset.
• get_grid_crs / parse_grid_mapping return lat/lon and rotated-pole CF mappings on a sphere based on WGS84.
• create_dst_grid_from_src produces different (correct) bounds.
• set_grid_mapping writes the grid mapping with sorted keys.
• temp no longer raises for flat neighborhoods.

Benchmark (124 cases in fresh processes: the operational data4web POIs and seamlessweatherprovider grid cases, the notebook cases, the MIR comparison cases and others; main and the branch run back to back):

• Totals: on par with main, within run-to-run noise. In the last run, first calls took 154 → 164 s and next calls 132 → 134 s (operational next calls 108.2 → 109.7 s). An earlier run gave the branch about 10 % faster.
• Per case: the median first-call difference is +14 ms. Only the memory-bound large-k cases vary by more, in both directions between runs.
• Longitude fix, measured on the 47 operational cases: identical runtime. Values are identical, except for tie-breaking between exactly equidistant neighbors (ICON-CH2 LV95 to the 2 km grid, which is offset by half a cell).
• Regular grid path (topographic descriptors of data4web from the topo catalog v2, dask arrays, to the 5622 production POIs; warm-up, then main and the branch alternated over two rounds): the horizon with nearest (13.5 s) and 3 mosmix descriptors with linear (1.4 s) are on par with main, with identical values and peak memory. grid-process itself takes 0.03–0.06 s of each call in both versions; the rest is dask reading the zarr chunks.

The benchmark scripts are kept outside the repository.

---

Related issue

None

---

Checklist

• Code is well documented and follows project conventions (linted, formatted)
• CHANGELOG updated (if applicable)
• License header is added to all new files (the only new files are the two notebooks, which, like the existing ones, have no header)
• For a new contributors, their name has been added to the AUTHORS file
• No sensitive data or secrets are exposed
• Unit tests added covering the new code