[GRASS-user] EPSG 32633 and spatial resolution for hourly LST product from Copernicus

[Nikos Alexandris]

Nikos wrote:

>> gdalinfo NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":LST
>> Driver: netCDF/Network Common Data Format
>> Files: g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc
>> Size is 8064, 3584
>> Coordinate System is:
>> GEOGCS["unknown",
>>     DATUM["unknown",
>>         SPHEROID["Spheroid",6378137,298.2572326660156]],
>>     PRIMEM["Greenwich",0],
>>     UNIT["degree",0.0174532925199433,
>>         AUTHORITY["EPSG","9122"]]]
>> Origin = (-180.022321429103613,80.022321429103613)
>> Pixel Size = (0.044642858207226,-0.044642858207226)
>[...]
>> Corner Coordinates:
>> Upper Left  (-180.0223214,  80.0223214) (180d 1'20.36"W, 80d 1'20.36"N)
>> Lower Left  (-180.0223214, -79.9776824) (180d 1'20.36"W, 79d58'39.66"S)
>> Upper Right ( 179.9776872,  80.0223214) (179d58'39.67"E, 80d 1'20.36"N)
>> Lower Right ( 179.9776872, -79.9776824) (179d58'39.67"E, 79d58'39.66"S)
>> Center      (  -0.0223171,   0.0223195) (  0d 1'20.34"W,  0d 1'20.35"N)

Markus:

>apparently the center of the left-most column is -180, therefore forcing
>the corner to -180 would shift the grid by half a cell.

>> Import using r.in.gdal, _without_ any of `-l` or `-a` and then I get the
>> closest to the reported spatial resolution. Else, with `-a`, for
>> example, the spatial resolution is not as close to the "original" one.
>> Makes sense?

>what would be the output resolution and extends with r.in.gdal -a?
>Generally r.in.gdal -a provides the best results.

Importing with/out `-a` and `-al`:

for MAP in $(g.list raster pattern=import*) ;do echo $MAP && r.info -g $MAP && echo ;done

import
360 degree EW extent is exceeded by 0.00019226 cells
north=80.0223214291667
south=-79.9776823855556
east=179.977687153889
west=-180.022321429167
nsres=0.0446428582072328
ewres=0.0446428582072241
rows=3584
cols=8064
cells=28901376
datatype=CELL
ncats=0

import_with_a
north=80.0223333333333
south=-79.9634444444444
east=179.945666666667
west=-180.022333333333
nsres=0.0446388888888889
ewres=0.0446388888888889
rows=3584
cols=8064
cells=28901376
datatype=CELL
ncats=0

import_with_al
north=80.0223333333333
south=-79.9634444444444
east=179.968
west=-180
nsres=0.0446388888888889
ewres=0.0446388888888889
rows=3584
cols=8064
cells=28901376
datatype=CELL
ncats=0

The first "import" map's ns/ew resolution is closest to the original.

>>
>> Better to cut off the west side (?):
>> ```
>> g.region raster=g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc_LST -pag
>w=-180 e=180
>
>this shifts the grid by half a cell to the east. The -a flag does not make
>sense because 1) you want to force new extends, 2) there is no resolution
>given for use with the -a flag.

More precise, this shifts the computational's region grid by half a
cell to the east. Right?

If the default of `-a` is "to align the region resolution to match the
region boundaries", won't the above command try to modify the spatial
resolution, of the computational region, so as to perfectly fit inside
the currently set, of user provided, boundaries?

If, say, the region's boundaries are n=80 s=-80 w=-180 e=180 and the
raster map's rows and columns 3584 and 8064 respectively, won't the
above command try to adjust the region's resolution so as to fit these
cells inside these boundaries?


>Using g.region -pg defaults to g.region -g. Use either -p or -g.o

I see.

Nikos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20181001/3908e037/attachment.sig>