Working with 360 and 180 longitude domains in GDAL

There are many times where planetary data is create using a Longitude range from 0 to 360 (instead of the more common -180 to 180 Longitude range used for most Earth-base applications). Below are some notes to work-around some of these quirks in GDAL (for images and some vector layers).

High-level tips:

  1. Reminder: For a global mosaic using 0 to 360 (e.g. merc, mollweide equirectangular, simple cyl) always set a central meridian (clon) = 180.0 (which has the effects of setting X=0.0 meters at the center of the map). This definitely can help many applications (not all – but many).
  2. PROJ library has two settings +wrap_lon and +over which you can set which in a projection’s definition (thus gdalwarp and ogr2ogr can benefit). For more see.
  3. gdalwarp and ogr2ogr also support a variation on this set as –config CENTER_LONG 180. This may only help in degrees.

So if in a meters map projection (e.g. equirectangular using central meridian=180), GDAL should do the right thing. Examples:

where: > gdalsrsinfo IAU_2015:49915

PROJ.4 : +proj=eqc +lat_ts=0 +lat_0=0 +lon_0=180 +x_0=0 +y_0=0 +R=3396190 +units=m +no_defs

raster to 0 - 360 (map projected meters):

gdalwarp -r bilinear -t_srs IAU_2015:49915 in_mars_180_meters.tif out_mars_360_meters.tif

where: > gdalsrsinfo IAU_2015:49910

PROJ.4 : +proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +R=3396190 +units=m +no_defs

raster to -180 - 180 (map projected meters):

gdalwarp -r bilinear -t_srs IAU_2015:49910 in_mars_360_meters.tif out_mars_180_meters.tif


So if in a Long/Lat degrees you can use the commands below. Note the use of -te (target extent) can help force the correct extent. When going from any projection to another projection it can be tricky for GDAL to calculate your intended extent.

where: gdalsrsinfo IAU_2015:49900

PROJ.4 : +proj=longlat +R=3396190 +no_defs

raster to 0 - 360 (degrees):

gdalwarp -r bilinear --config CENTER_LONG 180 -t_srs IAU_2015:49900 -te 0 -90 360 90 in_mars_180_degrees.tif out_mars_degrees_360_degrees.tif

raster to -180 -180 (degrees):

gdalwarp -r bilinear --config CENTER_LONG 0 -t_srs IAU_2015:49900 -te -180 -90 180 90 in_mars_360_degrees.tif out_mars_180_degrees.tif

vector to 0 - 360 (degrees):

ogr2ogr out_mars_360_degrees.shp in_mars_180_degrees.shp --config CENTER_LONG 180 -t_srs IAU_2015:49900

vector to -180 -180 (degrees):

ogr2ogr out_mars_180_degrees.shp in_mars_360_degrees.shp --config CENTER_LONG 0 -t_srs IAU_2015:49900

Lines and Polygons require an extra step to split at the 180 boundary. Thus we can use attempt to use -wrapdateline. For more see. I have not test moving from 180 to 360 and splitting.

ogr2ogr -t_srs IAU_2015:49900 -s_srs IAU_2015:49900 -wrapdateline --config CENTER_LONG 0 out_mars_180_split_degrees.shp in_mars_180_degrees.shp


For giant files you can play games with GDAL virtual format. I use this all the time to virtual create a 0 to 360 map from a -180 to 180 map. You can even create a -180 to 360 virtual mosaic ideal for WMS servers. Check out the bottom (step “e” is the trick which requires manually editing a text editor): UserDocs/RasterProcTutorial – GDAL

There is even a basic script to help automate this (at least 360 to 180): https://github.com/perrygeo/ncvrt


tip: In QGIS or Arc, you can set a projected system (meters) with the central meridian = 180. That should wrap the map.

tip: For QGIS to wrap from 360 to 180, virtually, you can setup a custom projection using +lon_wrap:

+proj=longlat +R=3396190 +no_defs +lon_wrap=180
This allows for a virtual wrap similar to the VRT trick above.

tip: for ArcGIS Pro there is a nice little setting you define called Enable wrapping around the date line.

1 Like