<html style="direction: ltr;">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body bidimailui-charset-is-forced="true" style="direction: ltr;"
    text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 07/09/2018 06:43 PM, Rich Shepard
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:alpine.LNX.2.20.1807090830110.31280@salmo.appl-ecosys.com"> 
      In the Notes section of the 7.5 r.proj manual the second and third
      <br>
      paragraphs read,
      <br>
      <br>
      "To avoid excessive time consumption when reprojecting a map the
      region and
      <br>
      resolution of the target location should be set appropriately
      beforehand."
      <br>
      <br>
        Isn't the target's location and region set when that location is
      created?
      <br>
    </blockquote>
    Yes, but you can change both anytime you need a different extent or
    resolution.<br>
    <br>
    <blockquote type="cite"
      cite="mid:alpine.LNX.2.20.1807090830110.31280@salmo.appl-ecosys.com">What
      happens to other maps (vector and raster) in that location if the
      <br>
    </blockquote>
    Nothing<br>
    <br>
    <blockquote type="cite"
      cite="mid:alpine.LNX.2.20.1807090830110.31280@salmo.appl-ecosys.com">region
      and resolution are changed to match that of the source map? I
      thought
      <br>
      that r.proj was the tool to convert the source's region and
      resolution to
      <br>
    </blockquote>
    No, r.proj transforms a raster from one projection (location) to a
    different projection (location)<br>
    <br>
    <blockquote type="cite"
      cite="mid:alpine.LNX.2.20.1807090830110.31280@salmo.appl-ecosys.com">that
      of the target.
      <br>
      <br>
      "A simple way to do this is to check the projected bounds of the
      input map
      <br>
      in the current location's projection using the -p flag. The -g
      flag reports
      <br>
      the same thing, but in a form which can be directly cut and pasted
      into a
      <br>
      g.region command. After setting the region in that way you might
      check the
      <br>
      cell resolution with "g.region -p" then snap it to a regular grid
      with
      <br>
      g.region's -a flag. E.g. g.region -a res=5 -p. Note that this is
      just a
      <br>
      rough guide."
      <br>
      <br>
        The first sentence checks the source (current) location's
      projection. The
      <br>
    </blockquote>
    You should be only in the *target* location. First run:<br>
     <tt>r.proj -g location=<source location> mapset=<source
      mapset> input=<source raster></tt><br>
    <br>
    Then copy/paste the output to the <tt>g.region -ap</tt> command.<br>
    Then rerun r.proj without the -g flag.<br>
    <br>
    <br>
    <blockquote type="cite"
      cite="mid:alpine.LNX.2.20.1807090830110.31280@salmo.appl-ecosys.com">third
      sentence suggests snapping the source grid's region and resolution
      to
      <br>
      a regular grid. Two questions about this: 1) aren't all raster
      maps on a
      <br>
      regular grid? </blockquote>
    Yes, but every projection transform creates a new regular grid,
    requiring a "warp" of the original regular grid cells. That's why
    it's a good idea to use the '-a' flag to g.region to align the cells
    and extent settings.<br>
    <br>
    <blockquote type="cite"
      cite="mid:alpine.LNX.2.20.1807090830110.31280@salmo.appl-ecosys.com">and
      2) how does this change affect the source location?
      <br>
    </blockquote>
    None whatsoever<br>
    <br>
    <blockquote type="cite"
      cite="mid:alpine.LNX.2.20.1807090830110.31280@salmo.appl-ecosys.com">
      <br>
        I'm working on understanding how to correct r.proj failures
      because the
      <br>
      source map/location is outside the bounds of the target location.
      <br>
    </blockquote>
    As Markus said, the source region settings are irrelevant here.<br>
    <br>
    One final comment: I noticed in a previous post:<br>
    >   This I did:<br>
    ><br>
    > r.proj loc=elwood map=PERMANENT in=elwood_dem2013 -g<br>
    > WARNING: Input and output locations are the same   
    <<==== ????<br>
    <br>
    Obviously, the source and target locations must be different.<br>
    <br>
    HTH,<br>
    <br>
    <blockquote type="cite"
      cite="mid:alpine.LNX.2.20.1807090830110.31280@salmo.appl-ecosys.com">
      <br>
      TIA,
      <br>
      <br>
      Rich
      <br>
      <br>
      <br>
      _______________________________________________
      <br>
      grass-user mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>
      <br>
      <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918</pre>
  </body>
</html>