Opened 9 years ago
Closed 7 years ago
#2757 closed defect (fixed)
r.import: ERROR: Input raster map is outside current region
| Reported by: | neteler | Owned by: | |
|---|---|---|---|
| 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 by , 9 years ago
comment:2 by , 9 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
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 by , 9 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
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:7 by , 9 years ago
| Milestone: | 7.0.4 → 7.0.5 |
|---|
follow-up: 10 comment:9 by , 8 years ago
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 by , 8 years ago
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.
follow-up: 12 comment:11 by , 8 years ago
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...
follow-up: 13 comment:12 by , 8 years ago
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 by , 8 years ago
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 regioncomes 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 by , 8 years ago
| Milestone: | 7.0.5 → 7.0.6 |
|---|
follow-up: 16 comment:15 by , 8 years ago
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.
follow-up: 17 comment:16 by , 8 years ago
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?
follow-up: 18 comment:17 by , 8 years ago
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 by , 8 years ago
follow-up: 20 comment:19 by , 8 years ago
| Keywords: | r.in.gdal r.external r.region added |
|---|---|
| Platform: | Unspecified → All |
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?
Finally: yet g.region is picky here:
GRASS 7.2.1svn (latlong_wgs84):~ > g.region n=90 s=-90 w=180 e=180 -p ERROR: Syntax error in cell header
comment:20 by , 8 years ago
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 by , 7 years ago
| Milestone: | 7.0.6 → 7.4.0 |
|---|---|
| Resolution: | → fixed |
| Status: | reopened → closed |
| Version: | svn-trunk → svn-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.
I added r.in.gdal's -l flag, it works then, although I don't actually know what went wrong there.