Near global grid registerd grid tricks -Baf

[joa-quim]

This example uses a SST grid from the OceanColor site, so it's a real case data. Seems NASA is still having troubles with grid vs pixel registration grids. This one intend to be a global grid but it's actually a grid registered not covering the full [-180 180] range. In consequence of it our -Baf fails to do a good job. It also fails to plot more latitude labels because of the image size. If I had used a 15c width then latitudes of 60 degrees would be annotated.

Don't know if there anything that we can do to address first issue then to impose adding also -Rd (in which case the oddities at the poles would disappear).

julia> fname = "/vsizip/vsicurl/https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/SNPP_VIIRS.20191001_20191031.L3m.MO.NSST.sst.9km.nc=gd?NETCDF:SNPP_VIIRS.20191001_20191031.L3m.MO.NSST.sst.9km.nc:sst";

julia> G = gmtread(fname);

julia> grdinfo(G)
Array{GMT.GMTdataset,1} with 1 segments
First segment DATA
9×0 Array{Float64,2}
First segment TEXT
9-element Array{String,1}:
 ": Title: Grid imported via GDAL"
 ": Command: "
 ": Remark: "
 ": Gridline node registration used [Cartesian grid]"
 ": Unrecognized grid file format! Probably not a GMT grid"
 ": x_min: -179.958328247 x_max: 179.958358765 x_inc: 0.0833333380439 name:  n_columns: 4320"
 ": y_min: -89.9583358765 y_max: 89.9583358765 y_inc: 0.0833333356892 name:  n_rows: 2160"
 ": z_min: -1.79499995708 z_max: 33.6599998474 name: z"
 ": scale_factor: 1 add_offset: 0"

julia> imshow(G, projection=:Mollweide, frame=:ag, title="SST - September 2019", colorbar=true,fmt=:PNG, Vd=1)
        ["grdimage  -JW12c -Bag -B+t\"SST - September 2019\" -R-179.95832824707/179.95835876465/-89.958335876465/89.958335876465 -C -P -K > C:\\TMP\\GMTjl_tmp.ps", "psscale  -R -J -Baf -DJMR -C -K -O >> C:\\TMP\\GMTjl_tmp.ps"]

[PaulWessel]

I thought we have protections against those - I am sure we have been here before. And why can't I get the file:

gmt grdconvert "/vsizip/vsicurl/https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/SNPP_VIIRS.20191001_20191031.L3m.MO.NSST.sst.9km.nc=gd?NETCDF:SNPP_VIIRS.20191001_20191031.L3m.MO.NSST.sst.9km.nc:sst" sst.nc ERROR 4: NETCDF:SNPP_VIIRS.20191001_20191031.L3m.MO.NSST.sst.9km.nc:sst: No such file or directory grdconvert [ERROR]: Unable to open NETCDF:SNPP_VIIRS.20191001_20191031.L3m.MO.NSST.sst.9km.nc:sst. grdconvert [ERROR]: ERROR reading file (metadata) with gdalread. grdconvert [ERROR]: gmt_M_err_trap: 7 grdconvert (gmt_api.c:4643(api_import_grid)): Could not open file [/vsizip/vsicurl/https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/SNPP_VIIRS.20191001_20191031.L3m.MO.NSST.sst.9km.nc=gd?NETCDF:SNPP_VIIRS.20191001_20191031.L3m.MO.NSST.sst.9km.nc:sst] [Session gmt (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18) [Session gmt (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)

[joa-quim]

Try without the quotes. It worked for me.

[PaulWessel]

No. You mean grdconvert works for you or that your plot works?

[joa-quim]

I meant the grdconvert download the data and created the sst.nc file

[PaulWessel]

Strange, so if you copy/paste my command above it works?

[joa-quim]

Ah, GDAL is cheating. I actually also have the file in the same dir and it was reading from it. Once I renamed it, got error too.

But sill about the plot, GMT command line reproduces the same behavior of my plot if I specify the -R

gmt grdimage  -JW12c -Bag -B+t"SST - September 2019" -R-179.95832824707/179.95835876465/-89.958335876465/89.958335876465 -C -P sst.nc > lixo.ps
grdimage [ERROR]: (x_max-x_min) must equal (NX + eps) * x_inc), where NX is an integer and |eps| <= 0.0001.
gmt grdimage (gmtlib_read_grd_info): Use grdedit -A on your grid file to make region and increments compatible [sst.nc]

but not if I remove the -R (which was introduced by Julia automatically)

[joa-quim]

You can download the file from

https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/SNPP_VIIRS.20191001_20191031.L3m.MO.NSST.sst.9km.nc

[PaulWessel]

OK, thanks. Gotta do family FaceTime now so it will be a while until debug.

[joa-quim]

And dinner time (but must prepare it first)

[PaulWessel]

Nice, yes probably best after cooking it.