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 <wick...@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 <wick...@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 <wick...@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 >>> >> >> >
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user