[GRASS-dev] [GRASS GIS] #2757: r.import: ERROR: Input raster map is outside current region

GDAL · October 12, 2015, 9:19pm

#2757: r.import: ERROR: Input raster map is outside current region
-------------------------+-------------------------
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.2
Component: Python | Version: svn-trunk
Keywords: r.import | CPU: Unspecified
Platform: Unspecified |
-------------------------+-------------------------
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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2757>
GRASS GIS <https://grass.osgeo.org>

GDAL · October 13, 2015, 2:10am

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
  Reporter: neteler | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: normal | Milestone: 7.0.2
Component: Python | Version: svn-trunk
Resolution: | Keywords: r.import
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (by annakrat):

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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2757#comment:1>
GRASS GIS <https://grass.osgeo.org>

GDAL · October 13, 2015, 10:48am

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
  Reporter: neteler | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 7.0.2
Component: Python | Version: svn-trunk
Resolution: fixed | Keywords: r.import
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Changes (by neteler):

* status: new => closed
* resolution: => fixed

Comment:

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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2757#comment:2>
GRASS GIS <https://grass.osgeo.org>

mlennert · October 13, 2015, 11:07am

On 13/10/15 12:48, GRASS GIS wrote:

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
   Reporter: neteler | Owner: grass-dev@…
       Type: defect | Status: closed
   Priority: normal | Milestone: 7.0.2
  Component: Python | Version: svn-trunk
Resolution: fixed | Keywords: r.import
        CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Changes (by neteler):

  * status: new => closed
  * resolution: => fixed

Comment:

  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.

The -n flag comes from r.proj and is explained as such in the r.proj man page:

"When reprojecting whole-world maps the user should disable map-trimming with the -n flag. Trimming is not useful here because the module has the whole map in memory anyway. Besides that, world "edges" are hard (or impossible) to find in projections other than latitude-longitude so results may be odd with trimming."

Moritz

neteler · October 13, 2015, 1:03pm

On Tue, Oct 13, 2015 at 1:07 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

The -n flag comes from r.proj and is explained as such in the r.proj man
page:

Right.

"When reprojecting whole-world maps the user should disable map-trimming
with the -n flag. Trimming is not useful here because the module has the
whole map in memory anyway.

^^^ already here I am lost Trimming is doing what (also compared to -l)?

Besides that, world "edges" are hard (or
impossible) to find in projections other than latitude-longitude so results
may be odd with trimming."

All quite complicated and contradicting a bit the purpose of r.import.
Can the usage of -n be made automated for r.import and not exposed to
the user?
(in case I suggest to hide -n for now for the 7.0.2 release, it can be
introduced later if not avoidable).

Markus

annakrat · October 13, 2015, 1:37pm

On Tue, Oct 13, 2015 at 9:03 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Tue, Oct 13, 2015 at 1:07 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
> The -n flag comes from r.proj and is explained as such in the r.proj man
> page:

Right.

> "When reprojecting whole-world maps the user should disable map-trimming
> with the -n flag. Trimming is not useful here because the module has the
> whole map in memory anyway.

^^^ already here I am lost Trimming is doing what (also compared to
-l)?

> Besides that, world "edges" are hard (or
> impossible) to find in projections other than latitude-longitude so
results
> may be odd with trimming."

All quite complicated and contradicting a bit the purpose of r.import.
Can the usage of -n be made automated for r.import and not exposed to
the user?

It can be there by default, but maybe it could be harmful in certain cases?

(in case I suggest to hide -n for now for the 7.0.2 release, it can be
introduced later if not avoidable).

It is sort of hidden in the Optional tab, I am not sure if we gain much by
hiding it completely.

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

neteler · October 13, 2015, 1:58pm

On Tue, Oct 13, 2015 at 3:37 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Tue, Oct 13, 2015 at 9:03 AM, Markus Neteler <neteler@osgeo.org> wrote:

It is sort of hidden in the Optional tab, I am not sure if we gain much by
hiding it completely.

As mentioned, I don't even understand the meaning of -n in r.proj. If
anyone knows, please rephrase it in r.proj's manual.

thanks
Markus

ecodiv · October 13, 2015, 2:32pm

I was asking myself the same some time ago. Perhaps this option does not need to be hidden, but it would be good to have a positive definition of what trimming means (also in the manual page of r.proj)? I would be inclined to think that if even Markus does not know what this means, many users won’t know either

···

On 13-10-15 15:37, Anna Petrášová wrote:

On Tue, Oct 13, 2015 at 9:03 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Tue, Oct 13, 2015 at 1:07 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

The -n flag comes from r.proj and is explained as such in the r.proj man
page:

Right.

"When reprojecting whole-world maps the user should disable map-trimming
with the -n flag. Trimming is not useful here because the module has the
whole map in memory anyway.

^^^ already here I am lost Trimming is doing what (also compared to -l)?

Besides that, world “edges” are hard (or
impossible) to find in projections other than latitude-longitude so results
may be odd with trimming."

All quite complicated and contradicting a bit the purpose of r.import.
Can the usage of -n be made automated for r.import and not exposed to
the user?

It can be there by default, but maybe it could be harmful in certain cases?

(in case I suggest to hide -n for now for the 7.0.2 release, it can be
introduced later if not avoidable).

It is sort of hidden in the Optional tab, I am not sure if we gain much by hiding it completely.

