[GRASS-user] r.patch for stitching rasters?

GRASS GRASS user
1

Hello grass (ab)users!
I am using r.patch to merge 200 1 degree, 3 seconds resolution srtm's
(1-2 Mb each). After 24 hours of real time and 20 hours of Xeon
processor time I have 39% completed! My guess that this task shouldn't
take so long. Is r.patch a wrong tool to do this thing? Or is it a
bug? I am using grass-6.3.cvs.

Thanks,
Boris

2

On Friday 16 November 2007, Boris Avdeev wrote:

Hello grass (ab)users!
I am using r.patch to merge 200 1 degree, 3 seconds resolution srtm's
(1-2 Mb each). After 24 hours of real time and 20 hours of Xeon
processor time I have 39% completed! My guess that this task shouldn't
take so long. Is r.patch a wrong tool to do this thing? Or is it a
bug? I am using grass-6.3.cvs.

Thanks,
Boris

check region extents and resolution ... can you send the output from
g.region -p ?

Dylan

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

3

Now, when you asking...
Now it is this:

projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 48:50:24.701676N
south: 34:38:56.353164N
west: 45:57:00.735336E
east: 55:00:56.276712E
nsres: 0:01:00.033312
ewres: 0:00:59.991804
rows: 851
cols: 544
cells: 462944

But I believe that at the time I started r.patch it was this:

projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 46N
south: 35N
west: 35E
east: 55E
nsres: 0:00:03
ewres: 0:00:03
rows: 13200
cols: 24000
cells: 316800000

since I was trying to preserve resolution of original srtms.

Boris

PS Sorry Dylan

On Nov 16, 2007 12:49 PM, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:

On Friday 16 November 2007, Boris Avdeev wrote:
> Hello grass (ab)users!
> I am using r.patch to merge 200 1 degree, 3 seconds resolution srtm's
> (1-2 Mb each). After 24 hours of real time and 20 hours of Xeon
> processor time I have 39% completed! My guess that this task shouldn't
> take so long. Is r.patch a wrong tool to do this thing? Or is it a
> bug? I am using grass-6.3.cvs.
>
> Thanks,
> Boris

check region extents and resolution ... can you send the output from
g.region -p ?

Dylan

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

4

On Friday 16 November 2007, Boris Avdeev wrote:

Now, when you asking...
Now it is this:

projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 48:50:24.701676N
south: 34:38:56.353164N
west: 45:57:00.735336E
east: 55:00:56.276712E
nsres: 0:01:00.033312
ewres: 0:00:59.991804
rows: 851
cols: 544
cells: 462944

But I believe that at the time I started r.patch it was this:

projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 46N
south: 35N
west: 35E
east: 55E
nsres: 0:00:03
ewres: 0:00:03
rows: 13200
cols: 24000
cells: 316800000

since I was trying to preserve resolution of original srtms.

Boris

That is pretty big, but not impossibly big. Have you considered something like
gdal_merge.py for merging the files outside of GRASS ?

cheers,

Dylan

PS Sorry Dylan

On Nov 16, 2007 12:49 PM, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:
> On Friday 16 November 2007, Boris Avdeev wrote:
> > Hello grass (ab)users!
> > I am using r.patch to merge 200 1 degree, 3 seconds resolution srtm's
> > (1-2 Mb each). After 24 hours of real time and 20 hours of Xeon
> > processor time I have 39% completed! My guess that this task shouldn't
> > take so long. Is r.patch a wrong tool to do this thing? Or is it a
> > bug? I am using grass-6.3.cvs.
> >
> > Thanks,
> > Boris
>
> check region extents and resolution ... can you send the output from
> g.region -p ?
>
> Dylan
>
>
> --
> Dylan Beaudette
> Soil Resource Laboratory
> http://casoilresource.lawr.ucdavis.edu/
> University of California at Davis
> 530.754.7341

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

5

Yes, though I couldn't figure out how to make gdal_merge output NULLs
instead of 0s (and what formats support NULLs?).
But anyway, you think that this is normal performance?

On Nov 16, 2007 2:08 PM, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:

On Friday 16 November 2007, Boris Avdeev wrote:

