fix: use proj4 +over flag to prevent antimeridian longitude wrapping

[yharby]

Summary

• Use proj4's +over flag on target projection definitions (EPSG:4326 and EPSG:3857) to disable adjust_lon longitude normalization
• Fixes 360° round-trip errors at the antimeridian that make Delatin mesh refinement unconvergeable for global COGs spanning ±180°

Problem

proj4's adjust_lon normalizes longitude to (-π, π], causing:

• forward(-180.001°, lat) → positive easting (wrong sign)
• inverse(-WM_HALF, northing) → +180° instead of -180°

For tiles touching the antimeridian on global EPSG:4326 COGs (e.g. 1.4M×600K pixel DEM), the round-trip error equals the full image width (5625 pixels), producing visibly distorted tile meshes at low zoom levels.

Fix

Add +over to the target projection definitions:

proj4.defs("__WGS84_OVER", "+proj=longlat +datum=WGS84 +over");
proj4.defs("__MERC_OVER", "+proj=merc +a=6378137 +b=6378137 +lat_ts=0 +lon_0=0 +x_0=0 +y_0=0 +k=1 +units=m +nadgrids=@null +over");

The +over flag is safe for longlat and Mercator projections where the 180° meridian is a straight line. Supported since proj4js v2.20.0 (proj4js#530).

Test plan

• Load a global EPSG:4326 COG spanning ±180° longitude (e.g. GEDTM30 at 1440010×600010 pixels)
• Verify z=0 tiles at the antimeridian (x=0, x=2) converge without 5625-pixel error
• Verify regional COGs (EPSG:2193, EPSG:32610) render correctly
• Verify no regressions with non-geographic source CRS

Fixes #352

[yharby]

https://walkthru.earth/objex/?url=https%3A%2F%2Fs3.us-west-2.amazonaws.com%2Fus-west-2.opendata.source.coop%2Fwalkthru-earth%2Fdem-terrain%2FGEDTM30%2Fgedtm30.tif

[kylebarron]

This looks very hacky.

I think we need a deeper consideration of how to handle images spanning the antimeridian.

[yharby]

Thanks, I’ve just discovered #171 and #269 .. will close this !