Re: [GRASS-user] patching vectors - some are not patched

[Ken Mankoff]

On 2018-11-19 at 16:59 +0100, Markus Metz  wrote:

> looking at your aim: get basins for all outlets, you could also use
> 1. r.stream.extract with stream_vector as output
> outlets have category value 2 in layer 2
> 2. extract the outlets with v.extract lyer=2 type=point cats=2
> 3. use the outlets as input for r.stream.basins

Yes this is my main aim, but as usual things are getting more complicated.

It turns out I cannot use r.watershed over sub-regions (even if I overlap and 
then crop) because it produced bad output due to catchments meeting the edge of 
regions. So I'm going back to r.terraflow.

r.terraflow means I don't have access to the stream maps that you're suggesting 
I use. I also have "direction" in a different format than all the other tools 
want, but I can convert it. I'm not sure what to do about the interior basins 
that r.terraflow leaves unlike r.watershed which fills them... I think I'll run 
all my 'r.water.outlets', generate my raster basins, then flood each basin so 
that the interior basins are now included.

All this is complicated by the fact that I'm working with a 4.5 billion cell 
raster (90,000 x 50,000) with ~100,000 outlets (catchments). I have it running 
fairly fast on my laptop thanks to GNU parallel and WIND_OVERRIDE.

Work is in progress...

  -k.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching vectors - some are not patched

[Markus Metz]

On Mon, Nov 19, 2018 at 4:52 PM Ken Mankoff  wrote:
>
> Hi Martin,
>
> On 2018-11-19 at 16:32 +0100, Markus Metz 
wrote:
> >> On 2018-11-19 at 08:26 +0100, Ken Mankoff  wrote:
> >>
> >> r.mapcalc "basin = if(basin, ${count}, null())" --o
> >> r.to.vect -v input=basin output=b type=area --o
> >> v.patch -a input=b output=basin --o
> >> v.clean in=basin out=basin_clean0 tool=break,rmdupl --o
> >> v.clean in=basin_clean0 out=basin_clean1 tool=snap,break,rmdupl --o
> >
> > you can also clean the patched vector with
> >
> > v.clean tool=bpol,rmdupl,break,rmdupl -c
> >
> > it could be a bit faster
>
> If found it faster and easier to not work in vector space. I now write
out the raster with 'r.out.xyz raster=basin >> basin.txt" (I'm actually
doing this with GNU parallel with one basin and one file per CPU core).
Then I can read concat and read in everything as a raster. Finally,
converting the single raster to a vector seems to work better than
accumulating all the individual vectors.

looking at your aim: get basins for all outlets, you could also use
1. r.stream.extract with stream_vector as output
outlets have category value 2 in layer 2
2. extract the outlets with v.extract lyer=2 type=point cats=2
3. use the outlets as input for r.stream.basins

Markus M

>
> Thanks,
>
>   -k.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching vectors - some are not patched

[Ken Mankoff]

Hi Martin,

On 2018-11-19 at 16:32 +0100, Markus Metz  wrote:
>> On 2018-11-19 at 08:26 +0100, Ken Mankoff  wrote:
>>
>> r.mapcalc "basin = if(basin, ${count}, null())" --o
>> r.to.vect -v input=basin output=b type=area --o
>> v.patch -a input=b output=basin --o
>> v.clean in=basin out=basin_clean0 tool=break,rmdupl --o
>> v.clean in=basin_clean0 out=basin_clean1 tool=snap,break,rmdupl --o
>
> you can also clean the patched vector with
>
> v.clean tool=bpol,rmdupl,break,rmdupl -c
>
> it could be a bit faster

If found it faster and easier to not work in vector space. I now write out the 
raster with 'r.out.xyz raster=basin >> basin.txt" (I'm actually doing this with 
GNU parallel with one basin and one file per CPU core). Then I can read concat 
and read in everything as a raster. Finally, converting the single raster to a 
vector seems to work better than accumulating all the individual vectors.

Thanks,

  -k.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching vectors - some are not patched

[Markus Metz]

On Mon, Nov 19, 2018 at 12:20 PM Ken Mankoff  wrote:
>
> Hi List,
>
> On 2018-11-19 at 08:26 +0100, Ken Mankoff  wrote:
> > I'm having trouble getting v.patch to patch some vectors. I've tested
> > this on Linux grass 7.4.0 (default Ubuntu 18.04 version) and SVN trunk
> > from this evening.
>
> It appears I can get the patched vectors to work by using v.clean. In
this way, the "basin" vector accumulates the "b" vectors generated from the
"basin" raster.
>
> r.mapcalc "basin = if(basin, ${count}, null())" --o
> r.to.vect -v input=basin output=b type=area --o
> v.patch -a input=b output=basin --o
> v.clean in=basin out=basin_clean0 tool=break,rmdupl --o
> v.clean in=basin_clean0 out=basin_clean1 tool=snap,break,rmdupl --o

you can also clean the patched vector with

v.clean tool=bpol,rmdupl,break,rmdupl -c

it could be a bit faster

Markus M

> g.rename vector=basin_clean1,basin --o
>
>   -k.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching vectors - some are not patched

[Ken Mankoff]

Hi List,

On 2018-11-19 at 08:26 +0100, Ken Mankoff  wrote:
> I'm having trouble getting v.patch to patch some vectors. I've tested
> this on Linux grass 7.4.0 (default Ubuntu 18.04 version) and SVN trunk
> from this evening.

It appears I can get the patched vectors to work by using v.clean. In this way, 
the "basin" vector accumulates the "b" vectors generated from the "basin" 
raster.

