<div>So, in short, I think that we could add the following at line 106 in main.c for r.water.outlet (see <a href="http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.water.outlet/main.c">http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.water.outlet/main.c</a>):</div>
<div><br></div><div>    if (window.east &gt; 180 &amp;&amp; G_projection()==3){</div><div>        E = E+360;</div><div>    }</div><div><br></div><div>Or, if I understand G_adjust_easting(), then we might be able to skip all of that and simply type:</div>
<div><br></div><div>  E = G_adjust_east_longitude(E,window.west);</div><div><br></div><div>Sound like a good improvement?</div><div><br></div><div>Andy</div>
<br><br><div class="gmail_quote">On Sat, Jul 2, 2011 at 2:16 AM, Andy Wickert <span dir="ltr">&lt;<a href="mailto:wickert@colorado.edu">wickert@colorado.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>Made some progress on this myself; think that a solution will require some minor source code modifications.</div><div><br></div><div>The main idea and my question to GRASS users/developers:</div><div><br></div>I think that I better understand the r.water.outlet problem now. Briefly, I think a proper solution would require changing the r.water.outlet source code to deal with wraparound at the 180 meridian; as it stands, the code seems to be designed for northing/easting in projected coordinate systems. I&#39;d be happy to change / recompile / test the source code; in that case, should I take this thread to the GRASS-dev list? I have found the programmer&#39;s manual, but if anyone has advice on how to start in on development in GRASS, I would greatly appreciate it.<div>

<br></div><div>Slightly more info:</div><div><br></div><div>I was able to make all the points work by specifying the window as W:-180, E:180. However, the drainage basins refused to cross the 180 meridian. I am fairly sure that these are because (1) I need increasing Easting values to make r.water.outlet work, but (2) in order to provide continously increasing Easting values, I must make a discontinuity at the 180 meridian in the middle of my data set. This makes me think that if I changed main.c inside r.water.outlet to include G_adjust_easting() within some if statments (is lat/long projection &amp; West value is greater than East), that this would solve the problem.</div>

<div><br></div><div>The workaround, of course, is to shift all location references by 180 degrees, perform calculations, and move everything back, but I&#39;d like to try to make a more elegant/permanent solution.</div><div>

<br></div><font color="#888888"><div>Andy</div></font><div><div></div><div class="h5"><div><br></div><div><br><div><div class="gmail_quote">On Tue, Jun 28, 2011 at 11:43 AM, Andy Wickert <span dir="ltr">&lt;<a href="mailto:wickert@colorado.edu" target="_blank">wickert@colorado.edu</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">OK - I think I figured out some of it. On my computer where r.water.outlet DOES work, the west-longitudes are expressed as negative 0-180, while on the computer where it doesn&#39;t work, they are expressed as positive east-longitude 180-360.<div>


<br></div><div>So: the question becomes, how do I choose how west-longitudes are interpreted by GRASS?<br>
<br>Thanks!</div><div><br></div><font color="#888888"><div>Andy</div></font><div><div></div><div><div><br></div><div><br><div class="gmail_quote">On Mon, Jun 27, 2011 at 11:00 PM, Andy Wickert <span dir="ltr">&lt;<a href="mailto:wickert@colorado.edu" target="_blank">wickert@colorado.edu</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi GRASS user-list,</div><div><br></div><div>I think that I have run into a bug in either the computational window definition or the r.water.outlet program (or maybe something else) that has to do with defining degrees West as either positive (East-longitude &gt;180) or negative.</div>



<div><br></div><div>What happens is that, for example, I type:</div><div>r.water.outlet drainage=$watershed_direction basin=temp_basin easting=196 northing=60 --verbose --overwrite</div><div><br></div><div>And GRASS returns:</div>



<div><div>WARNING: Warning, ignoring point outside window:</div><div>         -164.0000,60.0000</div></div><div><br></div><div>This occurs no matter whether I specify the longitude as a positive East-longitude (as above), as a negative value (e.g.,-164), or as, e.g., 164W. (196E is not allowed).</div>



<div><br></div><div>The problem is not my window definition, which includes the point in question:</div><div><div>proj:       3</div><div>zone:       0</div><div>north:      73:00:30N</div><div>south:      49:59:30N</div>



<div>east:       144:59:30W</div><div>west:       162:59:30E</div><div>cols:       3121</div><div>rows:       1381</div><div>e-w resol:  0:01</div><div>n-s resol:  0:01</div><div>top:        1</div><div>bottom:     0</div>



<div>cols3:      3121</div><div>rows3:      1381</div><div>depths:     1</div><div>e-w resol3: 0:01</div><div>n-s resol3: 0:01</div><div>t-b resol:  1</div></div><div><br></div><div>When I use r.what, it gives me East-longitudes (values &gt;180) for regions to the East of the 180 meridian. But r.water.outlet insists on switching everything to negatives no matter what input I give it, which I think is a source of the problem.</div>



<div><br></div><div>The strangest thing about this is that I ran into this problem while following a routine that I had written several months ago in Bash; last time, I ran r.water.outlet on North America (all in degrees-west land) with no problems at all. I just checked the computational region (window) files for that run, and they look very similar to the ones I am using now. I have no clue why I didn&#39;t run into this problem back then / why it is cropping up now; both computers are running GRASS 6.4.1 on Ubuntu Linux.</div>



<div><br></div><div>Anyway, if anyone has any suggestions, I&#39;m all ears. Many thanks in advance,</div><div><br></div><font color="#888888"><div>Andy Wickert</div>
</font></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>
</div></div></blockquote></div><br>