[GRASS-user] Re: r.water.outlet and longitude / window issue

Sat Jul 2 14:10:53 EDT 2011

SOLVED:

Built and installed GRASS 6.4.2 from svn, and added a line as noted below;
inserted at line 101 in 6.4.2 (see surrounding lines for context).
Recompiled r.water.outlet and it works like a charm.

It is totally obvious that this is not an issue that anyone on this list
knows/cares about, so could someone at least let me know where to take it
such that can get incorporated into the GRASS source and no one else has the
same problem? I'm thinking the grass-dev list, but I'd rather not use a
loudspeaker to have another conversation with myself if I can avoid it :)

G_usage();
exit(EXIT_FAILURE);
    }

  E = G_adjust_east_longitude(E,window.west); // <-- NEW LINE; for using
lat/lon data that straddle the 180 meridian

    if (E < window.west || E > window.east || N < window.south ||
N > window.north) {

Andy Wickert
PhD Candidate
University of Colorado
Geological Sciences & Institute of Arctic and Alpine Research
1560 30th St.
Boulder, CO 80303
Office: RL3-275

On Sat, Jul 2, 2011 at 3:01 AM, Andy Wickert <wickert at colorado.edu> wrote:

> 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/b259609a/attachment.html