> Now, when you asking...
> Now it is this:
>
> projection: 3 (Latitude-Longitude)
> zone: 0
> datum: wgs84
> ellipsoid: wgs84
> north: 48:50:24.701676N
> south: 34:38:56.353164N
> west: 45:57:00.735336E
> east: 55:00:56.276712E
> nsres: 0:01:00.033312
> ewres: 0:00:59.991804
> rows: 851
> cols: 544
> cells: 462944
>
> But I believe that at the time I started r.patch it was this:
>
> projection: 3 (Latitude-Longitude)
> zone: 0
> datum: wgs84
> ellipsoid: wgs84
> north: 46N
> south: 35N
> west: 35E
> east: 55E
> nsres: 0:00:03
> ewres: 0:00:03
> rows: 13200
> cols: 24000
> cells: 316800000
>
> since I was trying to preserve resolution of original srtms.
>
> Boris
>

That is pretty big, but not impossibly big. Have you considered something like
gdal_merge.py for merging the files outside of GRASS ?

cheers,

Dylan

>
> PS Sorry Dylan
>
> On Nov 16, 2007 12:49 PM, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:
> > On Friday 16 November 2007, Boris Avdeev wrote:
> > > Hello grass (ab)users!
> > > I am using r.patch to merge 200 1 degree, 3 seconds resolution srtm's
> > > (1-2 Mb each). After 24 hours of real time and 20 hours of Xeon
> > > processor time I have 39% completed! My guess that this task shouldn't
> > > take so long. Is r.patch a wrong tool to do this thing? Or is it a
> > > bug? I am using grass-6.3.cvs.
> > >
> > > Thanks,
> > > Boris
> >
> > check region extents and resolution ... can you send the output from
> > g.region -p ?
> >
> > Dylan
> >
> >
> > --
> > Dylan Beaudette
> > Soil Resource Laboratory
> > http://casoilresource.lawr.ucdavis.edu/
> > University of California at Davis
> > 530.754.7341

--

Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

6

Boris:

I am using r.patch to merge 200 1 degree, 3 seconds resolution srtm's
(1-2 Mb each). After 24 hours of real time and 20 hours of Xeon
processor time I have 39% completed! My guess that this task shouldn't
take so long. Is r.patch a wrong tool to do this thing? Or is it a
bug? I am using grass-6.3.cvs.

Dylan:

g.region -p ?

Boris:

rows: 13200
cols: 24000
cells: 316800000

Dylan:

That is pretty big, but not impossibly big. Have you considered
something like gdal_merge.py for merging the files outside of GRASS ?

splitting that into four or eight smaller tiles would make it more manageable,
but as Dylan says that isn't impossibly big, perhaps even on the high side
of common. For really huge regions (> 50000^2) you might start thinking about
using 64bit processors and if GRASS and the OS were compiled with large file
support.

Given the number of maps and size of the region, I'm not surprised it
could take x*y*maps times longer than normal.

Boris:

since I was trying to preserve resolution of original srtms.

hint 1: use g.region with multiple maps to set the region to the outer
bounds of all maps. For you with so many maps that could take a while,
so probably maps at the four corners would be enough.
  g.region rast=map1,map2,map3,map4

hint 2: a low number of columns can be more important to speed than low
number of rows when doing things like displaying maps.

suggestion: wait 48 hours for it to finish then see if it is too big
to work with before deciding to split it up into smaller tiles.
Also it could be a lot faster to make 4 or 8 smaller tiles then r.patch
those together in a second pass. (ie reduce the module's search time
through known empty space)

Hamish

      ____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

7

Boris Avdeev wrote:

Yes, though I couldn't figure out how to make gdal_merge output NULLs
instead of 0s (and what formats support NULLs?).

does it have any options like:

  [-srcnodata "value [value...]"] [-dstnodata "value [value...]"]

?

Hamish

      ____________________________________________________________________________________
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

8

Well, you assuming that NULL=0, but the sole reason for having NULL
layer in grass is that those values are not identical.

Boris

On Nov 16, 2007 5:55 PM, Charles Ehlschlaeger
<c.ehlschlaeger@insightbb.com> wrote:

> I couldn't figure out how to make gdal_merge output NULLs
> instead of 0s (and what formats support NULLs?).

r.mapcalc can easily convert your 0s into NULLS with the expression:

newmap = if(map == 0, null(), map)

