Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm using gdalwarp to manipulate SRTM tiles near the the dateline (i.e. 180°, aka the antimeridian). SRTM tiles have a very slight (1/2 pixel) overlap with the meridian. You can see this using gdalinfo:

gdalinfo S16W180.hgt
Driver: SRTMHGT/SRTMHGT File Format
Files: S16W180.hgt
Size is 1201, 1201
Lower Left  (-180.0004167, -16.0004167) (180d 0' 1.50"W, 16d 0' 1.50"S)
Upper Right (-178.9995833, -14.9995833) (178d59'58.50"W, 14d59'58.50"S)

So the source spans the dateline by a tiny amount.

This causes problems with gdalwarp, which ends up creating huge globe-spanning outputs.

gdalwarp -t_srs "epsg:900913" S16W180.hgt test.tif
gdalinfo test.tif
Driver: GTiff/GeoTIFF
Files: test.tif
Size is 1703, 5
Lower Left  (-20037508.330,-1806798.473) (180d 0' 0.00"W, 16d 7'13.00"S)
Upper Right (20032839.451,-1689152.120) (179d57'29.01"E, 15d 5'45.84"S)

Note the longitudes span (almost) the entire globe, and also the number of lines is unexpectedly small (5)

Is this a bug in gdalwarp? If not, what are the correct options to pass to gdalwarp to get a sensible output?

share|improve this question in case you want to experiment. – gravitystorm Sep 24 '12 at 11:45
add the SOURCE_EXTRA Parameter see - try gdalwarp -t_srs epsg:900913 -wo SOURCE_EXTRA=120 S16W180.hgt test.tif – Mapperz Sep 24 '12 at 20:55
maybe use -te argument for "target extents", or fix up the extents first using gdal_translate with a_ullr to overwrite the existing, or -projwin to cut out the bit you want within the bounds – mdsumner Nov 17 '12 at 3:19

It works in two steps:

gdalwarp -te -180 -16 -179 -15 s16W180.hgt test.tif
gdalwarp -t_srs "epsg:3857" test.tif out.tif

The first command kicks off the extra half pixel on the wrong side of the 180° meridian. You get an output file that is 1178P x 1222L.

Alternatively, with gdal_translate:

gdal_translate -a_ullr -180 -15 -179 -16 S16W180.hgt test2.tif
gdalwarp -t_srs "epsg:3857" test2.tif out2.tif

Creating an output file that is 1179P x 1223L.

share|improve this answer

This is problem in the GDAL library. It appears that GDALSuggestedWarpOutput() is giving weird output for width and height of the output file.

I haven't found a way to work around this yet.

share|improve this answer

One easy workaround would be to specify the coordinate system "manually" as a PROJ string. This allows you to use the +over switch that disables wrapping on the antimeridian:

gdalwarp -t_srs \
    "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0 \
        +over +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null \
        +wktext +lon_wrap=-180 +no_defs" \
    S16W180.hgt test.tif

When I do that and then do gdalinfo on the result, I get this:

Corner Coordinates:
Upper Left  (-20037554.726,-1689152.120) (179d59'58.50"E, 14d59'58.50"S)
Lower Left  (-20037554.726,-1804766.925) (179d59'58.50"E, 16d 0' 1.37"S)
Upper Right (-19926099.407,-1689152.120) (178d59'57.11"W, 14d59'58.50"S)
Lower Right (-19926099.407,-1804766.925) (178d59'57.11"W, 16d 0' 1.37"S)
Center      (-19981827.066,-1746959.523) (179d29'59.30"W, 15d30' 2.12"S)

I got the PROJ string (without +over) from looking at the original output of gdalinfo. It was included in an EXTENSION[...] block of the coordinate system.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.