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

GRASS GIS trac at osgeo.org
Wed Sep 21 06:08:18 PDT 2016


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



More information about the grass-dev mailing list