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

[GRASS GIS]

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