r.mapcalc "basin = if(basin, ${count}, null())" --o
r.to.vect -v input=basin output=b type=area --o
v.patch -a input=b output=basin --o
v.clean in=basin out=basin_clean0 tool=break,rmdupl --o
v.clean in=basin_clean0 out=basin_clean1 tool=snap,break,rmdupl --o
g.rename vector=basin_clean1,basin --o

  -k.

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Patching rasters based on other rasters

[Ken Mankoff]

Thanks. That helps. I now use the output of that (SZA_lut) and the
following:

r.mapcalc --o < wrote:

>
>
> Le 17 octobre 2017 13:38:34 GMT+02:00, Ken Mankoff  a
> écrit :
> >Dear GRASS List,
> >
> >I'm trying to do something in GRASS and can't figure out an efficient
> >way to do it. I'm guessing it is possible with 1-3 lines, but don't
> >know which ones. The algorithm I'm developing would be much more
> >complex, and I hope someone can suggest a shortcut.
> >
> >I have several satellite products of the same region each day. For
> >simplicity sake lets assume 3 overlapping solar zenith angle (SZA)
> >products, and for each of those a visual image (VIS). I'd like to have
> >one visual raster that, for each pixel, has the minimum SZA.
> >
> >I can get the minimum SZA for each pixel with
> >
> >r.mapcalc "SZA_min = min(SZA1,SZA2,SZA3)"
> >
> >But now I've lost the source of the minimum SZA, and I need it to link
> >SZA1 with VIS1.
> >
> >I could encode categories for each SZA:
> >r.category map=SZA1 cats=0-360 values=1
> >r.category map=SZA2 cats=0-360 values=2
> >r.category map=SZA3 cats=0-360 values=3
> >
> >And then
> >
> >r.mapcalc "SZA_min_cat = min(@SZA1,@SZA2,@SZA3)"
> >
> >And then use SZA_min_cat (values: 1 to 3) as a lookup to
> >VIS1,VIS2,VIS3. I'm actually not clear how to do this last step, if
> >this is the correct approach. Do I return to r.mapcalc, or is r.univar
> >the right tool?
> >
> >Any help will be much appreciated.
>
> Check r.series, notably the min_raster method.
>
> Moritz
>
>
> >
> >Thanks,
> >
> >  -k.
> >
> >___
> >grass-user mailing list
> >grass-user@lists.osgeo.org
> >https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Patching rasters based on other rasters

[Moritz Lennert]

Le 17 octobre 2017 13:38:34 GMT+02:00, Ken Mankoff  a écrit :
>Dear GRASS List,
>
>I'm trying to do something in GRASS and can't figure out an efficient
>way to do it. I'm guessing it is possible with 1-3 lines, but don't
>know which ones. The algorithm I'm developing would be much more
>complex, and I hope someone can suggest a shortcut.
>
>I have several satellite products of the same region each day. For
>simplicity sake lets assume 3 overlapping solar zenith angle (SZA)
>products, and for each of those a visual image (VIS). I'd like to have
>one visual raster that, for each pixel, has the minimum SZA.
>
>I can get the minimum SZA for each pixel with
>
>r.mapcalc "SZA_min = min(SZA1,SZA2,SZA3)"
>
>But now I've lost the source of the minimum SZA, and I need it to link
>SZA1 with VIS1. 
>
>I could encode categories for each SZA:
>r.category map=SZA1 cats=0-360 values=1
>r.category map=SZA2 cats=0-360 values=2
>r.category map=SZA3 cats=0-360 values=3
>
>And then 
>
>r.mapcalc "SZA_min_cat = min(@SZA1,@SZA2,@SZA3)"
>
>And then use SZA_min_cat (values: 1 to 3) as a lookup to
>VIS1,VIS2,VIS3. I'm actually not clear how to do this last step, if
>this is the correct approach. Do I return to r.mapcalc, or is r.univar
>the right tool? 
>
>Any help will be much appreciated.

Check r.series, notably the min_raster method.

Moritz


>
>Thanks,
>
>  -k.
>  
>___
>grass-user mailing list
>grass-user@lists.osgeo.org
>https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Patching rasters based on other rasters

[Ken Mankoff]

Dear GRASS List,

I'm trying to do something in GRASS and can't figure out an efficient way to do 
it. I'm guessing it is possible with 1-3 lines, but don't know which ones. The 
algorithm I'm developing would be much more complex, and I hope someone can 
suggest a shortcut.

I have several satellite products of the same region each day. For simplicity 
sake lets assume 3 overlapping solar zenith angle (SZA) products, and for each 
of those a visual image (VIS). I'd like to have one visual raster that, for 
each pixel, has the minimum SZA.

I can get the minimum SZA for each pixel with

r.mapcalc "SZA_min = min(SZA1,SZA2,SZA3)"

But now I've lost the source of the minimum SZA, and I need it to link SZA1 
with VIS1. 

I could encode categories for each SZA:
r.category map=SZA1 cats=0-360 values=1
r.category map=SZA2 cats=0-360 values=2
r.category map=SZA3 cats=0-360 values=3

And then 

r.mapcalc "SZA_min_cat = min(@SZA1,@SZA2,@SZA3)"

And then use SZA_min_cat (values: 1 to 3) as a lookup to VIS1,VIS2,VIS3. I'm 
actually not clear how to do this last step, if this is the correct approach. 
Do I return to r.mapcalc, or is r.univar the right tool? 

Any help will be much appreciated.

Thanks,

  -k.
  
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching maps together

[Tim Southern]

Dear All,

I am trying to patch together a number of 1 km by 1 km tiles of a map whose 
values are either 0 or 1 (black on white background).

