Opened 5 years ago

Closed 3 years ago

#2757 closed defect (fixed)

r.import: ERROR: Input raster map is outside current region

Reported by: neteler Owned by: grass-dev@…
Priority: normal Milestone: 7.4.0
Component: Python Version: svn-releasebranch74
Keywords: r.import, r.in.gdal, r.external, r.region Cc:
CPU: Unspecified Platform: All

Description

Both in trunk and relbranch70 (r66401 for a needed backport) I face a problem with r.import:

# get Bioclim data
wget http://biogeo.ucdavis.edu/data/climate/worldclim/1_4/grid/cur/bio_2-5m_bil.zip
# unpack bioclim1
unzip bio_2-5m_bil.zip bio1.bil bio1.hdr
# check
gdalinfo bio1.bil
Driver: EHdr/ESRI .hdr Labelled
Files: bio1.bil
       bio1.hdr
Size is 8640, 3600
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        TOWGS84[0,0,0,0,0,0,0],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9108"]],
    AUTHORITY["EPSG","4326"]]
Origin = (-180.000000000003354,90.000000000000028)
Pixel Size = (0.041666666666667,-0.041666666666667)
Corner Coordinates:
Upper Left  (-180.0000000,  90.0000000) (180d 0' 0.00"W, 90d 0' 0.00"N)
Lower Left  (-180.0000000, -60.0000000) (180d 0' 0.00"W, 60d 0' 0.00"S)
Upper Right ( 180.0000000,  90.0000000) (180d 0' 0.00"E, 90d 0' 0.00"N)
Lower Right ( 180.0000000, -60.0000000) (180d 0' 0.00"E, 60d 0' 0.00"S)
Center      (  -0.0000000,  15.0000000) (  0d 0' 0.00"W, 15d 0' 0.00"N)
Band 1 Block=8640x1 Type=Int16, ColorInterp=Undefined
  Min=-278.000 Max=319.000 
  NoData Value=-9999


# The goal is to reproject and import just 
# the NC portion of the Bioclim1 map:

GRASS 7.1.svn (nc_spm_08_grass7): > g.region -dp
projection: 99 (Lambert Conformal Conic)
zone:       0
datum:      nad83
ellipsoid:  a=6378137 es=0.006694380022900787
north:      320000
south:      10000
west:       120000
east:       935000
nsres:      500
ewres:      500
rows:       620
cols:       1630
cells:      1010600

GRASS 7.1.svn (nc_spm_08_grass7): > r.import input=bio1.bil output=bioclim1 resample=bilinear extent=region resolution=region
Proceeding with import of 1 raster bands...
WARNING: Fixing subtle input data rounding error of north boundary
         (2.84217e-14>2.77778e-07)
Importing raster map <bioclim1>...
 100%
Estimated target resolution for input band <bioclim1>: 4021.79
Reprojecting <bioclim1>...
ERROR: Input raster map is outside current region
ERROR: Unable to to reproject raster <bioclim1>


# while I don't really know what -n means:
GRASS 7.1.svn (nc_spm_08_grass7): > r.import input=bio1.bil output=bioclim1 resample=bilinear extent=region resolution=region -n
Proceeding with import of 1 raster bands...
WARNING: Fixing subtle input data rounding error of north boundary
         (2.84217e-14>2.77778e-07)
Importing raster map <bioclim1>...
 100%
Estimated target resolution for input band <bioclim1>: 4021.79
Reprojecting <bioclim1>...

GRASS 7.1.svn (nc_spm_08_grass7): > r.info -r bioclim1
min=-nan
max=-nan

The import of the requested map subset is not working.

Change History (21)

comment:1 Changed 5 years ago by annakrat

I added r.in.gdal's -l flag, it works then, although I don't actually know what went wrong there.

comment:2 Changed 5 years ago by neteler

Resolution: fixed
Status: newclosed

Thanks, with -l we can successfully import the Bioclim data which slightly exceed the "world extent".

(for the record, the -l flag was added in r37469 in r.in.gdal)

So only the -n flag remains unclear to me but we didn't need to use it here.

Closing since the original problem is solved.

comment:3 Changed 5 years ago by neteler

Resolution: fixed
Status: closedreopened

Reopening:

In r66528 I have added an example in the manual (Bioclim), yet nothing is imported.

Same map as above:

GRASS 7.1.svn (nc_spm_08_grass7):~ > r.import input=bio1.bil output=bioclim01 extent=region resolution=region -n --o
Proceeding with import of 1 raster bands...
WARNING: Fixing subtle input data rounding error of north boundary
         (2.84217e-14>2.77778e-07)
Importing raster map <bioclim01>...
 100%
Estimated target resolution for input band <bioclim01>: 4009.08060192
Using current region resolution for input band <bioclim01>: nsres=4000.0,
ewres=4000.0
Reprojecting <bioclim01>...
ERROR: The reprojected raster <bioclim01> is empty

Using version=7.1.svn, revision=66528, build_date=2015-10-19

comment:4 Changed 5 years ago by neteler

Milestone: 7.0.27.0.3

Ticket retargeted after milestone closed

comment:5 Changed 5 years ago by neteler

Milestone: 7.0.3

Ticket retargeted after milestone closed

comment:6 Changed 5 years ago by neteler

Milestone: 7.0.4

Ticket retargeted after 7.0.3 milestone closed

comment:7 Changed 5 years ago by martinl

Milestone: 7.0.47.0.5

comment:8 Changed 4 years ago by martinl

Still the issue?

comment:9 Changed 4 years ago by neteler

Yes (for the full test procedure, see original report above)

GRASS 7.3.svn (nc_spm_08_grass7):~ > g.region -dp
projection: 99 (Lambert Conformal Conic)
zone:       0
datum:      nad83
ellipsoid:  a=6378137 es=0.006694380022900787
north:      320000
south:      10000
west:       120000
east:       935000
nsres:      500
ewres:      500
rows:       620
cols:       1630
cells:      1010600

GRASS 7.3.svn (nc_spm_08_grass7):~ > r.import input=bio1.bil output=bioclim1 resample=bilinear extent=region resolution=region
Proceeding with import of 1 raster bands...
WARNING: Fixing subtle input data rounding error of north boundary
         (2.84217e-14>2.77778e-07)
Importing raster map <bioclim1>...
 100%
Estimated target resolution for input band <bioclim1>: 4021.78765331
Using current region resolution for input band <bioclim1>: nsres=500.0,
ewres=500.0
Reprojecting <bioclim1>...
ERROR: Input raster map is outside current region
ERROR: Unable to to reproject raster <bioclim1>

comment:10 in reply to:  9 Changed 4 years ago by mmetz

Replying to neteler:

Yes (for the full test procedure, see original report above)

You could try to import bio1.bil with r.in.gdal into a latlon location and check with r.info if anything strange shows up in the extents and/or resolutions.

comment:11 Changed 4 years ago by neteler

In fact, it looks reasonable:

GRASS 7.2.svn (latlong):~/software/bla > r.in.gdal bio1.bil out=bio1
Proceeding with import of 1 raster bands...
WARNING: Fixing subtle input data rounding error of north boundary
         (2.84217e-14>2.77778e-07)
Importing raster map <bio1>...
r.in 100%
GRASS 7.2.svn (latlong):~/software/bla > r.info bio1
 +----------------------------------------------------------------------------+
 | Map:      bio1                           Date: Thu Sep  1 23:58:23 2016    |
 | Mapset:   neteler                        Login of Creator: neteler         |
 | Location: latlong                                                          |
 | DataBase: /home/neteler/grassdata                                          |
 | Title:     ( bio1 )                                                        |
 | Timestamp: none                                                            |
 |----------------------------------------------------------------------------|
 |                                                                            |
 |   Type of Map:  raster               Number of Categories: 0               |
 |   Data Type:    CELL                                                       |
 |   Rows:         3600                                                       |
 |   Columns:      8640                                                       |
 |   Total Cells:  31104000                                                   |
 |        Projection: Latitude-Longitude                                      |
 |            N:        90N    S:        60S   Res: 0:02:30                   |
 |            E:       180E    W:       180E   Res: 0:02:30                   |
 |   Range of data:    min = -278  max = 319                                  |
 |                                                                            |
 |   Data Description:                                                        |
 |    generated by r.in.gdal                                                  |
 |                                                                            |
 |   Comments:                                                                |
 |    r.in.gdal input="bio1.bil" output="bio1" memory=300 offset=0 num_dig\   |
 |    its=0                                                                   |
 |                                                                            |
 +----------------------------------------------------------------------------+

So, r.import seems to do "extra" to it...

comment:12 in reply to:  11 ; Changed 4 years ago by mmetz

Replying to neteler:

In fact, it looks reasonable:

GRASS 7.2.svn (latlong):~/software/bla > r.info bio1
 
[...]
 |            E:       180E    W:       180E   Res: 0:02:30                   |

The E-W extents do not look reasonable to me: E = W = 180E, thus E - W = 0, while it should be W=180W and E=180E. libgis accounts for such cases, resulting in w=180, e=540 (180 + 360), but unfortunately GRASS restricts (not always) longitude extents to [-180, 180].

So, r.import seems to do "extra" to it...

r.import is a script calling r.in.gdal and r.proj. The reported error

ERROR: Input raster map is outside current region

comes from r.proj. I guess that the input raster region's E-W extent is mapped to W=180W and E=540E which does not overlap with the target region.

comment:13 in reply to:  12 Changed 4 years ago by mmetz

Replying to mmetz:

Replying to neteler:

In fact, it looks reasonable:

GRASS 7.2.svn (latlong):~/software/bla > r.info bio1
 
[...]
 |            E:       180E    W:       180E   Res: 0:02:30                   |

The E-W extents do not look reasonable to me: E = W = 180E, thus E - W = 0, while it should be W=180W and E=180E. libgis accounts for such cases, resulting in w=180, e=540 (180 + 360), but unfortunately GRASS restricts (not always) longitude extents to [-180, 180].

With some debugging, the extents as derived from GDAL geotransform parameters are

North: 90.000000000000028
South: -60.000000000001165
West: -180.00000000000335
East: 179.99999999999949

West is slightly smaller than -180, changed by G_lon_parts() to 179.99999999999775, then converted to DMS where seconds are rounded by printing with "%f" (default 6 decimal places). The final result is 180E, same as for East = 179.99999999999949 after gone through G_lon_format() calling G_lon_parts(). When reading this region definition in DMS format, G_adjust_Cell_head() converts W=180, E=180 to W=180, E=540.

I suggest to add some cleaning to r.in.gdal to remove these tiny fp representation errors. Also, I am not sure if it is a good idea to force longitudes within the range of -180,180 because there are raster maps starting west of 180W (e.g. SRTM and derived like GMTED2010) and many meteorological data are within 0,360 (e.g. CMIP5 climate models). GRASS wraps everything to -180,180, later on tries to fix any zero EW extent but sometimes makes things worse. This longitude-wrapping is also the reason why some raster imports result in a very narrow vertical stripe near 180E.

So, r.import seems to do "extra" to it...

r.import is a script calling r.in.gdal and r.proj. The reported error

ERROR: Input raster map is outside current region

comes from r.proj. I guess that the input raster region's E-W extent is mapped to W=180W and E=540E

I meant mapped to W=180E and E=540E

which does not overlap with the target region.

comment:14 Changed 4 years ago by neteler

Milestone: 7.0.57.0.6

comment:15 Changed 4 years ago by mmetz

Related tickets are #167, #352, #378, #1594, #1734, #2931, there are probably more.

West-East extent

Currently, GRASS wraps any ll coordinates outside -180, 180 to -180, 180. This causes troubles with raster maps outside this range, and there are many valid raster data existing with a West-East extent outside this range. Examples are GMTED2010 with a range of 180:00:00.5W to 179:59:59.5E, or meteorological or climate data with a West-East extent of appr. 0, 360, often shifted by about half a cell size. I suggest to relax GRASS latlong wrapping to allow regions to be within -180,360 plus a tolerance of ew_res. This would allow to import e.g. a global mosaik of SRTM tiles where the first and last columns are identical and the West-East extent is 360 degrees + ew_res. Single coordinates should not be wrapped automatically, this is creating too many problems. Instead, a window can be wrapped, i.e. shift west and east together, not separately. This guarantees that east is always larger than west. Currently, GRASS produces internally windows with e.g. w=180 e=540, this would also be avoided.

North-South extent

I suggest to allow extents above 90 and below -90 as long as 90, -90 bounds are not exceeded by more than half a cell size. The reasoning is that as long as the cell center is within 90, -90, the grid geometry is accepted as ok.

Regarding the ll extents, libgis would need to be fixed in ll_format.c and ll_scan.c where the checks for and wrapping to -90,90, and -180,180 need to be removed. In adj_cellhd.c, a new simple window wrapping method would need to be added:

while (west >= 180) {
    west -= 360;
    east -= 360;
}

while (east <= -180) {
    west += 360;
    east += 360;
} 

Import of raster data with corrupt grid geometry

There are lots of raster data where the metadata on the grid geometry are slightly wrong, e.g. by cutting the precision of the resolution which will in turn result in wrong extents reported by GDAL. Fixing the resolution in latlong is often but not always relatively easy by converting the resolution from degrees to seconds, then rounding seconds to the nearest multiple of 0.5 seconds. It is rather difficult to figure out which extent would then need to be adjusted. Often, the reference point is the lower left (South-West) corner, but not always. Considering the reference point as correct, the corresponding extent can be re-calculated, e.g. if South is assumed correct, get North as South + fixed ns_res * nrows. An attempt to fix such a corrupt grid geometry can be made in r.in.gdal.

comment:16 in reply to:  15 ; Changed 4 years ago by hellik

Replying to mmetz:

Related tickets are #167, #352, #378, #1594, #1734, #2931, there are probably more.

West-East extent

Currently, GRASS wraps any ll coordinates outside -180, 180 to -180, 180. This causes troubles with raster maps outside this range, and there are many valid raster data existing with a West-East extent outside this range. Examples are GMTED2010 with a range of 180:00:00.5W to 179:59:59.5E, or meteorological or climate data with a West-East extent of appr. 0, 360, often shifted by about half a cell size. I suggest to relax GRASS latlong wrapping to allow regions to be within -180,360 plus a tolerance of ew_res. This would allow to import e.g. a global mosaik of SRTM tiles where the first and last columns are identical and the West-East extent is 360 degrees + ew_res. Single coordinates should not be wrapped automatically, this is creating too many problems. Instead, a window can be wrapped, i.e. shift west and east together, not separately. This guarantees that east is always larger than west. Currently, GRASS produces internally windows with e.g. w=180 e=540, this would also be avoided.

North-South extent

I suggest to allow extents above 90 and below -90 as long as 90, -90 bounds are not exceeded by more than half a cell size. The reasoning is that as long as the cell center is within 90, -90, the grid geometry is accepted as ok.

Regarding the ll extents, libgis would need to be fixed in ll_format.c and ll_scan.c where the checks for and wrapping to -90,90, and -180,180 need to be removed. In adj_cellhd.c, a new simple window wrapping method would need to be added:

while (west >= 180) {
    west -= 360;
    east -= 360;
}

while (east <= -180) {
    west += 360;
    east += 360;
} 

Import of raster data with corrupt grid geometry

There are lots of raster data where the metadata on the grid geometry are slightly wrong, e.g. by cutting the precision of the resolution which will in turn result in wrong extents reported by GDAL. Fixing the resolution in latlong is often but not always relatively easy by converting the resolution from degrees to seconds, then rounding seconds to the nearest multiple of 0.5 seconds. It is rather difficult to figure out which extent would then need to be adjusted. Often, the reference point is the lower left (South-West) corner, but not always. Considering the reference point as correct, the corresponding extent can be re-calculated, e.g. if South is assumed correct, get North as South + fixed ns_res * nrows. An attempt to fix such a corrupt grid geometry can be made in r.in.gdal.

I've seen some related commits to this: r70642, r70643, r70644, r70645, r70646, r70647

any test cases, hints how to test this new feature?

comment:17 in reply to:  16 ; Changed 4 years ago by mmetz

Replying to hellik:

I've seen some related commits to this: r70642, r70643, r70644, r70645, r70646, r70647

also r70656

any test cases, hints how to test this new feature?

Population for Madagascar from http://www.worldpop.org.uk/

resolution is 0.000833300000000, should be 0.000833333333333

GRASS 7.2
N: 11:57:04.9988S    S: 25:36:24.03236S   Res: 0:00:02.99988
E: 50:29:05.949529E    W: 43:11:16.000369E   Res: 0:00:02.99988

trunk
N: 11:57:04.9988S    S: 25:36:24.03236S   Res: 0:00:02.99988
E: 50:29:05.949529E    W: 43:11:16.000369E   Res: 0:00:02.99988

trunk, automatic adjustment
N:  11:57:05S    S:  25:36:26S   Res: 0:00:03
E:  50:29:07E    W:  43:11:16E   Res: 0:00:03

worldclim global 2.5 minutes

GRASS 7.2
N:        90N    S:        60S   Res: 0:02:30
E:       180E    W:       180E   Res: 0:02:30
-> West is wrong, must be 180W

trunk
N:        90N    S:        60S   Res: 0:02:30
E:       180E    W:       180W   Res: 0:02:30

trunk, automatic adjustment
N:        90N    S:        60S   Res: 0:02:30
E:       180E    W:       180W   Res: 0:02:30

CHELSA version 1.1

GRASS 7.2
N: 83:59:59.497495N    S:        90S   Res: 0:00:29.999976
E: 179:59:59.494816E    W: 179:59:59.5E   Res: 0:00:30
-> South has been cut
-> West is too far east,
   East will silently be wrapped by lib/gis/adj_cellhd.c:L119,120
   to 539:59:59.494816E, causing all sorts of problems

trunk
N: 83:59:59.497495N    S: 90:00:00.5S   Res: 0:00:30
E: 179:59:59.494816E    W: 180:00:00.5W   Res: 0:00:30

trunk, automatic adjustment
N: 83:59:59.5N    S: 90:00:00.5S   Res: 0:00:30
E: 179:59:59.5E    W: 180:00:00.5W   Res: 0:00:30

The automatic adjustment in trunk is not yet used by any module, candidates are r.in.gdal, r.external, r.region.

comment:18 in reply to:  17 Changed 4 years ago by neteler

Replying to mmetz:

The automatic adjustment in trunk is not yet used by any module, candidates are r.in.gdal, r.external, r.region.

For the record: r70664: r.in.gdal, r.external, r.region: add flag to auto-adjust cell header in lat/lon

comment:19 Changed 4 years ago by neteler

Keywords: r.in.gdal r.external r.region added
Platform: UnspecifiedAll

I have tested r70664 with the GMTED2010 elevation model:

gdalinfo /vsizip/vsicurl/http://edcintl.cr.usgs.gov/downloads/sciweb1/shared/topo/downloads/GMTED/Grid_ZipFiles/mn30_grd.zip/mn30_grd -nofl -norat
Driver: AIG/Arc/Info Binary Grid
Files: /vsizip/vsicurl/http://edcintl.cr.usgs.gov/downloads/sciweb1/shared/topo/downloads/GMTED/Grid_ZipFiles/mn30_grd.zip/mn30_grd
Size is 43200, 20880
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]
Origin = (-180.000138888888927,83.999860415111328)
Pixel Size = (0.008333333300000,-0.008333333300000)
Corner Coordinates:
Upper Left  (-180.0001389,  83.9998604) (180d 0' 0.50"W, 83d59'59.50"N)
Lower Left  (-180.0001389, -90.0001389) (180d 0' 0.50"W, 90d 0' 0.50"S)
Upper Right ( 179.9998597,  83.9998604) (179d59'59.49"E, 83d59'59.50"N)
Lower Right ( 179.9998597, -90.0001389) (179d59'59.49"E, 90d 0' 0.50"S)
Center      (  -0.0001396,  -3.0001392) (  0d 0' 0.50"W,  3d 0' 0.50"S)
Band 1 Block=256x16 Type=Int16, ColorInterp=Undefined
  Min=-430.000 Max=8625.000 
  NoData Value=-32768

GRASS 7.3.svn (latlong_wgs84):~ > r.in.gdal /vsizip/vsicurl/http://edcintl.cr.usgs.gov/downloads/sciweb1/shared/topo/downloads/GMTED/Grid_ZipFiles/mn30_grd.zip/mn30_grd out=gmted2010_mn30_grd -a
90 degree south is exceeded by 0.0166667 cells
90 degree south is exceeded by 0.0166667 cells
Importing raster map <gmted2010_mn30_grd>...
 100%
ERROR 4: Failed to open file /vsizip/vsicurl/http://edcintl.cr.usgs.gov/downloads/sciweb1/shared/topo/downloads/GMTED/Grid_ZipFiles/mn30_grd.zip/mn30_grd/../info/arc.dir


GRASS 7.3.svn (latlong_wgs84):~ > r.info -r gmted2010_mn30_grd
90 degree south is exceeded by 0.0166667 cells
min=-430
max=8625


GRASS 7.3.svn (latlong_wgs84):~ > g.region raster=gmted2010_mn30_grd -g
90 degree south is exceeded by 0.0166667 cells
90 degree south is exceeded by 0.0166667 cells
90 degree south is exceeded by 0.0166667 cells
projection=3
zone=0
n=83.9998611111111
s=-90.0001388888889
w=-180.000138888889
e=179.999861111111
nsres=0.00833333333333333
ewres=0.00833333333333333
rows=20880
cols=43200
cells=902016000

Excellent! I see that:

  • Number of rows and cols match the figures reported by gdalinfo.
  • The resolution is now correctly set to 0.00833333333333333 (unlike the original resolution of 0.008333333300000 with its precision loss).

Observation: Still the E-W center is not 0 and n=83.9998611111111 (I expected > 84N but maybe an issue with the original data?):

GRASS 7.3.svn (latlong_wgs84):~ > g.region -c
90 degree south is exceeded by 0.0166667 cells
90 degree south is exceeded by 0.0166667 cells
north-south center: 3:00:00.5S
east-west center: 0:00:00.5W

Another question:

What would be the best way now to "silence" the excess messages? Adjust the computational region and make a map copy with r.mapcalc to fit into -180..+180, -90..+90?

Last edited 4 years ago by neteler (previous) (diff)

comment:20 in reply to:  19 Changed 4 years ago by mmetz

Replying to neteler:

I have tested r70664 with the GMTED2010 elevation model:

original resolution and extents:

gdalinfo /vsizip/vsicurl/http://edcintl.cr.usgs.gov/downloads/sciweb1/shared/topo/downloads/GMTED/Grid_ZipFiles/mn30_grd.zip/mn30_grd -nofl -norat
[...]
Pixel Size = (0.008333333300000,-0.008333333300000)
Corner Coordinates:
Upper Left  (-180.0001389,  83.9998604) (180d 0' 0.50"W, 83d59'59.50"N)
Lower Left  (-180.0001389, -90.0001389) (180d 0' 0.50"W, 90d 0' 0.50"S)
Upper Right ( 179.9998597,  83.9998604) (179d59'59.49"E, 83d59'59.50"N)
Lower Right ( 179.9998597, -90.0001389) (179d59'59.49"E, 90d 0' 0.50"S)
Center      (  -0.0001396,  -3.0001392) (  0d 0' 0.50"W,  3d 0' 0.50"S)

resolution and extents of the imported map:

GRASS 7.3.svn (latlong_wgs84):~ > g.region raster=gmted2010_mn30_grd -g
90 degree south is exceeded by 0.0166667 cells
90 degree south is exceeded by 0.0166667 cells
90 degree south is exceeded by 0.0166667 cells
projection=3
zone=0
n=83.9998611111111
s=-90.0001388888889
w=-180.000138888889
e=179.999861111111
nsres=0.00833333333333333
ewres=0.00833333333333333
rows=20880
cols=43200
cells=902016000

Why g.region -g? Here, g.region -p is more informative because it uses DMS format.

Observation: Still the E-W center is not 0 and n=83.9998611111111 (I expected > 84N but maybe an issue with the original data?):

Why do you expect N > 84N? gdal reports 83d59'59.50"N.

Another question:

What would be the best way now to "silence" the excess messages?

These messages are important because they indicate region settings that are not compatible with G7.2 or earlier.

Adjust the computational region and make a map copy with r.mapcalc to fit into -180..+180, -90..+90?

Why do you want to fit the map into -180 / 180, -90 / 90? The original map extents with east corrected for limited fp precision are

w=180:00:00.50W
e=179:59:59.50E
n=83:59:59.50N
s=90:00:00.50S

In trunk, this is a perfectly valid region, even though South is south of 90S by half a second.

Also, r.region is much easier than r.mapcalc in this case, if there is still need to correct the extents and resolution of the imported map.

comment:21 Changed 3 years ago by neteler

Milestone: 7.0.67.4.0
Resolution: fixed
Status: reopenedclosed
Version: svn-trunksvn-releasebranch74

Checking this ticket with GRASS GIS 7.4:

# Fedora box
GRASS 7.4.1svn (nc_basic_spm_grass7):/scratch > g.version -ger
version=7.4.1svn
date=2018
revision=r72180
build_date=2018-01-28
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=70829 
libgis_date="2017-04-04 09:43:02 +0200 (Tue, 04 Apr 2017) "
proj4=4.9.3
gdal=2.1.3
geos=3.6.1
sqlite=3.20.1

Test in Long-Lat:

GRASS 7.4.1svn (latlong_wgs84):/scratch > r.import input=bio1.bil output=bioclim1
90 degree north is exceeded by 6.82121e-13 cells
Importing raster map <bioclim1>...
 100%
GRASS 7.4.1svn (latlong_wgs84):/scratch > g.region raster=bioclim1 -p
projection: 3 (Latitude-Longitude)
zone:       0
datum:      wgs84
ellipsoid:  wgs84
north:      90N
south:      60S
west:       180W
east:       180E
nsres:      0:02:30
ewres:      0:02:30
rows:       3600
cols:       8640
cells:      31104000

GRASS 7.4.1svn (latlong_wgs84):/scratch > g.region raster=bioclim1 -g
projection=3
zone=0
n=90
s=-60
w=-180
e=180
nsres=0.0416666666666667
ewres=0.0416666666666667
rows=3600
cols=8640
cells=31104000

Test in NC sample dataset location:

GRASS 7.4.1svn (nc_basic_spm_grass7):/scratch > r.import input=bio1.bil output=bioclim1 resample=bilinear extent=region resolution=region
WARNING: Projection of dataset does not appear to match current location.

         Location PROJ_INFO is:
         name: Lambert Conformal Conic
         proj: lcc
         datum: nad83
         a: 6378137.0
         es: 0.006694380022900787
         lat_1: 36.16666666666666
         lat_2: 34.33333333333334
         lat_0: 33.75
         lon_0: -79
         x_0: 609601.22
         y_0: 0
         no_defs: defined

         Dataset PROJ_INFO is:
         name: WGS 84
         datum: wgs84
         ellps: wgs84
         proj: ll
         no_defs: defined

         ERROR: proj

         In case of no significant differences in the projection
         definitions, use the -o flag to ignore them and use current
         location definition.
         Consider generating a new location from the input dataset using
         the 'location' parameter.
90 degree north is exceeded by 6.82121e-13 cells
Importing raster map <bioclim1>...
 100%
Estimated target resolution for input band <bioclim1>: 4021.78765331
Using current region resolution for input band <bioclim1>: nsres=500.0,
ewres=500.0
Reprojecting <bioclim1>...

GRASS 7.4.1svn (nc_basic_spm_grass7):/scratch > g.region -p raster=bioclim1
projection: 99 (Lambert Conformal Conic)
zone:       0
datum:      nad83
ellipsoid:  a=6378137 es=0.006694380022900787
north:      320000
south:      10000
west:       120000
east:       935000
nsres:      500
ewres:      500
rows:       620
cols:       1630
cells:      1010600

(the "ERROR: proj" is a bit disturbing as a message, since using r.import)

It looks ok to me - thanks for the hard work esp. by Markus Metz on improving the global data import and treatment of global data with coordinate precision issues!

Closing, this improvement is part of the recently published GRASS GIS 7.4.0.

Note: See TracTickets for help on using tickets.