Re: [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

signature.asc
Description: PGP signature

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user