If I use r.patch to put 2 tiles together is appears to work fine but if however 
I try and patch more, even if it is two tiles of already patched tiles I get 
one set when patched as black background and white features and the other part 
as white background and black features.  It appears that the second in the case 
of already patched data or third and subsequent in case of more than 2 tiles is 
inverted with 1 becoming 0 and 0 becoming 1.

I have tried reducing region to the smallest.  Maps are at 0.2m resolution.  I 
am hoping to get a 5 tile by 5 tile block

I have tried this across two different platforms (Mac OS and OpenSuse ) on the 
latest downloadable binary versions of GRASS.

Am I doing something wrong?

Kind regards

Tim
Tim Southern

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching maps together

[Nick Ves]

Hey Tim,

If your maps don't overlap with each other you could use r.series in your case :

$ g.region rast=$(g.mlist rast sep=,)

$ r.series input=$(g.mlist rast sep=,) out=myMap method=sum

N

On Mon, May 19, 2014 at 11:31 AM, Tim Southern
tim.south...@talktalk.net wrote:
 Dear All,

 I am trying to patch together a number of 1 km by 1 km tiles of a map whose 
 values are either 0 or 1 (black on white background).

 If I use r.patch to put 2 tiles together is appears to work fine but if 
 however I try and patch more, even if it is two tiles of already patched 
 tiles I get one set when patched as black background and white features and 
 the other part as white background and black features.  It appears that the 
 second in the case of already patched data or third and subsequent in case of 
 more than 2 tiles is inverted with 1 becoming 0 and 0 becoming 1.

 I have tried reducing region to the smallest.  Maps are at 0.2m resolution.  
 I am hoping to get a 5 tile by 5 tile block

 I have tried this across two different platforms (Mac OS and OpenSuse ) on 
 the latest downloadable binary versions of GRASS.

 Am I doing something wrong?

 Kind regards

 Tim
 Tim Southern

 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Patching Maps

[Tim Southern]

Dear Nick and Hamish,

Thanks, when I used the query raster over the individual maps for both black 
and white most gave coordinates plus a 0 or 1, some however gave an * for 
value.  I suspect that even though all the tiles were from the same source and 
processed in the same way some of the .tif files have ended up as greyscale 
images.

I have now run ImageMagick convert -monochrome and will reload the tiles and 
check.

If I still have problems I will come back to the list.

Kind regards

Tim
Tim Southern
17, Park Close,
Sonning Common,
Oxfordshire
RG4 9RY



On 19 May 2014, at 20:00, grass-user-requ...@lists.osgeo.org wrote:

 Send grass-user mailing list submissions to
   grass-user@lists.osgeo.org
 
 To subscribe or unsubscribe via the World Wide Web, visit
   http://lists.osgeo.org/mailman/listinfo/grass-user
 or, via email, send a message with subject or body 'help' to
   grass-user-requ...@lists.osgeo.org
 
 You can reach the person managing the list at
   grass-user-ow...@lists.osgeo.org
 
 When replying, please edit your Subject line so it is more specific
 than Re: Contents of grass-user digest...
 
 
 Today's Topics:
 
   1. Re: patching maps together (Nick Ves)
   2. Re: patching maps together (Hamish)
   3. Re: GRASS and Blender (G. Allegri)
   4. GRASS 7.0beta2 (Jon Eiriksson)
 
 
 --
 
 Message: 1
 Date: Mon, 19 May 2014 12:39:23 +0300
 From: Nick Ves vesni...@gmail.com
 To: Tim Southern tim.south...@talktalk.net
 Cc: Grass Users grass-user@lists.osgeo.org
 Subject: Re: [GRASS-user] patching maps together
 Message-ID:
   cadccpvto6tuc4m_5uemzg-mc6psgvc6brupyx8tchvcvvg_...@mail.gmail.com
 Content-Type: text/plain; charset=UTF-8
 
 Hey Tim,
 
 If your maps don't overlap with each other you could use r.series in your 
 case :
 
 $ g.region rast=$(g.mlist rast sep=,)
 
 $ r.series input=$(g.mlist rast sep=,) out=myMap method=sum
 
 N
 
 On Mon, May 19, 2014 at 11:31 AM, Tim Southern
 tim.south...@talktalk.net wrote:
 Dear All,
 
 I am trying to patch together a number of 1 km by 1 km tiles of a map whose 
 values are either 0 or 1 (black on white background).
 
 If I use r.patch to put 2 tiles together is appears to work fine but if 
 however I try and patch more, even if it is two tiles of already patched 
 tiles I get one set when patched as black background and white features and 
 the other part as white background and black features.  It appears that the 
 second in the case of already patched data or third and subsequent in case 
 of more than 2 tiles is inverted with 1 becoming 0 and 0 becoming 1.
 
 I have tried reducing region to the smallest.  Maps are at 0.2m resolution.  
 I am hoping to get a 5 tile by 5 tile block
 
 I have tried this across two different platforms (Mac OS and OpenSuse ) on 
 the latest downloadable binary versions of GRASS.
 
 Am I doing something wrong?
 
 Kind regards
 
 Tim
 Tim Southern
 
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user
 
 
 --
 
 Message: 2
 Date: Tue, 20 May 2014 00:05:36 +1200
 From: Hamish hamish.webm...@gmail.com
 To: Tim Southern tim.south...@talktalk.net
 Cc: grass-user@lists.osgeo.org
 Subject: Re: [GRASS-user] patching maps together
 Message-ID: 2014052536.25baa063189ea1fd178f4...@gmail.com
 Content-Type: text/plain; charset=US-ASCII
 
 Tim wrote:
 I am trying to patch together a number of 1 km by 1 km tiles of a map
 whose values are either 0 or 1 (black on white background).
 
 If I use r.patch to put 2 tiles together is appears to work fine but
 if however I try and patch more, even if it is two tiles of already
 patched tiles I get one set when patched as black background and
 white features and the other part as white background and black
 features.  It appears that the second in the case of already patched
 data or third and subsequent in case of more than 2 tiles is inverted
 with 1 becoming 0 and 0 becoming 1.
 
 I have tried reducing region to the smallest.  Maps are at 0.2m
 resolution.  I am hoping to get a 5 tile by 5 tile block
 
 I have tried this across two different platforms (Mac OS and OpenSuse
 ) on the latest downloadable binary versions of GRASS.
 
 Am I doing something wrong?
 
 
 I suspect that the images are paletted, and the color palettes differ
 between the images. After confirming that you might run the images
 through a bulk color palette - 24bit RGB filter. (I'm not sure what the
 right NetPBM or ImageMagick command is, but I'm sure there is one)
 
 after that, gdalbuildvrt is wonderful for import + patch in one step.
 
 
 good luck,
 
 -- 
 Hamish hamish.webm...@gmail.com
 
 
 --
 
 Message: 3
 Date: Mon, 19 May 2014 16:21:55 +0200
 From: G. Allegri gioha...@gmail.com
 To: Vincent Bain b...@toraval.fr
 Cc: GRASS user list grass-user@lists.osgeo.org

[GRASS-user] patching

[Bulent Arikan]

Dear List,

I have several ASTER GDEM (originally Latlong) images that I want to
reinterpolate from 30 to 10 m res. I also need to patch these images. I am
not sure whether:

 - I should patch them in Latlong using r.series, reproject into UTM and
interpolate them using r.resamp.rst or

 - reproject images individually into UTM, interpolate individually using
r.resamp.rst and then patch them using r.series.

So far, I tried the second option. After cubic reprojection and
interpolation to 10m the tiles have little borders of NULL areas when I
display them together. They don't go away when patched.

I will appreciate any advice
Thanks.
-- 
BÜLENT ARIKAN, PhD
School of Human Evolution and Social Change
Arizona State University
Tempe - AZ
85287-2402
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching dems together

[Hamish]

stephen wrote:
 r.info

 any ideas,

{
 g.region rast=yourmap
   +
 r.univar yourmap
 d.histogram yourmap
}

are other useful ways to see if there is really any data in the map,
even if the color map (r.colors) has somehow gone completely out of range
and 0-100% is all set to a single color.

unlike r.info which looks at the metadata, r.univar and r.stats etc look
at the current computational region, resampling if need be; reporting
all NULLs if the map is not in the current zoom.


Hamish



  

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] patching dems together