Markus

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
[grass-dev@lists.osgeo.org](mailto:grass-dev@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/grass-dev](http://lists.osgeo.org/mailman/listinfo/grass-dev)

mlennert · October 13, 2015, 2:48pm

On 13/10/15 15:58, Markus Neteler wrote:

On Tue, Oct 13, 2015 at 3:37 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Tue, Oct 13, 2015 at 9:03 AM, Markus Neteler <neteler@osgeo.org> wrote:

It is sort of hidden in the Optional tab, I am not sure if we gain much by
hiding it completely.

As mentioned, I don't even understand the meaning of -n in r.proj. If
anyone knows, please rephrase it in r.proj's manual.

In r.proj, -n provokes a call to bordwalk(), which is described in the code (bordwalk.c) as doing the following:

  * bordwalk.c - projects the border cell centers of a map or region
  * to check whether they are inside the borders of another map/region
  * in a different location, and adjusts the cell header so
  * only overlapping areas are included. The function is called by main,
  * first to project the output region into the input map and trim the
  * borders of this in order to get a smaller map, and faster and less hungry
  * memory allocation. Then main calls the function again, but reversed,
  * to project the input map on the output region, trimming this down to
  * the smallest possible rectangular region.

So, IIUC, this means that -n already crops the input map in the input location before reprojection, instead of only writing those parts of the output map that fall into the current region. This makes reprojection faster if the target region is only a subset of the input map (again AFAIU).

Moritz

GDAL · October 19, 2015, 7:59pm

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
  Reporter: neteler | Owner: grass-dev@…
      Type: defect | Status: reopened
  Priority: normal | Milestone: 7.0.2
Component: Python | Version: svn-trunk
Resolution: | Keywords: r.import
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Changes (by neteler):

* status: closed => reopened
* resolution: fixed =>

Comment:

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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2757#comment:3>
GRASS GIS <https://grass.osgeo.org>

GDAL · August 23, 2016, 1:10pm

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
  Reporter: neteler | Owner: grass-dev@…
      Type: defect | Status: reopened
  Priority: normal | Milestone: 7.0.5
Component: Python | Version: svn-trunk
Resolution: | Keywords: r.import
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (by martinl):

Still the issue?

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2757#comment:8>
GRASS GIS <https://grass.osgeo.org>

GDAL · August 29, 2016, 9:53pm

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
  Reporter: neteler | Owner: grass-dev@…
      Type: defect | Status: reopened
  Priority: normal | Milestone: 7.0.5
Component: Python | Version: svn-trunk
Resolution: | Keywords: r.import
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (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>
}}}

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2757#comment:9>
GRASS GIS <https://grass.osgeo.org>

GDAL · September 1, 2016, 9:42pm

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
  Reporter: neteler | Owner: grass-dev@…
      Type: defect | Status: reopened
  Priority: normal | Milestone: 7.0.5
Component: Python | Version: svn-trunk
Resolution: | Keywords: r.import
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (by mmetz):

Replying to [comment:9 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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2757#comment:10>
GRASS GIS <https://grass.osgeo.org>

GDAL · September 1, 2016, 9:59pm

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
  Reporter: neteler | Owner: grass-dev@…
      Type: defect | Status: reopened
  Priority: normal | Milestone: 7.0.5
Component: Python | Version: svn-trunk
Resolution: | Keywords: r.import
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (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...

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2757#comment:11>
GRASS GIS <https://grass.osgeo.org>

GDAL · September 2, 2016, 7:10pm

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
  Reporter: neteler | Owner: grass-dev@…
      Type: defect | Status: reopened
  Priority: normal | Milestone: 7.0.5
Component: Python | Version: svn-trunk
Resolution: | Keywords: r.import
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (by mmetz):

Replying to [comment:11 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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2757#comment:12>
GRASS GIS <https://grass.osgeo.org>

GDAL · September 21, 2016, 1:08pm

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
  Reporter: neteler | Owner: grass-dev@…
      Type: defect | Status: reopened
  Priority: normal | Milestone: 7.0.5
Component: Python | Version: svn-trunk
Resolution: | Keywords: r.import
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (by mmetz):

Replying to [comment:12 mmetz]:
> Replying to [comment:11 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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2757#comment:13>
GRASS GIS <https://grass.osgeo.org>

GDAL · February 10, 2017, 9:33pm

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
  Reporter: neteler | Owner: grass-dev@…
      Type: defect | Status: reopened
  Priority: normal | Milestone: 7.0.6
Component: Python | Version: svn-trunk
Resolution: | Keywords: r.import
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2757#comment:15>
GRASS GIS <https://grass.osgeo.org>

GDAL · February 22, 2017, 8:25am

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
  Reporter: neteler | Owner: grass-dev@…
      Type: defect | Status: reopened
  Priority: normal | Milestone: 7.0.6
Component: Python | Version: svn-trunk
Resolution: | Keywords: r.import
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (by hellik):

Replying to [comment:15 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?

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2757#comment:16>
GRASS GIS <https://grass.osgeo.org>

GDAL · February 22, 2017, 9:16am

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
  Reporter: neteler | Owner: grass-dev@…
      Type: defect | Status: reopened
  Priority: normal | Milestone: 7.0.6
Component: Python | Version: svn-trunk
Resolution: | Keywords: r.import
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (by mmetz):

Replying to [comment:16 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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2757#comment:17>
GRASS GIS <https://grass.osgeo.org>

GDAL · March 2, 2017, 9:44pm

#2757: r.import: ERROR: Input raster map is outside current region
--------------------------+-------------------------
  Reporter: neteler | Owner: grass-dev@…
      Type: defect | Status: reopened
  Priority: normal | Milestone: 7.0.6
Component: Python | Version: svn-trunk
Resolution: | Keywords: r.import
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (by neteler):

Replying to [comment:17 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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2757#comment:18>
GRASS GIS <https://grass.osgeo.org>