Request for earth_relief_01s in area of no SRTM yields incorrect 15s resampled grid

[PaulWessel]

Requests for @earth_relief_01s will be filled in with @earth_releif_15s in the oceans since there are no SRTM tiles there. However, in the case below there are no land area so we end up with earth_relief_15s being resampled at 1s. Because the chosen region is not a multiple of 15s it gets truncated inward, not outward, and we end up with a strange strip near the north border. A plain map using earth_relief_15s directly has no such issues.

Script to produce the problem:

#!/usr/bin/env bash
RR2="-R-108.444/-108.3724/23.53499/23.6057"
gmt begin two png
  gmt subplot begin 2x1 -Fs10c -B -BwsNE $RR2
    gmt grdimage @earth_relief_15s.grd -V -JM? -c
    gmt grdimage @earth_relief_01s.grd -V -c
  gmt subplot end
gmt end show

Result:

[PaulWessel]

The issue seems to be this: The users desired w/e/s/n are not exact multiples of the grid increment (here 1s). That should be fine: this sets the plot region, not a particular grid domain. However, as we assemble the required grid from srtm tiles and earth_relief_15s via grdblend, the grdblend module creates the final composite grid that is returned to grdimage. Ah, but the GMT_Create_Data call to make that grid uses the plot region w/e/s/n and the chosen grid increments (here 1s) to make that grid. Yikes, this w/e/s/n cannot be used as is for making the grid, since our default procedure for creating a grid from w/e/s/n and dx/dy is to adjust dx/dy if they do not fit evenly into the range. So we end up with a modified dx/dy that no longer is 1s. There may be other issues downstream from this but I will start here.
Solution: grdblend needs a way to adjust the w/e/s/n for building the grid, since the given w/e/s/n is a plot domain. It then internally knows to make the w/e/s/n exact integer multiples of dx/dy and create the grid thus. This grid with a slightly different region is returned by to grdimage, which sets up plotting with the original plot region (which will possibly clip fractions of pixels)

I think the solution is to recognize that when these srtm blend requests are given by a plot module we must make the w/e/sn adjustment. Someone running grdblend on the command line to make a grid should get the default treatment (with warnings).