[stephen sefick]

r.patch this gives me single color when the original dems where
reliefs (there is topography).  What am I doing wrong?  I have set the
n-s e-w resolution to 00:00:03 because I downloaded 1/3 arc second dem
from the seamless server (.adf).  I am confused as to what to do next.
 Is r.patch the wrong thing to be doing?
thanks in advance

-- 
Stephen Sefick

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods.  We are mammals, and have not exhausted the
annoying little problems of being mammals.

-K. Mullis
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching dems together

[Nikos Alexandris]

On Thu, 2009-07-09 at 11:17 -0500, stephen sefick wrote:
 r.patch this gives me single color when the original dems where
 reliefs (there is topography).  What am I doing wrong?  I have set the
 n-s e-w resolution to 00:00:03 because I downloaded 1/3 arc second dem
 from the seamless server (.adf).  I am confused as to what to do next.
  Is r.patch the wrong thing to be doing?
 thanks in advance

some ideas:

* check range of values with r.info YourDEMtile(s) -tr before patching

* set g.region rast=`g.mlist rast=PatternThatMatchesDEMtiles sep=,`
res=WantedResolution

* r.patch input=... out=patchedDEM

* check range again r.info -tr patchedDEM

* r.colors patchedDEM color=terrain

* d.rast

Somewhere in between you should find the problem if there is any.
Kind regards, Nikos

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching dems together

[Moritz Lennert]

On 09/07/09 18:17, stephen sefick wrote:

r.patch this gives me single color when the original dems where
reliefs (there is topography).  What am I doing wrong?  I have set the
n-s e-w resolution to 00:00:03 because I downloaded 1/3 arc second dem
from the seamless server (.adf).  I am confused as to what to do next.
 Is r.patch the wrong thing to be doing?


Try r.colors for setting a new color table (e.g. elevation).

Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching dems together

[stephen sefick]

values range from ~-9 to ~800 there is a tile which has no elevation.
The patched dem only ranges from 0-296.  This may be the problem.

On Thu, Jul 9, 2009 at 11:27 AM, Moritz
Lennertmlenn...@club.worldonline.be wrote:
 On 09/07/09 18:17, stephen sefick wrote:

 r.patch this gives me single color when the original dems where
 reliefs (there is topography).  What am I doing wrong?  I have set the
 n-s e-w resolution to 00:00:03 because I downloaded 1/3 arc second dem
 from the seamless server (.adf).  I am confused as to what to do next.
  Is r.patch the wrong thing to be doing?

 Try r.colors for setting a new color table (e.g. elevation).

 Moritz




-- 
Stephen Sefick

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods.  We are mammals, and have not exhausted the
annoying little problems of being mammals.

-K. Mullis
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching dems together

[Markus Metz]

stephen sefick wrote:
 values range from ~-9 to ~800 there is a tile which has no elevation.
 The patched dem only ranges from 0-296.  This may be the problem.
   
