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

The hourly 5km LST product from Copernicus, as per the product user manual
(https://land.copernicus.eu/global/sites/cgls.vito.be/files/products/GIOGL1_PUM_LST-I1.40.pdf)

"is displayed in a regular latitude/longitude grid (plate carrée) with
the ellipsoid WGS 1984 (Terrestrial radius=6378km). This coordinate
reference system corresponds to EPSG code 32663. The resolution of the
grid is 5/112° (approximately 0.045°)."

I imported a map (netCDF) and set the region to match it. If '32633' unit is 'meter', any ideas on to do with the reported:

nsres: 0.04464286
ewres: 0.04464286

which is, obviously, not meters?
Is there something "hidden" in the netCDF file(s)?

Here is a `gdalinfo g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc`:

Driver: netCDF/Network Common Data Format
Files: g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc
Size is 512, 512
Coordinate System is `'
Metadata:
  NC_GLOBAL#algorithm_version=GOES13-LST_v3.40, MSG3-LST_v7.14.0, HIMAWARI8-LST_v3.50, DataFusion_v5.2
  NC_GLOBAL#archive_facility=IPMA
  NC_GLOBAL#comment=Land Surface Temperature (LST) is the radiative skin temperature over land. LST plays
an important role in the physics of land surface as it is involved in the processes of energy and water ex
change with the atmosphere. LST is useful for the scientific community, namely for those dealing with mete
orological and climate models. Accurate values of LST are also of special interest in a wide range of area
s related to land surface processes, including meteorology, hydrology, agrometeorology, climatology and en
vironmental studies.
  NC_GLOBAL#contacts=Principal investigator (Researcher): isabel.trigo@ipma.pt; Instituto Português do Mar
 e da Atmosfera (IPMA); Rua C ao Aeroporto; Lisbon; 1749-077; Portugal (PT); IPMA website; http://www.ipma
.pt
Originator (IPMA GIO-Global Land Help Desk): sandra.coelho@ipma.pt; Instituto Português do Mar e da Atmosf
era (IPMA); Rua C ao Aeroporto; Lisbon; 1749-077; Portugal (PT); IPMA website; http://www.ipma.pt
Point of contact (GIO-Global Land Help Desk): helpdesk@vgt.vito.be; Flemish Institute for Technological Research (VITO); Boeretang 200; Mol; 2400; Belgium (BE); VITO website; http://land.copernicus.eu/global/
Owner: ENTR-COPERNICUS-ASSETS@ec.europa.eu; European Commission Directorate-General for Enterprise and Industry (EC-DGEI); Avenue d'Auderghem 45; Brussels; 1049; Belgium (BE); EC-DGEI website; http://ec.europa.eu/enterprise/
Custodian (Responsible): copernicuslandproducts@jrc.ec.europa.eu; European Commission Directorate-General Joint Research Center (JRC); Via E.Fermi, 249; Ispra; 21027; Italy (IT); JRC website; http://ies.jrc.ec.europa.eu
  NC_GLOBAL#Conventions=CF-1.6
  NC_GLOBAL#credit=LST products are generated by the land service of Copernicus, the Earth Observation programme of the European Commission. The LST algorithm, originally developed in the framework of the FP7/Geoland2, is generated from MTSAT/HIMAWARI and GOES data, respectively owned by JMA and NOAA, and combined with the LST product from MSG under copyright EUMETSAT, produced by LSA-SAF.
  NC_GLOBAL#date_created=2016-06-22T03:22:01Z
  NC_GLOBAL#gcmd_keywords=SURFACE TEMPERATURE
  NC_GLOBAL#gemet_keywords=solar radiation
  NC_GLOBAL#history=2016-06-22T03:22:01Z - Product generation;
  NC_GLOBAL#identifier=urn:cgls:global:lst_v1_0.045degree:LST_201606220100_GLOBE_GEO_V1.2
  NC_GLOBAL#inspire_theme=Orthoimagery
  NC_GLOBAL#institution=IPMA
  NC_GLOBAL#iso19115_topic_categories=climatologyMeteorologyAtmosphere, imageryBaseMapsEarthCover
  NC_GLOBAL#long_name=Land Surface Temperature
  NC_GLOBAL#name=LST
  NC_GLOBAL#orbit_type=GEO
  NC_GLOBAL#other_keywords=Global
  NC_GLOBAL#parent_identifier=urn:cgls:global:lst_v1_0.045degree
  NC_GLOBAL#platform=GOES13, MSG3, HIMAWARI8
  NC_GLOBAL#processing_level=L4
  NC_GLOBAL#processing_mode=Near Real Time
  NC_GLOBAL#product_version=V1.2
  NC_GLOBAL#purpose=This product is first designed to fit the requirements of the Global Land component of Land Service of GMES-Copernicus. It can be also useful for all applications related to the environment monitoring.
  NC_GLOBAL#references=Product User Manual: http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_PUM_LST_I1.10.pdf
Validation Report: http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_VR_LST_I2.10.pdf
Product page: http://land.copernicus.eu/global/products/lst
  NC_GLOBAL#sensor=IMAG, SEVI, AHI
  NC_GLOBAL#source=Data was derived from satellite imagery.
  NC_GLOBAL#time_coverage_end=2016-06-22T01:30:00Z
  NC_GLOBAL#time_coverage_start=2016-06-22T00:30:00Z
  NC_GLOBAL#title=Global Land Surface Temperature for 2016-06-22T01:00:00Z
Subdatasets:
  SUBDATASET_1_NAME=NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":ERRORBAR_LST
  SUBDATASET_1_DESC=[1x3584x8064] surface_temperature standard_error (16-bit integer)
  SUBDATASET_2_NAME=NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":LST
  SUBDATASET_2_DESC=[1x3584x8064] surface_temperature (16-bit integer)
  SUBDATASET_3_NAME=NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":PERCENT_PROC_PIXELS
  SUBDATASET_3_DESC=[1x3584x8064] PERCENT_PROC_PIXELS (16-bit integer)
  SUBDATASET_4_NAME=NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":Q_FLAGS
  SUBDATASET_4_DESC=[1x3584x8064] Q_FLAGS (16-bit integer)
  SUBDATASET_5_NAME=NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":TIME_DELTA
  SUBDATASET_5_DESC=[1x3584x8064] TIME_DELTA (16-bit integer)
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0,  512.0)
Upper Right (  512.0,    0.0)
Lower Right (  512.0,  512.0)
Center      (  256.0,  256.0)

Nikos

AFAIU, plate carree (lat long grid, no meters) is deprecated, and you should use latlong instead. I had a similar issue with modis ocean color products.

Do you at least get the same number of row and columns that is described by gdalinfo when you import?

HTH,
Vero

El mar., 25 sep. 2018 7:25, Nikos Alexandris <nik@nikosalexandris.net> escribió:

The hourly 5km LST product from Copernicus, as per the product user manual
(https://land.copernicus.eu/global/sites/cgls.vito.be/files/products/GIOGL1_PUM_LST-I1.40.pdf)

“is displayed in a regular latitude/longitude grid (plate carrée) with
the ellipsoid WGS 1984 (Terrestrial radius=6378km). This coordinate
reference system corresponds to EPSG code 32663. The resolution of the
grid is 5/112° (approximately 0.045°).”

I imported a map (netCDF) and set the region to match it.
If ‘32633’ unit is ‘meter’, any ideas on to do with the reported:

nsres: 0.04464286
ewres: 0.04464286

which is, obviously, not meters?
Is there something “hidden” in the netCDF file(s)?

Here is a gdalinfo [g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc):

Driver: netCDF/Network Common Data Format
Files: [g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc)
Size is 512, 512
Coordinate System is `'
Metadata:
NC_GLOBAL#algorithm_version=GOES13-LST_v3.40, MSG3-LST_v7.14.0, HIMAWARI8-LST_v3.50, DataFusion_v5.2
NC_GLOBAL#archive_facility=IPMA
NC_GLOBAL#comment=Land Surface Temperature (LST) is the radiative skin temperature over land. LST plays
an important role in the physics of land surface as it is involved in the processes of energy and water ex
change with the atmosphere. LST is useful for the scientific community, namely for those dealing with mete
orological and climate models. Accurate values of LST are also of special interest in a wide range of area
s related to land surface processes, including meteorology, hydrology, agrometeorology, climatology and en
vironmental studies.
NC_GLOBAL#contacts=Principal investigator (Researcher): [isabel.trigo@ipma.pt](mailto:isabel.trigo@ipma.pt); Instituto Português do Mar
e da Atmosfera (IPMA); Rua C ao Aeroporto; Lisbon; 1749-077; Portugal (PT); IPMA website; [http://www.ipma](http://www.ipma)
.pt
Originator (IPMA GIO-Global Land Help Desk): [sandra.coelho@ipma.pt](mailto:sandra.coelho@ipma.pt); Instituto Português do Mar e da Atmosf
era (IPMA); Rua C ao Aeroporto; Lisbon; 1749-077; Portugal (PT); IPMA website; [http://www.ipma.pt](http://www.ipma.pt)
Point of contact (GIO-Global Land Help Desk): [helpdesk@vgt.vito.be](mailto:helpdesk@vgt.vito.be); Flemish Institute for Technological Research (VITO); Boeretang 200; Mol; 2400; Belgium (BE); VITO website; [http://land.copernicus.eu/global/](http://land.copernicus.eu/global/)
Owner: [ENTR-COPERNICUS-ASSETS@ec.europa.eu](mailto:ENTR-COPERNICUS-ASSETS@ec.europa.eu); European Commission Directorate-General for Enterprise and Industry (EC-DGEI); Avenue d'Auderghem 45; Brussels; 1049; Belgium (BE); EC-DGEI website; [http://ec.europa.eu/enterprise/](http://ec.europa.eu/enterprise/)
Custodian (Responsible): [copernicuslandproducts@jrc.ec.europa.eu](mailto:copernicuslandproducts@jrc.ec.europa.eu); European Commission Directorate-General Joint Research Center (JRC); Via E.Fermi, 249; Ispra; 21027; Italy (IT); JRC website; [http://ies.jrc.ec.europa.eu](http://ies.jrc.ec.europa.eu)
NC_GLOBAL#Conventions=CF-1.6
NC_GLOBAL#credit=LST products are generated by the land service of Copernicus, the Earth Observation programme of the European Commission. The LST algorithm, originally developed in the framework of the FP7/Geoland2, is generated from MTSAT/HIMAWARI and GOES data, respectively owned by JMA and NOAA, and combined with the LST product from MSG under copyright EUMETSAT, produced by LSA-SAF.
NC_GLOBAL#date_created=2016-06-22T03:22:01Z
NC_GLOBAL#gcmd_keywords=SURFACE TEMPERATURE
NC_GLOBAL#gemet_keywords=solar radiation
NC_GLOBAL#history=2016-06-22T03:22:01Z - Product generation;
NC_GLOBAL#identifier=urn:cgls:global:lst_v1_0.045degree:LST_201606220100_GLOBE_GEO_V1.2
NC_GLOBAL#inspire_theme=Orthoimagery
NC_GLOBAL#institution=IPMA
NC_GLOBAL#iso19115_topic_categories=climatologyMeteorologyAtmosphere, imageryBaseMapsEarthCover
NC_GLOBAL#long_name=Land Surface Temperature
NC_GLOBAL#name=LST
NC_GLOBAL#orbit_type=GEO
NC_GLOBAL#other_keywords=Global
NC_GLOBAL#parent_identifier=urn:cgls:global:lst_v1_0.045degree
NC_GLOBAL#platform=GOES13, MSG3, HIMAWARI8
NC_GLOBAL#processing_level=L4
NC_GLOBAL#processing_mode=Near Real Time
NC_GLOBAL#product_version=V1.2
NC_GLOBAL#purpose=This product is first designed to fit the requirements of the Global Land component of Land Service of GMES-Copernicus. It can be also useful for all applications related to the environment monitoring.
NC_GLOBAL#references=Product User Manual: [http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_PUM_LST_I1.10.pdf](http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_PUM_LST_I1.10.pdf)
Validation Report: [http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_VR_LST_I2.10.pdf](http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_VR_LST_I2.10.pdf)
Product page: [http://land.copernicus.eu/global/products/lst](http://land.copernicus.eu/global/products/lst)
NC_GLOBAL#sensor=IMAG, SEVI, AHI
NC_GLOBAL#source=Data was derived from satellite imagery.
NC_GLOBAL#time_coverage_end=2016-06-22T01:30:00Z
NC_GLOBAL#time_coverage_start=2016-06-22T00:30:00Z
NC_GLOBAL#title=Global Land Surface Temperature for 2016-06-22T01:00:00Z
Subdatasets:
SUBDATASET_1_NAME=NETCDF:"[g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc)":ERRORBAR_LST
SUBDATASET_1_DESC=[1x3584x8064] surface_temperature standard_error (16-bit integer)
SUBDATASET_2_NAME=NETCDF:"[g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc)":LST
SUBDATASET_2_DESC=[1x3584x8064] surface_temperature (16-bit integer)
SUBDATASET_3_NAME=NETCDF:"[g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc)":PERCENT_PROC_PIXELS
SUBDATASET_3_DESC=[1x3584x8064] PERCENT_PROC_PIXELS (16-bit integer)
SUBDATASET_4_NAME=NETCDF:"[g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc)":Q_FLAGS
SUBDATASET_4_DESC=[1x3584x8064] Q_FLAGS (16-bit integer)
SUBDATASET_5_NAME=NETCDF:"[g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc)":TIME_DELTA
SUBDATASET_5_DESC=[1x3584x8064] TIME_DELTA (16-bit integer)
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 512.0)
Upper Right ( 512.0, 0.0)
Lower Right ( 512.0, 512.0)
Center ( 256.0, 256.0)

Nikos


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

On Tue, Sep 25, 2018 at 1:25 PM Veronica Andreo <veroandreo@gmail.com> wrote:

AFAIU, plate carree (lat long grid, no meters) is deprecated, and you should use latlong instead. I had a similar issue with modis ocean color products.

Do you at least get the same number of row and columns that is described by gdalinfo when you import?

… by gdalinfo on one of the subdatasets, not on the netcdf file directly, e.g.

gdalinfo NETCDF:“g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc”:LST

note that the resolution you get (0.04464286) is close to what is reported in the metadata:

NC_GLOBAL#parent_identifier=urn:cgls:global:lst_v1_0.045degree

assuming units are degrees.

Markus M

HTH,
Vero

El mar., 25 sep. 2018 7:25, Nikos Alexandris <nik@nikosalexandris.net> escribió:

The hourly 5km LST product from Copernicus, as per the product user manual
(https://land.copernicus.eu/global/sites/cgls.vito.be/files/products/GIOGL1_PUM_LST-I1.40.pdf)

“is displayed in a regular latitude/longitude grid (plate carrée) with
the ellipsoid WGS 1984 (Terrestrial radius=6378km). This coordinate
reference system corresponds to EPSG code 32663. The resolution of the
grid is 5/112° (approximately 0.045°).”

I imported a map (netCDF) and set the region to match it.
If ‘32633’ unit is ‘meter’, any ideas on to do with the reported:

nsres: 0.04464286
ewres: 0.04464286

which is, obviously, not meters?
Is there something “hidden” in the netCDF file(s)?

Here is a gdalinfo [g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc):

Driver: netCDF/Network Common Data Format
Files: [g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc)
Size is 512, 512
Coordinate System is `'
Metadata:
NC_GLOBAL#algorithm_version=GOES13-LST_v3.40, MSG3-LST_v7.14.0, HIMAWARI8-LST_v3.50, DataFusion_v5.2
NC_GLOBAL#archive_facility=IPMA
NC_GLOBAL#comment=Land Surface Temperature (LST) is the radiative skin temperature over land. LST plays
an important role in the physics of land surface as it is involved in the processes of energy and water ex
change with the atmosphere. LST is useful for the scientific community, namely for those dealing with mete
orological and climate models. Accurate values of LST are also of special interest in a wide range of area
s related to land surface processes, including meteorology, hydrology, agrometeorology, climatology and en
vironmental studies.
NC_GLOBAL#contacts=Principal investigator (Researcher): [isabel.trigo@ipma.pt](mailto:isabel.trigo@ipma.pt); Instituto Português do Mar
e da Atmosfera (IPMA); Rua C ao Aeroporto; Lisbon; 1749-077; Portugal (PT); IPMA website; [http://www.ipma](http://www.ipma)
.pt
Originator (IPMA GIO-Global Land Help Desk): [sandra.coelho@ipma.pt](mailto:sandra.coelho@ipma.pt); Instituto Português do Mar e da Atmosf
era (IPMA); Rua C ao Aeroporto; Lisbon; 1749-077; Portugal (PT); IPMA website; [http://www.ipma.pt](http://www.ipma.pt)
Point of contact (GIO-Global Land Help Desk): [helpdesk@vgt.vito.be](mailto:helpdesk@vgt.vito.be); Flemish Institute for Technological Research (VITO); Boeretang 200; Mol; 2400; Belgium (BE); VITO website; [http://land.copernicus.eu/global/](http://land.copernicus.eu/global/)
Owner: [ENTR-COPERNICUS-ASSETS@ec.europa.eu](mailto:ENTR-COPERNICUS-ASSETS@ec.europa.eu); European Commission Directorate-General for Enterprise and Industry (EC-DGEI); Avenue d'Auderghem 45; Brussels; 1049; Belgium (BE); EC-DGEI website; [http://ec.europa.eu/enterprise/](http://ec.europa.eu/enterprise/)
Custodian (Responsible): [copernicuslandproducts@jrc.ec.europa.eu](mailto:copernicuslandproducts@jrc.ec.europa.eu); European Commission Directorate-General Joint Research Center (JRC); Via E.Fermi, 249; Ispra; 21027; Italy (IT); JRC website; [http://ies.jrc.ec.europa.eu](http://ies.jrc.ec.europa.eu)
NC_GLOBAL#Conventions=CF-1.6
NC_GLOBAL#credit=LST products are generated by the land service of Copernicus, the Earth Observation programme of the European Commission. The LST algorithm, originally developed in the framework of the FP7/Geoland2, is generated from MTSAT/HIMAWARI and GOES data, respectively owned by JMA and NOAA, and combined with the LST product from MSG under copyright EUMETSAT, produced by LSA-SAF.
NC_GLOBAL#date_created=2016-06-22T03:22:01Z
NC_GLOBAL#gcmd_keywords=SURFACE TEMPERATURE
NC_GLOBAL#gemet_keywords=solar radiation
NC_GLOBAL#history=2016-06-22T03:22:01Z - Product generation;
NC_GLOBAL#identifier=urn:cgls:global:lst_v1_0.045degree:LST_201606220100_GLOBE_GEO_V1.2
NC_GLOBAL#inspire_theme=Orthoimagery
NC_GLOBAL#institution=IPMA
NC_GLOBAL#iso19115_topic_categories=climatologyMeteorologyAtmosphere, imageryBaseMapsEarthCover
NC_GLOBAL#long_name=Land Surface Temperature
NC_GLOBAL#name=LST
NC_GLOBAL#orbit_type=GEO
NC_GLOBAL#other_keywords=Global
NC_GLOBAL#parent_identifier=urn:cgls:global:lst_v1_0.045degree
NC_GLOBAL#platform=GOES13, MSG3, HIMAWARI8
NC_GLOBAL#processing_level=L4
NC_GLOBAL#processing_mode=Near Real Time
NC_GLOBAL#product_version=V1.2
NC_GLOBAL#purpose=This product is first designed to fit the requirements of the Global Land component of Land Service of GMES-Copernicus. It can be also useful for all applications related to the environment monitoring.
NC_GLOBAL#references=Product User Manual: [http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_PUM_LST_I1.10.pdf](http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_PUM_LST_I1.10.pdf)
Validation Report: [http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_VR_LST_I2.10.pdf](http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_VR_LST_I2.10.pdf)
Product page: [http://land.copernicus.eu/global/products/lst](http://land.copernicus.eu/global/products/lst)
NC_GLOBAL#sensor=IMAG, SEVI, AHI
NC_GLOBAL#source=Data was derived from satellite imagery.
NC_GLOBAL#time_coverage_end=2016-06-22T01:30:00Z
NC_GLOBAL#time_coverage_start=2016-06-22T00:30:00Z
NC_GLOBAL#title=Global Land Surface Temperature for 2016-06-22T01:00:00Z
Subdatasets:
SUBDATASET_1_NAME=NETCDF:"[g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc)":ERRORBAR_LST
SUBDATASET_1_DESC=[1x3584x8064] surface_temperature standard_error (16-bit integer)
SUBDATASET_2_NAME=NETCDF:"[g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc)":LST
SUBDATASET_2_DESC=[1x3584x8064] surface_temperature (16-bit integer)
SUBDATASET_3_NAME=NETCDF:"[g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc)":PERCENT_PROC_PIXELS
SUBDATASET_3_DESC=[1x3584x8064] PERCENT_PROC_PIXELS (16-bit integer)
SUBDATASET_4_NAME=NETCDF:"[g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc)":Q_FLAGS
SUBDATASET_4_DESC=[1x3584x8064] Q_FLAGS (16-bit integer)
SUBDATASET_5_NAME=NETCDF:"[g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc](http://g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc)":TIME_DELTA
SUBDATASET_5_DESC=[1x3584x8064] TIME_DELTA (16-bit integer)
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 512.0)
Upper Right ( 512.0, 0.0)
Lower Right ( 512.0, 512.0)
Center ( 256.0, 256.0)

Nikos


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


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

* Veronica Andreo <veroandreo@gmail.com> [2018-09-25 08:24:44 -0300]:

AFAIU, plate carree (lat long grid, no meters) is deprecated, and you
should use latlong instead. I had a similar issue with modis ocean color
products.

Do you at least get the same number of row and columns that is described by
gdalinfo when you import?

No, it is 512^2 (see below) against

g.regio -p
..
rows:       3584
cols:       8064
..

Markus' hint, not *directly* on the netCDF file, rather on one of the
layers:

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)
Metadata:
  crs#grid_mapping_name=latitude_longitude
  crs#inverse_flattening=298.2572326660156
  crs#longitude_of_prime_meridian=0
  crs#semi_major_axis=6378137
  lat#axis=Y
  lat#long_name=latitude
  lat#standard_name=latitude
  lat#units=degrees_north
  lon#axis=X
  lon#long_name=longitude
  lon#standard_name=longitude
  lon#units=degrees_east
  LST#add_offset=273.15
  LST#ancillary_variables=Q_FLAGS, ERRORBAR_LST, TIME_DELTA, PERCENT_PROC_PIXELS
  LST#cell_methods=area:mean where land
  LST#coverage_content_type=physicalMeasurement
  LST#grid_mapping=crs
  LST#long_name=Land Surface Temperature
  LST#scale_factor=0.01
  LST#standard_name=surface_temperature
  LST#units=Kelvin
  LST#valid_range={-7000,8000}
  LST#_FillValue=-8000
  NC_GLOBAL#algorithm_version=GOES13-LST_v3.40, MSG3-LST_v7.14.0, HIMAWARI8-LST_v3.50, DataFusion_v5.2
  NC_GLOBAL#archive_facility=IPMA
  NC_GLOBAL#comment=Land Surface Temperature (LST) is the radiative skin temperature over land. LST plays an important role in the physics of land surface as it is involved in the processes of energy and water exc
hange with the atmosphere. LST is useful for the scientific community, namely for those dealing with meteorological and climate models. Accurate values of LST are also of special interest in a wide range of areas
related to land surface processes, including meteorology, hydrology, agrometeorology, climatology and environmental studies.
  NC_GLOBAL#contacts=Principal investigator (Researcher): isabel.trigo@ipma.pt; Instituto Português do Mar e da Atmosfera (IPMA); Rua C ao Aeroporto; Lisbon; 1749-077; Portugal (PT); IPMA website; http://www.ipma.
pt
Originator (IPMA GIO-Global Land Help Desk): sandra.coelho@ipma.pt; Instituto Português do Mar e da Atmosfera (IPMA); Rua C ao Aeroporto; Lisbon; 1749-077; Portugal (PT); IPMA website; http://www.ipma.pt
Point of contact (GIO-Global Land Help Desk): helpdesk@vgt.vito.be; Flemish Institute for Technological Research (VITO); Boeretang 200; Mol; 2400; Belgium (BE); VITO website; http://land.copernicus.eu/global/
Owner: ENTR-COPERNICUS-ASSETS@ec.europa.eu; European Commission Directorate-General for Enterprise and Industry (EC-DGEI); Avenue d'Auderghem 45; Brussels; 1049; Belgium (BE); EC-DGEI website; http://ec.europa.eu/
enterprise/
Custodian (Responsible): copernicuslandproducts@jrc.ec.europa.eu; European Commission Directorate-General Joint Research Center (JRC); Via E.Fermi, 249; Ispra; 21027; Italy (IT); JRC website; http://ies.jrc.ec.eur
opa.eu
  NC_GLOBAL#Conventions=CF-1.6
  NC_GLOBAL#credit=LST products are generated by the land service of Copernicus, the Earth Observation programme of the European Commission. The LST algorithm, originally developed in the framework of the FP7/Geoland2, is generated from MTSAT/HIMAWARI and GOES data, respectively owned by JMA and NOAA, and combined with the LST product from MSG under copyright EUMETSAT, produced by LSA-SAF.
  NC_GLOBAL#date_created=2016-06-22T03:22:01Z
  NC_GLOBAL#gcmd_keywords=SURFACE TEMPERATURE
  NC_GLOBAL#gemet_keywords=solar radiation
  NC_GLOBAL#history=2016-06-22T03:22:01Z - Product generation;
  NC_GLOBAL#identifier=urn:cgls:global:lst_v1_0.045degree:LST_201606220100_GLOBE_GEO_V1.2
  NC_GLOBAL#inspire_theme=Orthoimagery
  NC_GLOBAL#institution=IPMA
  NC_GLOBAL#iso19115_topic_categories=climatologyMeteorologyAtmosphere, imageryBaseMapsEarthCover
  NC_GLOBAL#long_name=Land Surface Temperature
  NC_GLOBAL#name=LST
  NC_GLOBAL#orbit_type=GEO
  NC_GLOBAL#other_keywords=Global
  NC_GLOBAL#parent_identifier=urn:cgls:global:lst_v1_0.045degree
  NC_GLOBAL#platform=GOES13, MSG3, HIMAWARI8
  NC_GLOBAL#processing_level=L4
  NC_GLOBAL#processing_mode=Near Real Time
  NC_GLOBAL#product_version=V1.2
  NC_GLOBAL#purpose=This product is first designed to fit the requirements of the Global Land component of Land Service of GMES-Copernicus. It can be also useful for all applications related to the environment monitoring.
  NC_GLOBAL#references=Product User Manual: http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_PUM_LST_I1.10.pdf
Validation Report: http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_VR_LST_I2.10.pdf
Product page: http://land.copernicus.eu/global/products/lst
  NC_GLOBAL#sensor=IMAG, SEVI, AHI
  NC_GLOBAL#source=Data was derived from satellite imagery.
  NC_GLOBAL#time_coverage_end=2016-06-22T01:30:00Z
  NC_GLOBAL#time_coverage_start=2016-06-22T00:30:00Z
  NC_GLOBAL#title=Global Land Surface Temperature for 2016-06-22T01:00:00Z
  NETCDF_DIM_EXTRA={time}
  NETCDF_DIM_time_DEF={1,6}
  NETCDF_DIM_time_VALUES=0
  time#axis=T
  time#long_name=time
  time#units=days since 2016-06-22 01:00:00
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)
Band 1 Block=200x200 Type=Int16, ColorInterp=Undefined
  NoData Value=-8000
  Unit Type: Kelvin
  Offset: 273.15, Scale:0.01
  Metadata:
    add_offset=273.15
    ancillary_variables=Q_FLAGS, ERRORBAR_LST, TIME_DELTA, PERCENT_PROC_PIXELS
    cell_methods=area:mean where land
    coverage_content_type=physicalMeasurement
    grid_mapping=crs
    long_name=Land Surface Temperature
    NETCDF_DIM_time=0
    NETCDF_VARNAME=LST
    scale_factor=0.01
    standard_name=surface_temperature
    units=Kelvin
    valid_range={-7000,8000}
    _FillValue=-8000

So, the important bits are:

gdalinfo NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":LST |grep Pixel

Pixel Size = (0.044642858207226,-0.044642858207226)

and

gdalinfo NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":LST |grep Coordinates -A5

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)

A fresh Location:

grass -c 'epsg:4326' /geo/grassdb/lst/wgs84

and

g.region -p

projection: 3 (Latitude-Longitude)
zone:       0
datum:      wgs84
ellipsoid:  wgs84
north:      1N
south:      0
west:       0
east:       1E
nsres:      1
ewres:      1
rows:       1
cols:       1
cells:      1

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?

r.in.gdal in=NETCDF:"g2_BIOPAR_LST_201606220300_GLOBE_GEO_V1.2.nc":LST output=g2_BIOPAR_LST_201606220300_GLOBE_GEO_V1.2.nc_LST -o

WARNING: Datum <unknown> not recognised by GRASS and no parameters found
Over-riding projection check
360 degree EW extent is exceeded by 0.000192261 cells
Importing raster map <g2_BIOPAR_LST_201606220300_GLOBE_GEO_V1.2.nc_LST>...
 100%

Here,

r.info g2_BIOPAR_LST_201606220300_GLOBE_GEO_V1.2.nc_LST -g

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

Then, setting the region:

g.region raster=g2_BIOPAR_LST_201606220300_GLOBE_GEO_V1.2.nc_LST -pg
360 degree EW extent is exceeded by 0.00019226 cells
projection=3
zone=0
n=80.0223214291667
s=-79.9776823855556
w=-180.022321429167
e=179.977687153889
nsres=0.0446428582072328
ewres=0.0446428582072241
rows=3584
cols=8064
cells=28901376

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

360 degree EW extent is exceeded by 0.00019226 cells
projection=3
zone=0
n=80.0223214291667
s=-79.9776823855556
w=-180
e=180
nsres=0.0446428582072328
ewres=0.0446428571428571
rows=3584
cols=8064
cells=28901376

How does this look like? We had this questions not along ago.

Nikos

On Tue, Sep 25, 2018 at 4:51 PM Nikos Alexandris <nik@nikosalexandris.net> wrote:

AFAIU, plate carree (lat long grid, no meters) is deprecated, and you
should use latlong instead. I had a similar issue with modis ocean color
products.

Do you at least get the same number of row and columns that is described by
gdalinfo when you import?

No, it is 512^2 (see below) against

g.regio -p
..
rows: 3584
cols: 8064
..

Markus’ hint, not directly on the netCDF file, rather on one of the
layers:

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)

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.

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.

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

Markus M

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

On Mon, Oct 1, 2018 at 4:28 PM Nikos Alexandris <nik@nikosalexandris.net> wrote:

Nikos wrote:

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

something went wrong here:

east=179.945666666667
east should be 180 - ew_res / 2

just like

west=-180.022333333333
i.e west = -180 - ew_res / 2

I will investigate

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?

it shifts the raster map to the east, not the computational region.

If the default of -a is "to align the region resolution to match the

region boundaries",

?
from the manual:
“With the -a flag all four boundaries are adjusted to be even multiples of the resolution, aligning the region to the resolution supplied by the user.”

i.e. with the -a flag, the region boundaries are modified and the resolution is kept. The default (without -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?

If you want to “adjust the region’s resolution so as to fit these cells inside these boundaries”, you must not use the -a flag.

Markus M

Nikos wrote:

>> 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?

Markus M:

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

Importing without `-a`:

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

Importing with `-a`:

import_with_a
north=80.0223333333333
south=-79.9634444444444

Markus M:

something went wrong here:

east=179.945666666667

east should be 180 - ew_res / 2

just like

west=-180.022333333333

i.e west = -180 - ew_res / 2

I will investigate

Reported here https://trac.osgeo.org/grass/ticket/3672#ticket.

nsres=0.0446388888888889
ewres=0.0446388888888889
rows=3584
cols=8064
cells=28901376
datatype=CELL
ncats=0

Nikos

(For context see previous messages in this thread)

Nikos A:

>> g.region raster=g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc_LST
>> -pag w=-180 e=180

Markus M:

>this shifts the grid by half a cell to the east. The -a flag does
>not mak sense because 1) you want to force new extends, 2) there is
>no resolution given for use with the -a flag.

Eh.. hm, right, using `-a` is nonsensical here :slight_smile:

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

it shifts the raster map to the east, not the computational region.

Just a conceptual clarification, still after all these years:

`g.region` governs the computational region and `r.region` a raster
map's spatial specifications. These are related but independent.
How does `g.region` alter the raster map's location, if it can't modify
a raster map's spatial specifications? Do you refer to any output that
will base upon the region set?

If the default of `-a` is "to align the region resolution to match the
region boundaries",

?
from the manual:
"With the *-a* flag all four boundaries are adjusted to be even multiples
of the resolution, aligning the region to the resolution supplied by the
user."

i.e. with the -a flag, the region boundaries are modified and the
resolution is kept. The default (without -a) is to align the region
resolution to match the region boundaries.

I misfired. The manual is clear, the `-a` flag adjusts the computational
region's boundaries to be even multiples of the spatial resolution
*supplied by the user*.

Two full examples of using `-a` to `g.region` the right way, hopefully:

r.in.gdal in=NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":LST out=import -o --o

WARNING: Datum <unknown> not recognised by GRASS and no parameters found
Over-riding projection check
360 degree EW extent is exceeded by 1.00019 cells
360 degree EW extent is exceeded by 0.000192261 cells
Importing raster map <import>...
 100%

and

r.info import -g

360 degree EW extent is exceeded by 0.00019226 cells
360 degree EW extent is exceeded by 1.00019 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

and then setting the region via

g.region raster=import -ag nsres=0.0446428582072328 ewres=0.0446428582072241

360 degree EW extent is exceeded by 1.00019 cells
360 degree EW extent is exceeded by 0.00019226 cells
360 degree EW extent is exceeded by 1.00019 cells
projection=3
zone=0
n=80.0446447655684
s=-80.0000019073612
w=-180.044647149735
e=180.000004291528
nsres=0.0446428582072328
ewres=0.0446428582072241
rows=3585
cols=8065
cells=28913025

or via

g.region raster=import -ag res=0.044642858207226

360 degree EW extent is exceeded by 1.00019 cells
360 degree EW extent is exceeded by 0.00019226 cells
360 degree EW extent is exceeded by 1.00019 cells
projection=3
zone=0
n=80.0446447655562
s=-80.000001907349
w=-180.044647149742
e=180.000004291535
nsres=0.044642858207226
ewres=0.044642858207226
rows=3585
cols=8065
cells=28913025

all of which looks fine, except for the "exceeding" warnings.

With `-a`

r.in.gdal in=NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":LST out=import_with_a -o -a

WARNING: Datum <unknown> not recognised by GRASS and no parameters found
Over-riding projection check
360 degree EW extent is exceeded by 0.000192261 cells
360 degree EW extent is exceeded by 1.00019 cells
Importing raster map <import_with_a>...
 100%

and

r.info import_with_a -g
360 degree EW extent is exceeded by 1.00019 cells
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

and then setting the region

g.region raster=import_with_a -ag res=0.0446388888888889
360 degree EW extent is exceeded by 0.00019226 cells
360 degree EW extent is exceeded by 0.283136 cells
projection=3
zone=0
n=80.0375277777778
s=-79.9928888888889
w=-180.028638888889
e=179.984
nsres=0.0446388888888889
ewres=0.0446388888888889
rows=3585
cols=8065
cells=28913025

or

g.region raster=import_with_a -ag res=0.044642858207226
360 degree EW extent is exceeded by 1.00019 cells
360 degree EW extent is exceeded by 0.000192261 cells
projection=3
zone=0
n=80.0446447655562
s=-80.000001907349
w=-180.044647149742
e=179.955361433328
nsres=0.044642858207226
ewres=0.044642858207226
rows=3585
cols=8064
cells=28909440

[..]

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?

If you want to "adjust the region's resolution so as to fit these cells
inside these boundaries", you must not use the -a flag.

I got it wrong.
In short, `-a` attempts to *preserve* the (user-given?) cell resolution.

I'd like to work without the warning messages and, at the same time,
respect the spatial specifications of the input map. Given the
metadata-reported boundaries and the resolution (rows, columns) are
correct, I'd like to get these boundaries and rows by columns to govern
the definition of the computational region. Expectedly, the spatial
resolution should then be close to the one reported in the metadata.

How do we do away the warning messages? By cutting off half a cell from
the map's west limit, that is -180.0223214 + 0.044642858207226/2 = 180.
This means that the computational region will "see" only the requested
part of the map, not that a part of the map is really cut off.

Or should we cut off from the map?

Nikos

On Thu, Oct 4, 2018 at 6:54 AM Nikos Alexandris <nik@nikosalexandris.net> wrote:

(For context see previous messages in this thread)

In this case

r.in.gdal in=NETCDF:“g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc”:LST out=import -o --o

r.in.gdal -a would do more harm than good. The warning

360 degree EW extent is exceeded by 0.00019226 cells

is caused by floating point precision limits, I would leave it as it is.

These settings

r.info import -g

north=80.0223214291667
south=-79.9776823855556
east=179.977687153889
west=-180.022321429167
nsres=0.0446428582072328
ewres=0.0446428582072241
rows=3584
cols=8064
cells=28901376

are reasonably well representing the input data, I recommend using these settings without modification, i.e.

g.region raster=import -g

Markus M