[GRASS-user] raster pixel value

GRASS GRASS user
1

Hi

i was wondering how the value of a pixel is determined when multiple data points are located within a pixel, for 2d and 3d pixel. I assume it is based on the interpolation methodology of the raster. is this correct.
for large pixels where only data point is located within it, can the pixel have a different value than that of the data point if through the interpolation and due to surrounding points it generates a different value?
thks

2

* Francois Chartier <fra.chartier@gmail.com> [2019-03-10 09:38:13 -0400]:

Hi

i was wondering how the value of a pixel is determined when multiple data
points are located within a pixel, for 2d and 3d pixel. I assume it is
based on the interpolation methodology of the raster. is this correct.
for large pixels where only data point is located within it, can the pixel
have a different value than that of the data point if through the
interpolation and due to surrounding points it generates a different value?
thks

Dear Francois,

your questions are a bit sketchy. What exactly are trying to do?

How the value of a pixel is determined when multiple data points are
located within a pixel?

Which multiple data points are you referring to?

Multiple raster data cells, which you get when you modify the
computational region (i.e. when you go from a given spatial resolution
to a coarser one)?
Did you try to resample a raster data set and wonder how the new cell's
value is computed? Which module did you try to use? Which methods?

Vector data points? Which interpolation module did you try?

Nikos

3

I am asking a question on the fundamentals not on a particular example on how the value within a raster cell is determined when multiple vector data points are located within a raster cell footprint.
I use RST mostly and sometimes IDW for vector data points.

Le dim. 10 mars 2019 à 10:05, Nikos Alexandris <nik@nikosalexandris.net> a écrit :

Hi

i was wondering how the value of a pixel is determined when multiple data
points are located within a pixel, for 2d and 3d pixel. I assume it is
based on the interpolation methodology of the raster. is this correct.
for large pixels where only data point is located within it, can the pixel
have a different value than that of the data point if through the
interpolation and due to surrounding points it generates a different value?
thks

Dear Francois,

your questions are a bit sketchy. What exactly are trying to do?

How the value of a pixel is determined when multiple data points are
located within a pixel?

Which multiple data points are you referring to?

Multiple raster data cells, which you get when you modify the
computational region (i.e. when you go from a given spatial resolution
to a coarser one)?
Did you try to resample a raster data set and wonder how the new cell’s
value is computed? Which module did you try to use? Which methods?

Vector data points? Which interpolation module did you try?

Nikos

4

* Francois Chartier <fra.chartier@gmail.com> [2019-03-10 10:56:40 -0400]:

I am asking a question on the fundamentals not on a particular example on
how the value within a raster cell is determined when multiple vector data
points are located within a raster cell footprint.
I use RST mostly and sometimes IDW for vector data points.

Then, from https://grass.osgeo.org/grass76/manuals/rasterintro.html:

"Raster input maps are automatically cropped/padded and rescaled (using
nearest-neighbour resampling) to match the current region."

and

"GRASS raster map processing is always performed in the current region
settings (see g.region), i.e. the current region extent and current
raster resolution is used. If the resolution differs from that of the
input raster map(s), on-the-fly resampling is performed (nearest
neighbor resampling). If this is not desired, the input map(s) has/have
to be resampled beforehand with one of the dedicated modules.

The built-in nearest-neighbour resampling of raster data calculates the
centre of each region cell, and takes the value of the raster cell in
which that point falls.

If the point falls exactly upon a grid line, the exact result will be
determined by the direction of any rounding error. One consequence of
this is that downsampling by a factor which is an even integer will
always sample exactly on the boundary between cells, meaning that the
result is ill-defined."

Likely there is more on the subject.

Nikos

5

Following up, why are there differences between GDAL and GRASS GIS in
the following example?

This ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map, subject to `gdalinfo`:

gdalinfo OCDENS_M_sl1_5km_ll.tif -nogcp -nomd -norat -noct -nofl
Driver: GTiff/GeoTIFF
Files: OCDENS_M_sl1_5km_ll.tif
Size is 7200, 2987
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-180.000000000000000,87.370000000000005)
Pixel Size = (0.050000000000000,-0.050000000000000)
Corner Coordinates:
Upper Left  (-180.0000000,  87.3700000) (180d 0' 0.00"W, 87d22'12.00"N)
Lower Left  (-180.0000000, -61.9800000) (180d 0' 0.00"W, 61d58'48.00"S)
Upper Right ( 180.0000000,  87.3700000) (180d 0' 0.00"E, 87d22'12.00"N)
Lower Right ( 180.0000000, -61.9800000) (180d 0' 0.00"E, 61d58'48.00"S)
Center      (   0.0000000,  12.6950000) (  0d 0' 0.00"E, 12d41'42.00"N)
Band 1 Block=7200x1 Type=Int16, ColorInterp=Gray
  NoData Value=-32768

and GRASS GIS

# create a new Location
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/

# projection info
g.proj -g

name=WGS 84
datum=wgs84
ellps=wgs84
proj=ll
no_defs=defined
epsg=4326
unit=degree
units=degrees
meters=1.0

# raster info
r.info -g OCDENS_M_sl1_5km_ll

north=87.37
south=-61.98
east=180
west=-180
nsres=0.05
ewres=0.05
rows=2987
cols=7200
cells=21506400
datatype=CELL
ncats=0

# report non-NULL cells and their x, y grid location
r.stats OCDENS_M_sl1_5km_ll -n -x > stats_x

Comparing a few single pixels via:

while read LINE;do
    set -- $LINE
    echo " ($1,$2)
    echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $1 $2)"
    echo "GRASS: $3"
    echo
done < stats_x_head

gives

 (2930,77)
GDAL:  2090
GRASS: 2096

 (2931,77)
GDAL:  2055
GRASS: 2090

 (2932,77)
GDAL:  2063
GRASS: 2055

 (2933,77)
GDAL:  2093
GRASS: 2063

 (2934,77)
GDAL:  2240
GRASS: 2093

 (2935,77)
GDAL:  2332
GRASS: 2240

 (2936,77)
GDAL:  2296
GRASS: 2332

 (2937,77)
GDAL:  2253
GRASS: 2296

 (2938,77)
GDAL:  2179
GRASS: 2253

 (2939,77)
GDAL:  2115
GRASS: 2179

Why these differences?

Nikos

# meta

GRASS 7.7.svn (2019)
libgis Revision: 74118
libgis Date: 2019-02-21 10:38:28 +0100 (Thu, 21 Feb 2019)

GDAL 2.3.1, released 2018/06/22

6

* Nikos Alexandris <nik@nikosalexandris.net> [2019-03-14 15:11:51 +0100]:

Following up, why are there differences between GDAL and GRASS GIS in
the following example?

This ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map, subject to `gdalinfo`:

gdalinfo OCDENS_M_sl1_5km_ll.tif -nogcp -nomd -norat -noct -nofl
Driver: GTiff/GeoTIFF
Files: OCDENS_M_sl1_5km_ll.tif
Size is 7200, 2987
Coordinate System is:
GEOGCS["WGS 84",
  DATUM["WGS_1984",
      SPHEROID["WGS 84",6378137,298.257223563,
          AUTHORITY["EPSG","7030"]],
      AUTHORITY["EPSG","6326"]],
  PRIMEM["Greenwich",0],
  UNIT["degree",0.0174532925199433],
  AUTHORITY["EPSG","4326"]]
Origin = (-180.000000000000000,87.370000000000005)
Pixel Size = (0.050000000000000,-0.050000000000000)
Corner Coordinates:
Upper Left  (-180.0000000,  87.3700000) (180d 0' 0.00"W, 87d22'12.00"N)
Lower Left  (-180.0000000, -61.9800000) (180d 0' 0.00"W, 61d58'48.00"S)
Upper Right ( 180.0000000,  87.3700000) (180d 0' 0.00"E, 87d22'12.00"N)
Lower Right ( 180.0000000, -61.9800000) (180d 0' 0.00"E, 61d58'48.00"S)
Center      (   0.0000000,  12.6950000) (  0d 0' 0.00"E, 12d41'42.00"N)
Band 1 Block=7200x1 Type=Int16, ColorInterp=Gray
NoData Value=-32768

and GRASS GIS

# create a new Location
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/

projection info

g.proj -g

name=WGS 84
datum=wgs84
ellps=wgs84
proj=ll
no_defs=defined
epsg=4326
unit=degree
units=degrees
meters=1.0

Something I did do, but forgot to copy-paste here:

g\.region raster=OCDENS\_M\_sl1\_5km\_ll \-g

projection=3
zone=0
n=87\.37
s=\-61\.98
w=\-180
e=180
nsres=0\.05
ewres=0\.05
rows=2987
cols=7200
cells=21506400
\`\`\`

Nikos

> \# raster info
> r\.info \-g OCDENS\_M\_sl1\_5km\_ll
>
> north=87\.37
> south=\-61\.98
> east=180
> west=\-180
> nsres=0\.05
> ewres=0\.05
> rows=2987
> cols=7200
> cells=21506400
> datatype=CELL
> ncats=0

\[rest deleted\]
7

On Thu, Mar 14, 2019 at 3:16 PM Nikos Alexandris <nik@nikosalexandris.net> wrote:

Following up, why are there differences between GDAL and GRASS GIS in
the following example?

This ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map, subject to gdalinfo:

gdalinfo OCDENS_M_sl1_5km_ll.tif -nogcp -nomd -norat -noct -nofl
Driver: GTiff/GeoTIFF
Files: OCDENS_M_sl1_5km_ll.tif
Size is 7200, 2987
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (-180.000000000000000,87.370000000000005)
Pixel Size = (0.050000000000000,-0.050000000000000)
Corner Coordinates:
Upper Left (-180.0000000, 87.3700000) (180d 0' 0.00"W, 87d22'12.00"N)
Lower Left (-180.0000000, -61.9800000) (180d 0' 0.00"W, 61d58'48.00"S)
Upper Right ( 180.0000000, 87.3700000) (180d 0' 0.00"E, 87d22'12.00"N)
Lower Right ( 180.0000000, -61.9800000) (180d 0' 0.00"E, 61d58'48.00"S)
Center ( 0.0000000, 12.6950000) ( 0d 0' 0.00"E, 12d41'42.00"N)
Band 1 Block=7200x1 Type=Int16, ColorInterp=Gray
NoData Value=-32768

and GRASS GIS

# create a new Location
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/

# projection info
g.proj -g

name=WGS 84
datum=wgs84
ellps=wgs84
proj=ll
no_defs=defined
epsg=4326
unit=degree
units=degrees
meters=1.0

# raster info
[r.info](http://r.info) -g OCDENS_M_sl1_5km_ll

north=87.37
south=-61.98
east=180
west=-180
nsres=0.05
ewres=0.05
rows=2987
cols=7200
cells=21506400
datatype=CELL
ncats=0

# report non-NULL cells and their x, y grid location
r.stats OCDENS_M_sl1_5km_ll -n -x > stats_x

Comparing a few single pixels via:

while read LINE;do
set -- $LINE
echo " ($1,$2)
echo "GDAL: $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $1 $2)"
echo "GRASS: $3"
echo
done < stats_x_head

gives

(2930,77)
GDAL: 2090
GRASS: 2096

(2931,77)
GDAL: 2055
GRASS: 2090

(2932,77)
GDAL: 2063
GRASS: 2055

(2933,77)
GDAL: 2093
GRASS: 2063

(2934,77)
GDAL: 2240
GRASS: 2093

(2935,77)
GDAL: 2332
GRASS: 2240

(2936,77)
GDAL: 2296
GRASS: 2332

(2937,77)
GDAL: 2253
GRASS: 2296

(2938,77)
GDAL: 2179
GRASS: 2253

(2939,77)
GDAL: 2115
GRASS: 2179

Why these differences?

With r.stats -x, indexing starts with 1 (first row is 1).
With gdallocationinfo, indexing starts with 0 (first row is 0).

Markus M

Nikos

meta

GRASS 7.7.svn (2019)
libgis Revision: 74118
libgis Date: 2019-02-21 10:38:28 +0100 (Thu, 21 Feb 2019)

GDAL 2.3.1, released 2018/06/22

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

8

* Markus Metz <markus.metz.giswork@gmail.com> [2019-03-14 17:07:49 +0100]:

On Thu, Mar 14, 2019 at 3:16 PM Nikos Alexandris <nik@nikosalexandris.net>
wrote:

Following up, why are there differences between GDAL and GRASS GIS in
the following example?

This ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map, subject to `gdalinfo`:

gdalinfo OCDENS_M_sl1_5km_ll.tif -nogcp -nomd -norat -noct -nofl
Driver: GTiff/GeoTIFF
Files: OCDENS_M_sl1_5km_ll.tif
Size is 7200, 2987
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-180.000000000000000,87.370000000000005)
Pixel Size = (0.050000000000000,-0.050000000000000)
Corner Coordinates:
Upper Left  (-180.0000000,  87.3700000) (180d 0' 0.00"W, 87d22'12.00"N)
Lower Left  (-180.0000000, -61.9800000) (180d 0' 0.00"W, 61d58'48.00"S)
Upper Right ( 180.0000000,  87.3700000) (180d 0' 0.00"E, 87d22'12.00"N)
Lower Right ( 180.0000000, -61.9800000) (180d 0' 0.00"E, 61d58'48.00"S)
Center      (   0.0000000,  12.6950000) (  0d 0' 0.00"E, 12d41'42.00"N)
Band 1 Block=7200x1 Type=Int16, ColorInterp=Gray
  NoData Value=-32768

and GRASS GIS

# create a new Location
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/

# projection info
g.proj -g

name=WGS 84
datum=wgs84
ellps=wgs84
proj=ll
no_defs=defined
epsg=4326
unit=degree
units=degrees
meters=1.0

# raster info
r.info -g OCDENS_M_sl1_5km_ll

north=87.37
south=-61.98
east=180
west=-180
nsres=0.05
ewres=0.05
rows=2987
cols=7200
cells=21506400
datatype=CELL
ncats=0

# report non-NULL cells and their x, y grid location
r.stats OCDENS_M_sl1_5km_ll -n -x > stats_x

Comparing a few single pixels via:

while read LINE;do
    set -- $LINE
    echo " ($1,$2)
    echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $1

$2)"

echo "GRASS: $3"
echo

done < stats_x_head


gives

(2930,77)
GDAL: 2090
GRASS: 2096

(2931,77)
GDAL: 2055
GRASS: 2090

(2932,77)
GDAL: 2063
GRASS: 2055

(2933,77)
GDAL: 2093
GRASS: 2063

(2934,77)
GDAL: 2240
GRASS: 2093

(2935,77)
GDAL: 2332
GRASS: 2240

(2936,77)
GDAL: 2296
GRASS: 2332

(2937,77)
GDAL: 2253
GRASS: 2296

(2938,77)
GDAL: 2179
GRASS: 2253

(2939,77)
GDAL: 2115
GRASS: 2179


Why these differences?

With r.stats -x, indexing starts with 1 (first row is 1).
With gdallocationinfo, indexing starts with 0 (first row is 0).

Updated:

while read LINE ;do
    set -- ${LINE}
    echo " ($1,$2)"
    echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $(echo $1 - 1 |bc) $(echo $2 - 1 |bc))"
    echo "GRASS: ${3}"
    echo
done < stats_x_head

which gives

 (2930,77)
GDAL:  2096
GRASS: 2096

 (2931,77)
GDAL:  2090
GRASS: 2090

 (2932,77)
GDAL:  2055
GRASS: 2055

 (2933,77)
GDAL:  2063
GRASS: 2063

 (2934,77)
GDAL:  2093
GRASS: 2093

 (2935,77)
GDAL:  2240
GRASS: 2240

 (2936,77)
GDAL:  2332
GRASS: 2332

 (2937,77)
GDAL:  2296
GRASS: 2296

 (2938,77)
GDAL:  2253
GRASS: 2253

 (2939,77)
GDAL:  2179
GRASS: 2179

Danke Markus!

Markus M

Nikos

# meta

GRASS 7.7.svn (2019)
libgis Revision: 74118
libgis Date: 2019-02-21 10:38:28 +0100 (Thu, 21 Feb 2019)

GDAL 2.3.1, released 2018/06/22
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3

9

Francois Chartier:

I am asking a question on the fundamentals not on a particular example on
how the value within a raster cell is determined when multiple vector data
points are located within a raster cell footprint.
I use RST mostly and sometimes IDW for vector data points.

Nikos Alexandris:

Then, from https://grass.osgeo.org/grass76/manuals/rasterintro.html:

"Raster input maps are automatically cropped/padded and rescaled (using
nearest-neighbour resampling) to match the current region."

[..]

Here a visual example using this
ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map in a GRASS GIS Location:

grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/
r.in.gdal input=OCDENS_M_sl1_5km_ll.tif output=OCDENS_M_sl1_5km_ll

Select a random point and grow over it a 10^2 box

center_n=37.176279; center_e=22.839542 ;offset=0.25
g.region -g \
  e=$(echo $center_e + $offset |bc) \
  w=$(echo $center_e - $offset |bc) \
  s=$(echo $center_n - $offset |bc) \
  n=$(echo $center_n + $offset |bc) \
  res=0.05

projection=3
zone=0
n=37.426279
s=36.926279
w=22.589542
e=23.089542
nsres=0.05
ewres=0.05
rows=10
cols=10
cells=100

Clean file receiving the rendering, then draw the map’s cell values

d.erase
d.rast.num OCDENS_M_sl1_5km_ll@PERMANENT text_color=red grid_color=gray

Here https://i.imgur.com/2L9dWgX.png red are the original values.

Upscale

g.region -g res=0.1

projection=3
zone=0
n=37.426279
s=36.926279
w=22.589542
e=23.089542
nsres=0.1
ewres=0.1
rows=5
cols=5
cells=25

And over-draw the "new" map

d.rast.num OCDENS_M_sl1_5km_ll@PERMANENT text_color=blue grid_color=blue

Here https://i.imgur.com/bYgH6io.png blue are the resampled values.

Nikos

10

Markus Metz:

With r.stats -x, indexing starts with 1 (first row is 1).
With gdallocationinfo, indexing starts with 0 (first row is 0).

I wonder if `-0` flag would make sense to be GDAL-compliant.
I created a Pull Request (in `grass-ci`) for a minor update in the manual.

Nikos

11

On Thu, Mar 14, 2019 at 11:31 PM Nikos Alexandris <nik@nikosalexandris.net> wrote:

Markus Metz:

With r.stats -x, indexing starts with 1 (first row is 1).
With gdallocationinfo, indexing starts with 0 (first row is 0).

I wonder if -0 flag would make sense to be GDAL-compliant.

Note that the internal variables row() and col() of r.mapcalc also use indices starting with 1. As long as the indexing is properly documented, I don’t see a problem. The r.stats manuals have been updated in trunk r74267 and relbr76 r74268. Maybe a PR for the documentation of gdallocationinfo is needed?

Markus M

I created a Pull Request (in grass-ci) for a minor update in the manual.

Nikos

12

* Markus Metz <markus.metz.giswork@gmail.com> [2019-03-15 22:16:17 +0100]:

On Thu, Mar 14, 2019 at 11:31 PM Nikos Alexandris <nik@nikosalexandris.net>
wrote:

Markus Metz:

>>With r.stats -x, indexing starts with 1 (first row is 1).
>>With gdallocationinfo, indexing starts with 0 (first row is 0).

I wonder if `-0` flag would make sense to be GDAL-compliant.

Note that the internal variables row() and col() of r.mapcalc also use
indices starting with 1. As long as the indexing is properly documented, I
don't see a problem. The r.stats manuals have been updated in trunk r74267
and relbr76 r74268. Maybe a PR for the documentation of gdallocationinfo is
needed?

I did search already the GDAL documentation, and the manual for
`gdallocationinfo`. On and off, the "C-style indexing starts at 0" is
mentioned here and there. A clear entry on this in `gdallocationinfo`'s
manual will be purposive.

Nikos

13

* Nikos Alexandris <nik@nikosalexandris.net> [2019-03-14 17:57:16 +0100]:

* Markus Metz <markus.metz.giswork@gmail.com> [2019-03-14 17:07:49 +0100]:

On Thu, Mar 14, 2019 at 3:16 PM Nikos Alexandris <nik@nikosalexandris.net>
wrote:

Following up, why are there differences between GDAL and GRASS GIS in
the following example?

This ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map, subject to `gdalinfo`:

gdalinfo OCDENS_M_sl1_5km_ll.tif -nogcp -nomd -norat -noct -nofl
Driver: GTiff/GeoTIFF
Files: OCDENS_M_sl1_5km_ll.tif
Size is 7200, 2987
Coordinate System is:
GEOGCS["WGS 84",
   DATUM["WGS_1984",
       SPHEROID["WGS 84",6378137,298.257223563,
           AUTHORITY["EPSG","7030"]],
       AUTHORITY["EPSG","6326"]],
   PRIMEM["Greenwich",0],
   UNIT["degree",0.0174532925199433],
   AUTHORITY["EPSG","4326"]]
Origin = (-180.000000000000000,87.370000000000005)
Pixel Size = (0.050000000000000,-0.050000000000000)
Corner Coordinates:
Upper Left  (-180.0000000,  87.3700000) (180d 0' 0.00"W, 87d22'12.00"N)
Lower Left  (-180.0000000, -61.9800000) (180d 0' 0.00"W, 61d58'48.00"S)
Upper Right ( 180.0000000,  87.3700000) (180d 0' 0.00"E, 87d22'12.00"N)
Lower Right ( 180.0000000, -61.9800000) (180d 0' 0.00"E, 61d58'48.00"S)
Center      (   0.0000000,  12.6950000) (  0d 0' 0.00"E, 12d41'42.00"N)
Band 1 Block=7200x1 Type=Int16, ColorInterp=Gray
 NoData Value=-32768

and GRASS GIS

# create a new Location
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/

# projection info
g.proj -g

name=WGS 84
datum=wgs84
ellps=wgs84
proj=ll
no_defs=defined
epsg=4326
unit=degree
units=degrees
meters=1.0

# raster info
r.info -g OCDENS_M_sl1_5km_ll

north=87.37
south=-61.98
east=180
west=-180
nsres=0.05
ewres=0.05
rows=2987
cols=7200
cells=21506400
datatype=CELL
ncats=0

# report non-NULL cells and their x, y grid location
r.stats OCDENS_M_sl1_5km_ll -n -x > stats_x

Comparing a few single pixels via:

while read LINE;do
   set -- $LINE
   echo " ($1,$2)
   echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $1

$2)"

echo “GRASS: $3”
echo
done < stats_x_head


gives

(2930,77)
GDAL: 2090
GRASS: 2096

(2931,77)
GDAL: 2055
GRASS: 2090

(2932,77)
GDAL: 2063
GRASS: 2055

(2933,77)
GDAL: 2093
GRASS: 2063

(2934,77)
GDAL: 2240
GRASS: 2093

(2935,77)
GDAL: 2332
GRASS: 2240

(2936,77)
GDAL: 2296
GRASS: 2332

(2937,77)
GDAL: 2253
GRASS: 2296

(2938,77)
GDAL: 2179
GRASS: 2253

(2939,77)
GDAL: 2115
GRASS: 2179


Why these differences?

With r.stats -x, indexing starts with 1 (first row is 1).
With gdallocationinfo, indexing starts with 0 (first row is 0).

Updated:

while read LINE ;do
  set -- ${LINE}
  echo " ($1,$2)"
  echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $(echo $1 - 1 |bc) $(echo $2 - 1 |bc))"
  echo "GRASS: ${3}"
  echo
done < stats_x_head

For the sake of clarity, since the file `stats_x_head` is a GRASS GIS
output, where indexing starts from 1:

while read LINE ;do
    set -- ${LINE}
    ROW=$(echo $1 -1 |bc)
    COLUMN=$(echo $2 - 1 |bc)
    echo "GDAL  ($ROW, $COLUMN): $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $ROW $COLUMN)"
    echo "GRASS ($1, $2): ${3}"
    echo
done < stats_x_head

will return


GDAL  (2929, 76): 2096
GRASS (2930, 77): 2096

GDAL  (2930, 76): 2090
GRASS (2931, 77): 2090

GDAL  (2931, 76): 2055
GRASS (2932, 77): 2055

GDAL  (2932, 76): 2063
GRASS (2933, 77): 2063

GDAL  (2933, 76): 2093
GRASS (2934, 77): 2093

GDAL  (2934, 76): 2240
GRASS (2935, 77): 2240

GDAL  (2935, 76): 2332
GRASS (2936, 77): 2332

GDAL  (2936, 76): 2296
GRASS (2937, 77): 2296

GDAL  (2937, 76): 2253
GRASS (2938, 77): 2253

GDAL  (2938, 76): 2179
GRASS (2939, 77): 2179

Nikos