It seems that the current computational region did not include all tiles.
Try setting the computational region to include all tiles with g.region
rast=all your tiles.
Check the resolution of each tile with r.info -s. If they are not all
the same, use the coarsest resolution to be safe.
Check the resolution of the computational region. It must be the same
like the coarsest resolution, if not, set it to that.
Set the same color rules for all tiles. Use srtm or etopo2 but not
elevation because elevation will be different for each tile.
Display all tiles, zoom to the computational region.
Patch all tiles.
Set the same color rules to the patched DEM like to the tiles.
Add the patched DEM to the display, it should look like the previous
display with all the tiles.

Good luck,

Markus M

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching dems together

[stephen sefick]

I followed the directions all set to srtm, computation region set to
resolution of the coarsest (they are all the same and 00:00:01).  The
map is still coming out as 7 different solid color blocks.

On Thu, Jul 9, 2009 at 12:58 PM, Markus
Metzmarkus.metz.gisw...@googlemail.com wrote:
 stephen sefick wrote:
 values range from ~-9 to ~800 there is a tile which has no elevation.
 The patched dem only ranges from 0-296.  This may be the problem.

 It seems that the current computational region did not include all tiles.
 Try setting the computational region to include all tiles with g.region
 rast=all your tiles.
 Check the resolution of each tile with r.info -s. If they are not all
 the same, use the coarsest resolution to be safe.
 Check the resolution of the computational region. It must be the same
 like the coarsest resolution, if not, set it to that.
 Set the same color rules for all tiles. Use srtm or etopo2 but not
 elevation because elevation will be different for each tile.
 Display all tiles, zoom to the computational region.
 Patch all tiles.
 Set the same color rules to the patched DEM like to the tiles.
 Add the patched DEM to the display, it should look like the previous
 display with all the tiles.

 Good luck,

 Markus M





-- 
Stephen Sefick

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods.  We are mammals, and have not exhausted the
annoying little problems of being mammals.

-K. Mullis
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching dems together

[Markus Metz]

stephen sefick wrote:
 I followed the directions all set to srtm, computation region set to
 resolution of the coarsest (they are all the same and 00:00:01).  The
 map is still coming out as 7 different solid color blocks.
   
You have set the region to include all tiles? You have zoomed to the
current region? The patched DEM still ranges from 0-296 only and not
from 9-800 (r.info -r)?

I've done that regularly with SRTM tiles and it worked, no problems
(6.4.0RC5).
 On Thu, Jul 9, 2009 at 12:58 PM, Markus
 Metzmarkus.metz.gisw...@googlemail.com wrote:
   
 stephen sefick wrote:
 
 values range from ~-9 to ~800 there is a tile which has no elevation.
 The patched dem only ranges from 0-296.  This may be the problem.

   
 It seems that the current computational region did not include all tiles.
 Try setting the computational region to include all tiles with g.region
 rast=all your tiles.
 Check the resolution of each tile with r.info -s. If they are not all
 the same, use the coarsest resolution to be safe.
 Check the resolution of the computational region. It must be the same
 like the coarsest resolution, if not, set it to that.
 Set the same color rules for all tiles. Use srtm or etopo2 but not
 elevation because elevation will be different for each tile.
 Display all tiles, zoom to the computational region.
 Patch all tiles.
 Set the same color rules to the patched DEM like to the tiles.
 Add the patched DEM to the display, it should look like the previous
 display with all the tiles.

 Good luck,

 Markus M


 



   

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching dems together

[stephen sefick]

yes still 0-296.  I think the problem is this

r.info -s series_map
nsres=1:09:25.8
ewres=1:01:15.8736

however:
g.region -p
projection: 3 (Latitude-Longitude)
zone:   0
datum:  nad83
ellipsoid:  grs80
north:  34:23:38.97N
south:  30:23:31.96N
west:   84:31:21.9W
east:   79:25:00.89W
nsres:  0:00:01
ewres:  0:00:01
rows:   14407
cols:   18381
cells:  264815067

any ideas,

Stephen


On Thu, Jul 9, 2009 at 1:50 PM, Markus
Metzmarkus.metz.gisw...@googlemail.com wrote:
 stephen sefick wrote:
 I followed the directions all set to srtm, computation region set to
 resolution of the coarsest (they are all the same and 00:00:01).  The
 map is still coming out as 7 different solid color blocks.

 You have set the region to include all tiles? You have zoomed to the
 current region? The patched DEM still ranges from 0-296 only and not
 from 9-800 (r.info -r)?

 I've done that regularly with SRTM tiles and it worked, no problems
 (6.4.0RC5).
 On Thu, Jul 9, 2009 at 12:58 PM, Markus
 Metzmarkus.metz.gisw...@googlemail.com wrote:

 stephen sefick wrote:

 values range from ~-9 to ~800 there is a tile which has no elevation.
 The patched dem only ranges from 0-296.  This may be the problem.


 It seems that the current computational region did not include all tiles.
 Try setting the computational region to include all tiles with g.region
 rast=all your tiles.
 Check the resolution of each tile with r.info -s. If they are not all
 the same, use the coarsest resolution to be safe.
 Check the resolution of the computational region. It must be the same
 like the coarsest resolution, if not, set it to that.
 Set the same color rules for all tiles. Use srtm or etopo2 but not
 elevation because elevation will be different for each tile.
 Display all tiles, zoom to the computational region.
 Patch all tiles.
 Set the same color rules to the patched DEM like to the tiles.
 Add the patched DEM to the display, it should look like the previous
 display with all the tiles.

 Good luck,

 Markus M












-- 
Stephen Sefick

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods.  We are mammals, and have not exhausted the
annoying little problems of being mammals.

