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