r.mapcalc will solve most raster problems. GRASS users are advised to know
that program inside and out.

Sincerely, chuck

Chuck Ehlschlaeger, Associate Professor of Geography
Western Illinois University
215 Tillman Hall, 1 University Circle, Macomb, IL 61455
cre111@wiu.edu, phone: 309-298-1841, fax: 309-298-3003

-----Original Message-----
From: grass-user-bounces@lists.osgeo.org
[mailto:grass-user-bounces@lists.osgeo.org] On Behalf Of Boris Avdeev
Sent: Friday, November 16, 2007 1:11 PM
To: dylan.beaudette@gmail.com
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] r.patch for stitching rasters?

Yes, though I couldn't figure out how to make gdal_merge output NULLs
instead of 0s (and what formats support NULLs?).
But anyway, you think that this is normal performance?

On Nov 16, 2007 2:08 PM, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:
> On Friday 16 November 2007, Boris Avdeev wrote:
>
> > Now, when you asking...
> > Now it is this:
> >
> > projection: 3 (Latitude-Longitude)
> > zone: 0
> > datum: wgs84
> > ellipsoid: wgs84
> > north: 48:50:24.701676N
> > south: 34:38:56.353164N
> > west: 45:57:00.735336E
> > east: 55:00:56.276712E
> > nsres: 0:01:00.033312
> > ewres: 0:00:59.991804
> > rows: 851
> > cols: 544
> > cells: 462944
> >
> > But I believe that at the time I started r.patch it was this:
> >
> > projection: 3 (Latitude-Longitude)
> > zone: 0
> > datum: wgs84
> > ellipsoid: wgs84
> > north: 46N
> > south: 35N
> > west: 35E
> > east: 55E
> > nsres: 0:00:03
> > ewres: 0:00:03
> > rows: 13200
> > cols: 24000
> > cells: 316800000
> >
> > since I was trying to preserve resolution of original srtms.
> >
> > Boris
> >
>
> That is pretty big, but not impossibly big. Have you considered something
like
> gdal_merge.py for merging the files outside of GRASS ?
>
> cheers,
>
> Dylan
>
>
> >
> > PS Sorry Dylan
> >
> > On Nov 16, 2007 12:49 PM, Dylan Beaudette <dylan.beaudette@gmail.com>
wrote:
> > > On Friday 16 November 2007, Boris Avdeev wrote:
> > > > Hello grass (ab)users!
> > > > I am using r.patch to merge 200 1 degree, 3 seconds resolution
srtm's
> > > > (1-2 Mb each). After 24 hours of real time and 20 hours of Xeon
> > > > processor time I have 39% completed! My guess that this task
shouldn't
> > > > take so long. Is r.patch a wrong tool to do this thing? Or is it a
> > > > bug? I am using grass-6.3.cvs.
> > > >
> > > > Thanks,
> > > > Boris
> > >
> > > check region extents and resolution ... can you send the output from
> > > g.region -p ?
> > >
> > > Dylan
> > >
> > >
> > > --
> > > Dylan Beaudette
> > > Soil Resource Laboratory
> > > http://casoilresource.lawr.ucdavis.edu/
> > > University of California at Davis
> > > 530.754.7341
>
>
>
> --
>
> Dylan Beaudette
> Soil Resource Laboratory
> http://casoilresource.lawr.ucdavis.edu/
> University of California at Davis
> 530.754.7341
>
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.15.33/1133 - Release Date: 11/15/2007
8:57 PM

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.15.33/1133 - Release Date: 11/15/2007
8:57 PM

9

Hi Boris,

Went back to a large file which was created with r.patch, which had
the following region settings:

Data Type: DCELL
Rows: 30912
Columns: 20239
Total Cells: 625627968

If I recall, this took about 20 minutes to complete on a Xeon 3.2 Ghz
machine, running Debian Linux, with 1 Gb RAM.

Cheers,

Dylan

On 11/17/07, Boris Avdeev <borisaqua@gmail.com> wrote:

Well, you assuming that NULL=0, but the sole reason for having NULL
layer in grass is that those values are not identical.

Boris

