[GRASS-user] Re: r.water.outlet and longitude / window issue
Andy Wickert
wickert at colorado.edu
Sat Jul 2 05:01:54 EDT 2011
So, in short, I think that we could add the following at line 106 in main.c
for r.water.outlet (see
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.water.outlet/main.c
):
if (window.east > 180 && G_projection()==3){
E = E+360;
}
Or, if I understand G_adjust_easting(), then we might be able to skip all of
that and simply type:
E = G_adjust_east_longitude(E,window.west);
Sound like a good improvement?
Andy
On Sat, Jul 2, 2011 at 2:16 AM, Andy Wickert <wickert at colorado.edu> wrote:
> Made some progress on this myself; think that a solution will require some
> minor source code modifications.
>
> The main idea and my question to GRASS users/developers:
>
> 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'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's manual, but if anyone has advice on how to start in on
> development in GRASS, I would greatly appreciate it.
>
> Slightly more info:
>
> 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 & West value is greater than East), that this would
> solve the problem.
>
> The workaround, of course, is to shift all location references by 180
> degrees, perform calculations, and move everything back, but I'd like to try
> to make a more elegant/permanent solution.
>
> Andy
>
>
> On Tue, Jun 28, 2011 at 11:43 AM, Andy Wickert <wickert at colorado.edu>wrote:
>
>> 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't work, they are expressed as positive
>> east-longitude 180-360.
>>
>> So: the question becomes, how do I choose how west-longitudes are
>> interpreted by GRASS?
>>
>> Thanks!
>>
>> Andy
>>
>>
>> On Mon, Jun 27, 2011 at 11:00 PM, Andy Wickert <wickert at colorado.edu>wrote:
>>
>>> Hi GRASS user-list,
>>>
>>> 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 >180) or
>>> negative.
>>>
>>> What happens is that, for example, I type:
>>> r.water.outlet drainage=$watershed_direction basin=temp_basin easting=196
>>> northing=60 --verbose --overwrite
>>>
>>> And GRASS returns:
>>> WARNING: Warning, ignoring point outside window:
>>> -164.0000,60.0000
>>>
>>> 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).
>>>
>>> The problem is not my window definition, which includes the point in
>>> question:
>>> proj: 3
>>> zone: 0
>>> north: 73:00:30N
>>> south: 49:59:30N
>>> east: 144:59:30W
>>> west: 162:59:30E
>>> cols: 3121
>>> rows: 1381
>>> e-w resol: 0:01
>>> n-s resol: 0:01
>>> top: 1
>>> bottom: 0
>>> cols3: 3121
>>> rows3: 1381
>>> depths: 1
>>> e-w resol3: 0:01
>>> n-s resol3: 0:01
>>> t-b resol: 1
>>>
>>> When I use r.what, it gives me East-longitudes (values >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.
>>>
>>> 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't run into this problem back then / why it is cropping up
>>> now; both computers are running GRASS 6.4.1 on Ubuntu Linux.
>>>
>>> Anyway, if anyone has any suggestions, I'm all ears. Many thanks in
>>> advance,
>>>
>>> Andy Wickert
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20110702/552eedca/attachment.html
More information about the grass-user
mailing list