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.hgtDriver: SRTMHGT/SRTMHGT File FormatFiles: S16W180.hgtSize 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.tifgdalinfo test.tifDriver: GTiff/GeoTIFFFiles: test.tifSize 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?
أكثر...
gdalinfo S16W180.hgtDriver: SRTMHGT/SRTMHGT File FormatFiles: S16W180.hgtSize 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.tifgdalinfo test.tifDriver: GTiff/GeoTIFFFiles: test.tifSize 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?
أكثر...