-K. Mullis
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching dems together

[Markus Metz]

stephen sefick wrote:
 yes still 0-296.  I think the problem is this

 r.info -s series_map
 nsres=1:09:25.8
 ewres=1:01:15.8736

 however:
 g.region -p
 projection: 3 (Latitude-Longitude)
 zone:   0
 datum:  nad83
 ellipsoid:  grs80
 north:  34:23:38.97N
 south:  30:23:31.96N
 west:   84:31:21.9W
 east:   79:25:00.89W
 nsres:  0:00:01
 ewres:  0:00:01
 rows:   14407
 cols:   18381
 cells:  264815067
   
Hmm, doesn't make sense if you have set this region before patching. I
guess now you must post the exact commands you used in the exact order
you used them, plus grass version and operating system (wasn't it 3.0 on
Linux?).

Markus M

 any ideas,

 Stephen


 On Thu, Jul 9, 2009 at 1:50 PM, Markus
 Metzmarkus.metz.gisw...@googlemail.com wrote:
   
 stephen sefick wrote:
 
 I followed the directions all set to srtm, computation region set to
 resolution of the coarsest (they are all the same and 00:00:01).  The
 map is still coming out as 7 different solid color blocks.

   
 You have set the region to include all tiles? You have zoomed to the
 current region? The patched DEM still ranges from 0-296 only and not
 from 9-800 (r.info -r)?

 I've done that regularly with SRTM tiles and it worked, no problems
 (6.4.0RC5).
 
 On Thu, Jul 9, 2009 at 12:58 PM, Markus
 Metzmarkus.metz.gisw...@googlemail.com wrote:

   
 stephen sefick wrote:

 
 values range from ~-9 to ~800 there is a tile which has no elevation.
 The patched dem only ranges from 0-296.  This may be the problem.


   
 It seems that the current computational region did not include all tiles.
 Try setting the computational region to include all tiles with g.region
 rast=all your tiles.
 Check the resolution of each tile with r.info -s. If they are not all
 the same, use the coarsest resolution to be safe.
 Check the resolution of the computational region. It must be the same
 like the coarsest resolution, if not, set it to that.
 Set the same color rules for all tiles. Use srtm or etopo2 but not
 elevation because elevation will be different for each tile.
 Display all tiles, zoom to the computational region.
 Patch all tiles.
 Set the same color rules to the patched DEM like to the tiles.
 Add the patched DEM to the display, it should look like the previous
 display with all the tiles.

 Good luck,

 Markus M



 


   
 



   

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching dems together

[stephen sefick]

Markus,
I made a Permanent Map set and put in everything from the projection
region, and followed your directions.  They worked.  I have created
the map, and I am now reprojecting it into another mapset so that I
can use v.strahler to calculate stream orders.  Thank you so much for
your help.  As it is most of the time- I think it was operator error.
Sorry, for the headache.

Stephen Sefick

On Thu, Jul 9, 2009 at 2:55 PM, Markus
Metzmarkus.metz.gisw...@googlemail.com wrote:
 stephen sefick wrote:
 yes still 0-296.  I think the problem is this

 r.info -s series_map
 nsres=1:09:25.8
 ewres=1:01:15.8736

 however:
 g.region -p
 projection: 3 (Latitude-Longitude)
 zone:       0
 datum:      nad83
 ellipsoid:  grs80
 north:      34:23:38.97N
 south:      30:23:31.96N
 west:       84:31:21.9W
 east:       79:25:00.89W
 nsres:      0:00:01
 ewres:      0:00:01
 rows:       14407
 cols:       18381
 cells:      264815067

 Hmm, doesn't make sense if you have set this region before patching. I
 guess now you must post the exact commands you used in the exact order
 you used them, plus grass version and operating system (wasn't it 3.0 on
 Linux?).

 Markus M

 any ideas,

 Stephen


 On Thu, Jul 9, 2009 at 1:50 PM, Markus
 Metzmarkus.metz.gisw...@googlemail.com wrote:

 stephen sefick wrote:

 I followed the directions all set to srtm, computation region set to
 resolution of the coarsest (they are all the same and 00:00:01).  The
 map is still coming out as 7 different solid color blocks.


 You have set the region to include all tiles? You have zoomed to the
 current region? The patched DEM still ranges from 0-296 only and not
 from 9-800 (r.info -r)?

 I've done that regularly with SRTM tiles and it worked, no problems
 (6.4.0RC5).

 On Thu, Jul 9, 2009 at 12:58 PM, Markus
 Metzmarkus.metz.gisw...@googlemail.com wrote:


 stephen sefick wrote:


 values range from ~-9 to ~800 there is a tile which has no elevation.
 The patched dem only ranges from 0-296.  This may be the problem.



 It seems that the current computational region did not include all tiles.
 Try setting the computational region to include all tiles with g.region
 rast=all your tiles.
 Check the resolution of each tile with r.info -s. If they are not all
 the same, use the coarsest resolution to be safe.
 Check the resolution of the computational region. It must be the same
 like the coarsest resolution, if not, set it to that.
 Set the same color rules for all tiles. Use srtm or etopo2 but not
 elevation because elevation will be different for each tile.
 Display all tiles, zoom to the computational region.
 Patch all tiles.
 Set the same color rules to the patched DEM like to the tiles.
 Add the patched DEM to the display, it should look like the previous
 display with all the tiles.

 Good luck,

 Markus M

















-- 
Stephen Sefick

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods.  We are mammals, and have not exhausted the
annoying little problems of being mammals.

-K. Mullis
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching images from different UTM zones (without shell script?)

[Renae Mackas]

Thanks-

