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

Andy_Wickert1 · June 28, 2011, 5:00am

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

Andy_Wickert1 · June 28, 2011, 5:43pm

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@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

Andy_Wickert1 · July 2, 2011, 8:16am

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@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@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

Andy_Wickert1 · July 2, 2011, 9:01am

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@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@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@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

Andy_Wickert1 · July 2, 2011, 6:10pm

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@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@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@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@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

Daniel_Lee · July 2, 2011, 6:12pm

Hi Andy,

I think it’s great that you’ve fixed the bug. I read your emails with interest but, as it’s not my area of expertise, I didn’t write back. As far as changes to the GRASS source goes, I do think that the grass-dev list would be the right place to take up such issues. You’d have my blessing at least

Best,
Daniel

On Sat, Jul 2, 2011 at 8:10 PM, Andy Wickert <wickert@colorado.edu> wrote:

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@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@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@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@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

–

B.Sc. Daniel Lee

Geschäftsführung für Forschung und Entwicklung

ISIS - International Solar Information Solutions

Deutschhausstr. 10

35037 Marburg

Festnetz: +49 6421 379 6256

Mobil: +49 176 6127 7269

E-Mail: Lee@isi-solutions.org

Web: http://www.isi-solutions.org

Andy_Wickert1 · July 2, 2011, 6:33pm

OK - great!

Didn’t mean the the “knows/cares” in a bad way - more a matter of fact one :). I figured that when I didn’t get a response, it was because no one had a solution off the top of their head, so I’d have to do it.

Thanks!

Andy

On Sat, Jul 2, 2011 at 12:12 PM, Daniel Lee <lee@isi-solutions.org> wrote:

Hi Andy,

I think it’s great that you’ve fixed the bug. I read your emails with interest but, as it’s not my area of expertise, I didn’t write back. As far as changes to the GRASS source goes, I do think that the grass-dev list would be the right place to take up such issues. You’d have my blessing at least

Best,
Daniel

On Sat, Jul 2, 2011 at 8:10 PM, Andy Wickert <wickert@colorado.edu> wrote:

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@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@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@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@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

–

B.Sc. Daniel Lee

Geschäftsführung für Forschung und Entwicklung

ISIS - International Solar Information Solutions

Deutschhausstr. 10

35037 Marburg

Festnetz: +49 6421 379 6256

Mobil: +49 176 6127 7269

E-Mail: Lee@isi-solutions.org

Web: http://www.isi-solutions.org