On Nov 16, 2007 5:55 PM, Charles Ehlschlaeger
<c.ehlschlaeger@insightbb.com> wrote:
> > I couldn't figure out how to make gdal_merge output NULLs
> > instead of 0s (and what formats support NULLs?).
>
> r.mapcalc can easily convert your 0s into NULLS with the expression:
>
> newmap = if(map == 0, null(), map)
>
> r.mapcalc will solve most raster problems. GRASS users are advised to know
> that program inside and out.
>
> Sincerely, chuck
>
> Chuck Ehlschlaeger, Associate Professor of Geography
> Western Illinois University
> 215 Tillman Hall, 1 University Circle, Macomb, IL 61455
> cre111@wiu.edu, phone: 309-298-1841, fax: 309-298-3003
>
>
> -----Original Message-----
> From: grass-user-bounces@lists.osgeo.org
> [mailto:grass-user-bounces@lists.osgeo.org] On Behalf Of Boris Avdeev
> Sent: Friday, November 16, 2007 1:11 PM
> To: dylan.beaudette@gmail.com
> Cc: grass-user@lists.osgeo.org
> Subject: Re: [GRASS-user] r.patch for stitching rasters?
>
> Yes, though I couldn't figure out how to make gdal_merge output NULLs
> instead of 0s (and what formats support NULLs?).
> But anyway, you think that this is normal performance?
>
> On Nov 16, 2007 2:08 PM, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:
> > On Friday 16 November 2007, Boris Avdeev wrote:
> >
> > > Now, when you asking...
> > > Now it is this:
> > >
> > > projection: 3 (Latitude-Longitude)
> > > zone: 0
> > > datum: wgs84
> > > ellipsoid: wgs84
> > > north: 48:50:24.701676N
> > > south: 34:38:56.353164N
> > > west: 45:57:00.735336E
> > > east: 55:00:56.276712E
> > > nsres: 0:01:00.033312
> > > ewres: 0:00:59.991804
> > > rows: 851
> > > cols: 544
> > > cells: 462944
> > >
> > > But I believe that at the time I started r.patch it was this:
> > >
> > > projection: 3 (Latitude-Longitude)
> > > zone: 0
> > > datum: wgs84
> > > ellipsoid: wgs84
> > > north: 46N
> > > south: 35N
> > > west: 35E
> > > east: 55E
> > > nsres: 0:00:03
> > > ewres: 0:00:03
> > > rows: 13200
> > > cols: 24000
> > > cells: 316800000
> > >
> > > since I was trying to preserve resolution of original srtms.
> > >
> > > Boris
> > >
> >
> > That is pretty big, but not impossibly big. Have you considered something
> like
> > gdal_merge.py for merging the files outside of GRASS ?
> >
> > cheers,
> >
> > Dylan
> >
> >
> > >
> > > PS Sorry Dylan
> > >
> > > On Nov 16, 2007 12:49 PM, Dylan Beaudette <dylan.beaudette@gmail.com>
> wrote:
> > > > On Friday 16 November 2007, Boris Avdeev wrote:
> > > > > Hello grass (ab)users!
> > > > > I am using r.patch to merge 200 1 degree, 3 seconds resolution
> srtm's
> > > > > (1-2 Mb each). After 24 hours of real time and 20 hours of Xeon
> > > > > processor time I have 39% completed! My guess that this task
> shouldn't
> > > > > take so long. Is r.patch a wrong tool to do this thing? Or is it a
> > > > > bug? I am using grass-6.3.cvs.
> > > > >
> > > > > Thanks,
> > > > > Boris
> > > >
> > > > check region extents and resolution ... can you send the output from
> > > > g.region -p ?
> > > >
> > > > Dylan
> > > >
> > > >
> > > > --
> > > > Dylan Beaudette
> > > > Soil Resource Laboratory
> > > > http://casoilresource.lawr.ucdavis.edu/
> > > > University of California at Davis
> > > > 530.754.7341
> >
> >
> >
> > --
> >
> > Dylan Beaudette
> > Soil Resource Laboratory
> > http://casoilresource.lawr.ucdavis.edu/
> > University of California at Davis
> > 530.754.7341
> >
> _______________________________________________
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.15.33/1133 - Release Date: 11/15/2007
> 8:57 PM
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.15.33/1133 - Release Date: 11/15/2007
> 8:57 PM
>
>
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

10

This is interesting. How many input files did you have?

On Nov 17, 2007 2:39 PM, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:

Hi Boris,

Went back to a large file which was created with r.patch, which had
the following region settings:

Data Type: DCELL
Rows: 30912
Columns: 20239
Total Cells: 625627968

If I recall, this took about 20 minutes to complete on a Xeon 3.2 Ghz
machine, running Debian Linux, with 1 Gb RAM.

Cheers,

Dylan

On 11/17/07, Boris Avdeev <borisaqua@gmail.com> wrote:
> Well, you assuming that NULL=0, but the sole reason for having NULL
> layer in grass is that those values are not identical.
>
> Boris
>
> On Nov 16, 2007 5:55 PM, Charles Ehlschlaeger
> <c.ehlschlaeger@insightbb.com> wrote:
> > > I couldn't figure out how to make gdal_merge output NULLs
> > > instead of 0s (and what formats support NULLs?).
> >
> > r.mapcalc can easily convert your 0s into NULLS with the expression:
> >
> > newmap = if(map == 0, null(), map)
> >
> > r.mapcalc will solve most raster problems. GRASS users are advised to know
> > that program inside and out.
> >
> > Sincerely, chuck
> >
> > Chuck Ehlschlaeger, Associate Professor of Geography
> > Western Illinois University
> > 215 Tillman Hall, 1 University Circle, Macomb, IL 61455
> > cre111@wiu.edu, phone: 309-298-1841, fax: 309-298-3003
> >
> >
> > -----Original Message-----
> > From: grass-user-bounces@lists.osgeo.org
> > [mailto:grass-user-bounces@lists.osgeo.org] On Behalf Of Boris Avdeev
> > Sent: Friday, November 16, 2007 1:11 PM
> > To: dylan.beaudette@gmail.com
> > Cc: grass-user@lists.osgeo.org
> > Subject: Re: [GRASS-user] r.patch for stitching rasters?
> >
> > Yes, though I couldn't figure out how to make gdal_merge output NULLs
> > instead of 0s (and what formats support NULLs?).
> > But anyway, you think that this is normal performance?
> >
> > On Nov 16, 2007 2:08 PM, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:
> > > On Friday 16 November 2007, Boris Avdeev wrote:
> > >
> > > > Now, when you asking...
> > > > Now it is this:
> > > >
> > > > projection: 3 (Latitude-Longitude)
> > > > zone: 0
> > > > datum: wgs84
> > > > ellipsoid: wgs84
> > > > north: 48:50:24.701676N
> > > > south: 34:38:56.353164N
> > > > west: 45:57:00.735336E
> > > > east: 55:00:56.276712E
> > > > nsres: 0:01:00.033312
> > > > ewres: 0:00:59.991804
> > > > rows: 851
> > > > cols: 544
> > > > cells: 462944
> > > >
> > > > But I believe that at the time I started r.patch it was this:
> > > >
> > > > projection: 3 (Latitude-Longitude)
> > > > zone: 0
> > > > datum: wgs84
> > > > ellipsoid: wgs84
> > > > north: 46N
> > > > south: 35N
> > > > west: 35E
> > > > east: 55E
> > > > nsres: 0:00:03
> > > > ewres: 0:00:03
> > > > rows: 13200
> > > > cols: 24000
> > > > cells: 316800000
> > > >
> > > > since I was trying to preserve resolution of original srtms.
> > > >
> > > > Boris
> > > >
> > >
> > > That is pretty big, but not impossibly big. Have you considered something
> > like
> > > gdal_merge.py for merging the files outside of GRASS ?
> > >
> > > cheers,
> > >
> > > Dylan
> > >
> > >
> > > >
> > > > PS Sorry Dylan
> > > >
> > > > On Nov 16, 2007 12:49 PM, Dylan Beaudette <dylan.beaudette@gmail.com>
> > wrote:
> > > > > On Friday 16 November 2007, Boris Avdeev wrote:
> > > > > > Hello grass (ab)users!
> > > > > > I am using r.patch to merge 200 1 degree, 3 seconds resolution
> > srtm's
> > > > > > (1-2 Mb each). After 24 hours of real time and 20 hours of Xeon
> > > > > > processor time I have 39% completed! My guess that this task
> > shouldn't
> > > > > > take so long. Is r.patch a wrong tool to do this thing? Or is it a
> > > > > > bug? I am using grass-6.3.cvs.
> > > > > >
> > > > > > Thanks,
> > > > > > Boris
> > > > >
> > > > > check region extents and resolution ... can you send the output from
> > > > > g.region -p ?
> > > > >
> > > > > Dylan
> > > > >
> > > > >
> > > > > --
> > > > > Dylan Beaudette
> > > > > Soil Resource Laboratory
> > > > > http://casoilresource.lawr.ucdavis.edu/
> > > > > University of California at Davis
> > > > > 530.754.7341
> > >
> > >
> > >
> > > --
> > >
> > > Dylan Beaudette
> > > Soil Resource Laboratory
> > > http://casoilresource.lawr.ucdavis.edu/
> > > University of California at Davis
> > > 530.754.7341
> > >
> > _______________________________________________
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-user
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.503 / Virus Database: 269.15.33/1133 - Release Date: 11/15/2007
> > 8:57 PM
> >
> >
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.5.503 / Virus Database: 269.15.33/1133 - Release Date: 11/15/2007
> > 8:57 PM
> >
> >
> _______________________________________________
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>