I had originally been having trouble trying to extend the regions beyond the 
end of the zone because when I used g.region with -p flag, the nesw borders 
were given for each zone specifically, and I understood it that there were 
overlapping borders between zones 16,17, and 18.  When I viewed the rasters in 
the map display however, I could just find the values of the appropriate 
extended borders by looking at the coordinates by vy the location of the cursor.

Thanks for the tips,

Renae


You can try using the -n flag for r.proj to avoid region clipping or  
you can extend your region beyond the edges of the zone.

On 1-Apr-09, at 4:10 PM, Renae Mackas wrote:


 Hello GRASS users-

 I am trying to create a mosaic of LANDSAT taken of Eastern Hudson  
 Bay area using GRASS 6.3.0.  I have run into the problem though that  
 some of these images are from different UTM zones (16, 17, and 18).   
 Currently, I have been able to import images from the three UTM  
 zones into 3 different locations.  What I want to do is bring in the  
 images from zones 16 and 18 (currently imported into different  
 locations), and patch them with images from zone 17.  I have tried  
 re-projecting these images into the location for zone 17 using  
 r.proj, but when I do this, it cuts off parts of the images which  
 are not within zone 17.

 I have looked at previous posts on the forum, and have found some  
 advice (moving raster maps across UTM zone boundaries).  I have  
 never used shell script and am very new to GRASS, so the advice  
 given in this response is somewhat complex for me.  Are there any  
 suggestions of how best to mosaic images from different zones  
 without using shell script?

 Thanks in advance for any help,

 Renae Mackas

 -- 
 View this message in context: 
 http://n2.nabble.com/patching-images-from-different-UTM-zones-%28without-shell-script-%29-tp2571892p2571892.html
 Sent from the Grass - Users mailing list archive at Nabble.com.

 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user



-- 
View this message in context: 
http://n2.nabble.com/patching-images-from-different-UTM-zones-%28without-shell-script-%29-tp2571892p2590427.html
Sent from the Grass - Users mailing list archive at Nabble.com.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] patching images from different UTM zones (without shell script?)

[Renae Mackas]

Hello GRASS users-

I am trying to create a mosaic of LANDSAT taken of Eastern Hudson Bay area 
using GRASS 6.3.0.  I have run into the problem though that some of these 
images are from different UTM zones (16, 17, and 18).  Currently, I have been 
able to import images from the three UTM zones into 3 different locations.  
What I want to do is bring in the images from zones 16 and 18 (currently 
imported into different locations), and patch them with images from zone 17.  I 
have tried re-projecting these images into the location for zone 17 using 
r.proj, but when I do this, it cuts off parts of the images which are not 
within zone 17.

I have looked at previous posts on the forum, and have found some advice 
(moving raster maps across UTM zone boundaries).  I have never used shell 
script and am very new to GRASS, so the advice given in this response is 
somewhat complex for me.  Are there any suggestions of how best to mosaic 
images from different zones without using shell script?

Thanks in advance for any help,

Renae Mackas

-- 
View this message in context: 
http://n2.nabble.com/patching-images-from-different-UTM-zones-%28without-shell-script-%29-tp2571892p2571892.html
Sent from the Grass - Users mailing list archive at Nabble.com.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] patching images from different UTM zones (without shell script?)

[Michael Perdue]

You can try using the -n flag for r.proj to avoid region clipping or  
you can extend your region beyond the edges of the zone.


On 1-Apr-09, at 4:10 PM, Renae Mackas wrote:



Hello GRASS users-

I am trying to create a mosaic of LANDSAT taken of Eastern Hudson  
Bay area using GRASS 6.3.0.  I have run into the problem though that  
some of these images are from different UTM zones (16, 17, and 18).   
Currently, I have been able to import images from the three UTM  
zones into 3 different locations.  What I want to do is bring in the  
images from zones 16 and 18 (currently imported into different  
locations), and patch them with images from zone 17.  I have tried  
re-projecting these images into the location for zone 17 using  
r.proj, but when I do this, it cuts off parts of the images which  
are not within zone 17.


I have looked at previous posts on the forum, and have found some  
advice (moving raster maps across UTM zone boundaries).  I have  
never used shell script and am very new to GRASS, so the advice  
given in this response is somewhat complex for me.  Are there any  
suggestions of how best to mosaic images from different zones  
without using shell script?


Thanks in advance for any help,

Renae Mackas

--
View this message in context: 
http://n2.nabble.com/patching-images-from-different-UTM-zones-%28without-shell-script-%29-tp2571892p2571892.html
Sent from the Grass - Users mailing list archive at Nabble.com.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Patching large numbers of vectors

[Markus Neteler]

Richard,

without error messages it's hard to understand...
Could you run it in command line? Then you may be able to
copy the error.

Alternative: tell us how to replicate it in the Spearfish or North
Carolina sample data set...

Markus

On Thu, Oct 23, 2008 at 11:49 PM, Richard Chirgwin
[EMAIL PROTECTED] wrote:
 Hi,

 There seems to be a problem in handling of large numbers of vectors.

 I had a large number of buffered points to put together. The buffer
 areas (with centroids added) were constrained by non-overlapping areas
 to avoid errors later, after which I wanted to patch them together into
 a single file. I used:

 for i in `g.mlist vect pattern=Centroids*`; do
 v.patch -a -e input=$i output=patchfile --overwrite;
 done

 to do this.

 For most vectors, everything works fine, but every now and again, the
 patching process would report a problem (something like error bug sidx
 topo, it goes by in a flash and I haven't been able to work out how to
 log the script outputs) with an individual vector. If, however, I
 patched the vector manually (outside the script), it would work fine.

 I suspect that because of the speed and huge number of vectors I'm
 trying to put together, v.patch is having trouble finding the sidx file,
 but really, I have no idea. Any thoughts?

 Richard Chirgwin

 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user




