Fixing NetCDF/GRD crossing 180 meridian to work with in QGIS

Gridded data from scientific software could be awkward from the GIS stack point of view. No coordinate reference system in metadata, and extent with longitudes > 180 degrees.

...
Corner Coordinates:
Upper Left  ( 159.9500000,  72.0281250)
Lower Left  ( 159.9500000,  49.4718750)
Upper Right (     200.050,      72.028)
Lower Right (     200.050,      49.472)
Center      ( 180.0000000,  60.7500000)
...

GDAL still handles it, but reprojecting leads to data disappearance in the X>180 part of the dataset. To use it and explore as continuous dataset simple gdalwarp workaround could be used:

gdalwarp -s_srs "+proj=longlat +ellps=WGS84" -t_srs "+proj=merc +lon_0=180 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs" -wo SOURCE_EXTRA=1000 --config CENTER_LONG 0 source.grd fixed.tif

There are two things to pay attention at:

• -t_srs "+proj=merc +lon_0=180 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs" — using artificial CRS, copy of EPSG:3857 but with longitude of origin shifted to 180 degrees. It would allow to build a map in world cylindrical projection, but without break.
• -wo SOURCE_EXTRA=1000 --config CENTER_LONG 0 — to handle source dataset problems with invalid behaviour related to 180 degree and how WGS84 works in GDAL (-180:180)

After that, using the same "+proj=merc +lon_0=180 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs" as CRS for a QGIS project, seamless visualization is available.