11

I was stitching together Landsat data for the state of AZ, so about 20.

Dylan

On 11/17/07, Boris Avdeev <borisaqua@gmail.com> wrote:

This is interesting. How many input files did you have?

On Nov 17, 2007 2:39 PM, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:
> Hi Boris,
>
> Went back to a large file which was created with r.patch, which had
> the following region settings:
>
> Data Type: DCELL
> Rows: 30912
> Columns: 20239
> Total Cells: 625627968
>
> If I recall, this took about 20 minutes to complete on a Xeon 3.2 Ghz
> machine, running Debian Linux, with 1 Gb RAM.
>
> Cheers,
>
> Dylan
>
>
>
> On 11/17/07, Boris Avdeev <borisaqua@gmail.com> wrote:
> > Well, you assuming that NULL=0, but the sole reason for having NULL
> > layer in grass is that those values are not identical.
> >
> > Boris
> >
> > On Nov 16, 2007 5:55 PM, Charles Ehlschlaeger
> > <c.ehlschlaeger@insightbb.com> wrote:
> > > > I couldn't figure out how to make gdal_merge output NULLs
> > > > instead of 0s (and what formats support NULLs?).
> > >
> > > r.mapcalc can easily convert your 0s into NULLS with the expression:
> > >
> > > newmap = if(map == 0, null(), map)
> > >
> > > r.mapcalc will solve most raster problems. GRASS users are advised to know
> > > that program inside and out.
> > >
> > > Sincerely, chuck
> > >
> > > Chuck Ehlschlaeger, Associate Professor of Geography
> > > Western Illinois University
> > > 215 Tillman Hall, 1 University Circle, Macomb, IL 61455
> > > cre111@wiu.edu, phone: 309-298-1841, fax: 309-298-3003
> > >
> > >
> > > -----Original Message-----
> > > From: grass-user-bounces@lists.osgeo.org
> > > [mailto:grass-user-bounces@lists.osgeo.org] On Behalf Of Boris Avdeev
> > > Sent: Friday, November 16, 2007 1:11 PM
> > > To: dylan.beaudette@gmail.com
> > > Cc: grass-user@lists.osgeo.org
> > > Subject: Re: [GRASS-user] r.patch for stitching rasters?
> > >
> > > Yes, though I couldn't figure out how to make gdal_merge output NULLs
> > > instead of 0s (and what formats support NULLs?).
> > > But anyway, you think that this is normal performance?
> > >
> > > On Nov 16, 2007 2:08 PM, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:
> > > > On Friday 16 November 2007, Boris Avdeev wrote:
> > > >
> > > > > Now, when you asking...
> > > > > Now it is this:
> > > > >
> > > > > projection: 3 (Latitude-Longitude)
> > > > > zone: 0
> > > > > datum: wgs84
> > > > > ellipsoid: wgs84
> > > > > north: 48:50:24.701676N
> > > > > south: 34:38:56.353164N
> > > > > west: 45:57:00.735336E
> > > > > east: 55:00:56.276712E
> > > > > nsres: 0:01:00.033312
> > > > > ewres: 0:00:59.991804
> > > > > rows: 851
> > > > > cols: 544
> > > > > cells: 462944
> > > > >
> > > > > But I believe that at the time I started r.patch it was this:
> > > > >
> > > > > projection: 3 (Latitude-Longitude)
> > > > > zone: 0
> > > > > datum: wgs84
> > > > > ellipsoid: wgs84
> > > > > north: 46N
> > > > > south: 35N
> > > > > west: 35E
> > > > > east: 55E
> > > > > nsres: 0:00:03
> > > > > ewres: 0:00:03
> > > > > rows: 13200
> > > > > cols: 24000
> > > > > cells: 316800000
> > > > >
> > > > > since I was trying to preserve resolution of original srtms.
> > > > >
> > > > > Boris
> > > > >
> > > >
> > > > That is pretty big, but not impossibly big. Have you considered something
> > > like
> > > > gdal_merge.py for merging the files outside of GRASS ?
> > > >
> > > > cheers,
> > > >
> > > > Dylan
> > > >
> > > >
> > > > >
> > > > > PS Sorry Dylan
> > > > >
> > > > > On Nov 16, 2007 12:49 PM, Dylan Beaudette <dylan.beaudette@gmail.com>
> > > wrote:
> > > > > > On Friday 16 November 2007, Boris Avdeev wrote:
> > > > > > > Hello grass (ab)users!
> > > > > > > I am using r.patch to merge 200 1 degree, 3 seconds resolution
> > > srtm's
> > > > > > > (1-2 Mb each). After 24 hours of real time and 20 hours of Xeon
> > > > > > > processor time I have 39% completed! My guess that this task
> > > shouldn't
> > > > > > > take so long. Is r.patch a wrong tool to do this thing? Or is it a
> > > > > > > bug? I am using grass-6.3.cvs.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Boris
> > > > > >
> > > > > > check region extents and resolution ... can you send the output from
> > > > > > g.region -p ?
> > > > > >
> > > > > > Dylan
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Dylan Beaudette
> > > > > > Soil Resource Laboratory
> > > > > > http://casoilresource.lawr.ucdavis.edu/
> > > > > > University of California at Davis
> > > > > > 530.754.7341
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Dylan Beaudette
> > > > Soil Resource Laboratory
> > > > http://casoilresource.lawr.ucdavis.edu/
> > > > University of California at Davis
> > > > 530.754.7341
> > > >
> > > _______________________________________________
> > > grass-user mailing list
> > > grass-user@lists.osgeo.org
> > > http://lists.osgeo.org/mailman/listinfo/grass-user
> > >
> > > No virus found in this incoming message.
> > > Checked by AVG Free Edition.
> > > Version: 7.5.503 / Virus Database: 269.15.33/1133 - Release Date: 11/15/2007
> > > 8:57 PM
> > >
> > >
> > > No virus found in this outgoing message.
> > > Checked by AVG Free Edition.
> > > Version: 7.5.503 / Virus Database: 269.15.33/1133 - Release Date: 11/15/2007
> > > 8:57 PM
> > >
> > >
> > _______________________________________________
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-user
> >
>

12

Charles:

> > I couldn't figure out how to make gdal_merge output NULLs
> > instead of 0s (and what formats support NULLs?).
>
> r.mapcalc can easily convert your 0s into NULLS with the expression:
>
> newmap = if(map == 0, null(), map)

another way is:
r.null map=yourmap setnull=0

> r.mapcalc will solve most raster problems. GRASS users are advised to know
> that program inside and out.

agreed.

Boris Avdeev wrote:

Well, you assuming that NULL=0, but the sole reason for having NULL
layer in grass is that those values are not identical.

true, the data is lost when NULL is mixed with 0 in the first place, not when
changing 0->NULL.

Hamish

      ____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

13

It does, but what formats support actual null layers? Of course I
might be able to find an unused rgb value and use it instead of NULL.
But what do you do if you don't have one?

Boris

On Nov 16, 2007 6:19 PM, Hamish <hamish_nospam@yahoo.com> wrote:

Boris Avdeev wrote:
> Yes, though I couldn't figure out how to make gdal_merge output NULLs
> instead of 0s (and what formats support NULLs?).

does it have any options like:

  [-srcnodata "value [value...]"] [-dstnodata "value [value...]"]

?

Hamish

      ____________________________________________________________________________________
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