-- 
Open Source Geospatial Foundation
http://www.osgeo.org/
http://www.grassbook.org/
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Patching large numbers of vectors

[Richard Chirgwin]

Markus Neteler wrote:
 Richard,

 without error messages it's hard to understand...
 Could you run it in command line? Then you may be able to
 copy the error.

 Alternative: tell us how to replicate it in the Spearfish or North
 Carolina sample data set...
   
Markus,

The error:
ERROR: BUG (Vect_build_sidx_from_topo): area does not exist

Thanks for suggesting I try it in Spearfish; it made the string of
errors more manageable to search through.

Reproduced in Spearfish like this.

1) Create individual points
for i in `echo select cat from bugsites | db.select`; do
v.extract input=$i output=bugsites_$i where=cat=$i; done

2) Buffer individual points
for i in `g.mlist vect pattern=bugsites_*`; do
v.buffer input=$i output=buffer_$i buffer=500; done

3) Add tables to buffers
for i in `g.mlist vect pattern=buffer_*`; do
v.db.addtable map=$i; done

4) Overlay buffers with areas
for i in `g.mlist vect pattern=buffer_*; do
v.overlay ainput=$i binput=trn_sites output=overlay_$i operator=and;
done

5) Create target patch map
for i in `g.mlist vect pattern=overlay_*`; do
v.patch -a -e input=$i output=patch --overwrite; done

During the patch phase, this gets reported from time to time:
ERROR: BUG (Vect_build_sidx_from_topo): area does not exist

I can rebuild the file manually and the patch will work. However, the
error will even occur if I insert the build into the script:
for i in `g.mlist vect pattern=overlay_*`; DO
v.build $i;
v.patch -a -e input=$i output=patch --overwrite; done

Thoughts?

RC

(By the way; why the labourious process? - I have a set of thousands of
points associated with areas, and want to constrain buffers using the
areas. If I just buffer the entire point file, I get lots of overlaps
that make things painful. I want to constrain the circles before
patching them together back into a single file.
I have tried other approaches -
- buffer all the points in one map with debug=buffer
- v.clean the resulting map
- add centroids
But I end up with incorrect boundaries that miss getting their centroids.)

 Markus

 On Thu, Oct 23, 2008 at 11:49 PM, Richard Chirgwin
 [EMAIL PROTECTED] wrote:
   
 Hi,

 There seems to be a problem in handling of large numbers of vectors.

 I had a large number of buffered points to put together. The buffer
 areas (with centroids added) were constrained by non-overlapping areas
 to avoid errors later, after which I wanted to patch them together into
 a single file. I used:

 for i in `g.mlist vect pattern=Centroids*`; do
 v.patch -a -e input=$i output=patchfile --overwrite;
 done

 to do this.

 For most vectors, everything works fine, but every now and again, the
 patching process would report a problem (something like error bug sidx
 topo, it goes by in a flash and I haven't been able to work out how to
 log the script outputs) with an individual vector. If, however, I
 patched the vector manually (outside the script), it would work fine.

 I suspect that because of the speed and huge number of vectors I'm
 trying to put together, v.patch is having trouble finding the sidx file,
 but really, I have no idea. Any thoughts?

 Richard Chirgwin

 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

 



   

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Patching large numbers of vectors

[Richard Chirgwin]

Hi,

There seems to be a problem in handling of large numbers of vectors.

I had a large number of buffered points to put together. The buffer
areas (with centroids added) were constrained by non-overlapping areas
to avoid errors later, after which I wanted to patch them together into
a single file. I used:

for i in `g.mlist vect pattern=Centroids*`; do
v.patch -a -e input=$i output=patchfile --overwrite;
done

to do this.

For most vectors, everything works fine, but every now and again, the
patching process would report a problem (something like error bug sidx
topo, it goes by in a flash and I haven't been able to work out how to
log the script outputs) with an individual vector. If, however, I
patched the vector manually (outside the script), it would work fine.

I suspect that because of the speed and huge number of vectors I'm
trying to put together, v.patch is having trouble finding the sidx file,
but really, I have no idea. Any thoughts?

Richard Chirgwin

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] patching dem at different resolution

[Silvia Simoni]

Hi grass users,

I have 4 dem, 2 are 1x1 m resolution and 2 are 2x2 m a resolution;  I  
'd like to have just one global dem 2x2 m resolution.
If I import the data with their native resolution then I set the  
region to the total area with a resolution of 2x2 (g.region -a res=2  
rast=dem1, dem2, dem3, dem4) and run r.patch, do I get consistent  
results? Would I get more precise results if I resampled the 1x1dem to  
2x2 before running r.patch?


thanks

silvia

Silvia Simoni PhD
DICA - Department of Civil and Environmental Engineering
Universita' di Trento
via Mesiano 77, 38100 Trento, ITALY
tel. +39 0461 882610
fax. +39 0461 882672
e-mail: [EMAIL PROTECTED]



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Patching raster maps produced by r.reclass

[Jana K.]

I have 2 raster maps in the same papset. I needed to complement the null
values in the first map with values from the second. I used r.patch
input=map1,map2 output=map3. The resulting map3, however, is an empty map.
Can the fact that map1 and map2 resulted from r.reclass procedures (the
original map on which reclass is based still exists) by the cause? 

Thanks,

Jana
-- 
View this message in context: 
http://www.nabble.com/Patching-raster-maps-produced-by-r.reclass-tp18402197p18402197.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user