[GRASS-dev] limits of r.patch

GRASS GIS GRASS GIS developer
1

Hi All,

I probably am requiring too much, but this is just for sharing an experience. I’ve just imported in GRASS 1573 ASTER GDEM tiles, using r.external, and everything seemed to be OK. Then I ran:

GRASS 6.4.3svn (ASTER_GDEM):~ > r.patch in=g.mlist pat=AST* sep=, out=aster_gdem
ERROR 1: TIFFOpen:/forest/ASTER-GDEM/Dem_lzw/ASTGTM_N45E010_dem_lzw.tif: Too many open files
WARNING: Unable to open raster map ASTGTM_N45E011_dem_lzw.tif@PERMANENT
ERROR: One or more input raster maps not found

I’m on Red Hat Enterprise Linux Server Rel. 6.3, RAM 16 GB.

Cheers,

–
Dr. Margherita Di Leo

2

2012/7/13 Margherita Di Leo <dileomargherita@gmail.com>:

Hi All,

hi madi

I probably am requiring too much, but this is just for sharing an
experience. I've just imported in GRASS 1573 ASTER GDEM tiles, using
r.external, and everything seemed to be OK. Then I ran:

GRASS 6.4.3svn (ASTER_GDEM):~ > r.patch in=`g.mlist pat=AST* sep=,`
out=aster_gdem
ERROR 1: TIFFOpen:/forest/ASTER-GDEM/Dem_lzw/ASTGTM_N45E010_dem_lzw.tif: Too
many open files
WARNING: Unable to open raster map <ASTGTM_N45E011_dem_lzw.tif@PERMANENT>
ERROR: One or more input raster maps not found

I'm on Red Hat Enterprise Linux Server Rel. 6.3, RAM 16 GB.

I think it's a limit of linux, you could patch images in more tiles
and after patch the tiles in a file

Cheers,

--
Dr. Margherita Di Leo

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

3

Margherita,
You may be running into the open file limit for linux. http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/, although 1573 files seems a bit low. I generally batch my r.patch’ing in groups of 120 or so with a python script , then go back and r.patch the results. It works well if the file names are related to the file locations.

See ugly python script below where elevation grid data with the "temp_"grid tiles were named by the x coordinate were patched together ( yes, I know you can do this better now with direct python calls to grass:-)):

grass_tile_merge.py

import os,string,re,glob
grdarr=[‘D2370’,‘D2371’,‘d2371’,‘d2372’,‘D2372’,‘D2373’]

for grdarrlist in grdarr:
gtarr=[‘0’,‘1’,‘2’,‘3’,‘4’,‘5’,‘6’,‘7’,‘8’,‘9’]
for gtarrl in gtarr:
gtarrb=[‘0’,‘1’,‘2’,‘3’,‘4’,‘5’,‘6’,‘7’,‘8’,‘9’]
for gtarrl2 in gtarrb:
gtarrc=[‘0’,‘1’,‘2’,‘3’,‘4’,‘5’,‘6’,‘7’,‘8’,‘9’]
for gtarrl3 in gtarrc:
grdstr=“”
gtemp=“temp_”+grdarrlist+gtarrl+gtarrl2+gtarrl3
#print grpitem
greplist=“/imagery/grass/ncstpftlidar_83/newdem/fcell/”+grdarrlist+gtarrl+gtarrl2+gtarrl3+“*_ras”
grdlist=glob.glob(greplist) # creates a list of those grid files
for t1 in grdlist:
t1base=os.path.basename(t1)
grdstr=grdstr+t1base+“,”
#grdarr.append(t1base)
grdstr=grdstr[:-1]
print grdstr
regtite=“g.region rast=%s”%(grdstr)
os.system(regtite)
patchgrp=“r.patch input=%s output=%s”%(grdstr,gtemp)
print patchgrp
os.system(patchgrp)
#http://grass.fbk.eu/grass64/manuals/html64_user/r.patch.html

Hope this helps.

Doug

Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov

The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.

Margherita Di Leo <dileomargherita@gmail.com>
Sent by: grass-dev-bounces@lists.osgeo.org

07/13/2012 11:27 AM

To

grass-dev@lists.osgeo.org

cc

Subject

[GRASS-dev] limits of r.patch

Hi All,

I probably am requiring too much, but this is just for sharing an experience. I’ve just imported in GRASS 1573 ASTER GDEM tiles, using r.external, and everything seemed to be OK. Then I ran:

GRASS 6.4.3svn (ASTER_GDEM):~ > r.patch in=g.mlist pat=AST* sep=, out=aster_gdem
ERROR 1: TIFFOpen:/forest/ASTER-GDEM/Dem_lzw/ASTGTM_N45E010_dem_lzw.tif: Too many open files
WARNING: Unable to open raster map ASTGTM_N45E011_dem_lzw.tif@PERMANENT
ERROR: One or more input raster maps not found

I’m on Red Hat Enterprise Linux Server Rel. 6.3, RAM 16 GB.

Cheers,

–
Dr. Margherita Di Leo

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

4

On Fri, Jul 13, 2012 at 5:27 PM, Margherita Di Leo
<dileomargherita@gmail.com> wrote:

Hi All,

I probably am requiring too much, but this is just for sharing an
experience. I've just imported in GRASS 1573 ASTER GDEM tiles, using
r.external, and everything seemed to be OK. Then I ran:

GRASS 6.4.3svn (ASTER_GDEM):~ > r.patch in=`g.mlist pat=AST* sep=,`
out=aster_gdem
ERROR 1: TIFFOpen:/forest/ASTER-GDEM/Dem_lzw/ASTGTM_N45E010_dem_lzw.tif: Too
many open files
WARNING: Unable to open raster map <ASTGTM_N45E011_dem_lzw.tif@PERMANENT>
ERROR: One or more input raster maps not found

I'm on Red Hat Enterprise Linux Server Rel. 6.3, RAM 16 GB.

Linux (and other OSes, likewise) has a limit of opening 1024 files
in parallel.

However, you can enlarge this, see:
http://grass.osgeo.org/gdp/html_grass64/r.series.html
--> "Number of raster maps to be processed is given by the limit of
the operating system."

I used happily 1500 files in the past.

Alternative:
Make the mosaik with gdalwarp and import/register this single file.
Here a simple script, using the GDAL cache to speed up (you'll
need to adapt it):

RES=10.0
BIGTIFF="-co BIGTIFF=YES"
# GDAL cache in megabytes
CACHE="--config GDAL_CACHEMAX 8000 -wm 8000"

LIST="`ls aster*.tif`"

gdalwarp $CACHE $BIGTIFF -srcnodata 65535 -dstnodata 65535 -r bilinear
-tr $RES $RES $LIST mosaik_$RES.tif
gdaladdo mosaik_$RES.tif 2 4 8 16 32

Hope this helps,
Markus

5

hi margherita,

I probably am requiring too much, but this is just for sharing an

experience. I've just imported in GRASS >1573 ASTER GDEM tiles, using
r.external, and everything seemed to be OK. Then I ran:

GRASS 6.4.3svn (ASTER_GDEM):~ > r.patch in=`g.mlist pat=AST* sep=,`

out=aster_gdem

ERROR 1: TIFFOpen:/forest/ASTER-GDEM/Dem_lzw/ASTGTM_N45E010_dem_lzw.tif:

Too many open files

WARNING: Unable to open raster map <ASTGTM_N45E011_dem_lzw.tif@PERMANENT>
ERROR: One or more input raster maps not found

using GDAL Virtual Format [1] by building a virtual dataset by gdalbuildvrt?

it's really a nice gdal utility:

no need to patch all ASTER GDEM tiles within grass, just import the virtual
dataset by r.in.gdal or link it by r.external

[1] http://www.gdal.org/gdal_vrttut.html
[2] http://www.gdal.org/gdalbuildvrt.html

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/limits-of-r-patch-tp4988265p4988454.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

6

Hi,

thank you all for answering,

On Sun, Jul 15, 2012 at 10:11 PM, Markus Neteler <neteler@osgeo.org> wrote:

Alternative:
Make the mosaik with gdalwarp and import/register this single file.
Here a simple script, using the GDAL cache to speed up (you’ll
need to adapt it):

RES=10.0

Markus, in my case resolution is RES=0:00:01, should I use decimal degrees (RES=0.000278 , not sure it is correct) ?

BIGTIFF=“-co BIGTIFF=YES”

GDAL cache in megabytes

CACHE=“–config GDAL_CACHEMAX 8000 -wm 8000”

LIST=“ls aster*.tif”

gdalwarp $CACHE $BIGTIFF -srcnodata 65535 -dstnodata 65535 -r bilinear

-tr $RES $RES $LIST mosaik_$RES.tif
gdaladdo mosaik_$RES.tif 2 4 8 16 32

Hope this helps,
Markus

My steps are the following:

RES=0:00:01

RES=0.000278
BIGTIFF=“-co BIGTIFF=YES”

GDAL cache in megabytes

CACHE=“–config GDAL_CACHEMAX 8000 -wm 8000”

Select from the complete ASTER coverage, the limits for Europe, and put it in a LIST:

LIST="ogr2ogr -f index_dem.shp -spat -11.0001389 33.9998611 43.0001389 72.0001389 "
gdalwarp $CACHE $BIGTIFF -srcnodata * -dstnodata * -r bilinear -tr $RES $RES $LIST mosaik_$RES.tif

But I get:

[leomarg@d01ri1002912 Dem_lzw]$ gdalwarp $CACHE $BIGTIFF -srcnodata * -dstnodata * -r bilinear -tr $RES $RES $LIST mosaik_$RES.tif

Usage: gdalwarp [–help-general] [–formats]
[-s_srs srs_def] [-t_srs srs_def] [-to “NAME=VALUE”]
[-order n] [-tps] [-rpc] [-geoloc] [-et err_threshold]
[-te xmin ymin xmax ymax] [-tr xres yres] [-tap] [-ts width height]
[-wo “NAME=VALUE”] [-ot Byte/Int16/…] [-wt Byte/Int16]
[-srcnodata “value [value…]”] [-dstnodata “value [value…]”] -dstalpha
[-r resampling_method] [-wm memory_in_mb] [-multi] [-q]
[-cutline datasource] [-cl layer] [-cwhere expression]
[-csql statement] [-cblend dist_in_pixels]
[-of format] [-co “NAME=VALUE”]* [-overwrite]
srcfile* dstfile

Available resampling methods:
near (default), bilinear, cubic, cubicspline, lanczos.

where am I wrong?

TIA

–
Dr. Margherita Di Leo

7

On Mon, Jul 16, 2012 at 10:53 AM, Margherita Di Leo
<dileomargherita@gmail.com> wrote:

On Sun, Jul 15, 2012 at 10:11 PM, Markus Neteler <neteler@osgeo.org> wrote:

Markus, in my case resolution is RES=0:00:01, should I use decimal degrees
(RES=0.000278 , not sure it is correct) ?

Likely GDAL only accepts decimal degrees, so yes.

...

# Select from the complete ASTER coverage, the limits for Europe, and put it
in a LIST:
LIST="ogr2ogr -f index_dem.shp -spat -11.0001389 33.9998611 43.0001389
72.0001389 "

.. this I don't understand. $LIST should contain a list of GeoTIFF names.

gdalwarp $CACHE $BIGTIFF -srcnodata * -dstnodata * -r bilinear -tr $RES $RES
$LIST mosaik_$RES.tif

... I am also not sure about the stars there: they will be expanded by
the shell. What did you want to set?

ciao
Markus

8

Ciao,

On Mon, Jul 16, 2012 at 11:08 AM, Markus Neteler <neteler@osgeo.org> wrote:

…

Select from the complete ASTER coverage, the limits for Europe, and put it

in a LIST:
LIST="ogr2ogr -f index_dem.shp -spat -11.0001389 33.9998611 43.0001389
72.0001389 "

… this I don’t understand. $LIST should contain a list of GeoTIFF names.

My aim was to retrieve the names of tiles in the LIST variable instead of storing them in the CSV file produced by:
ogr2ogr -f CSV list.csv index_dem.shp -spat -11.0001389 33.9998611 43.0001389 72.0001389
How should I do it?

gdalwarp $CACHE $BIGTIFF -srcnodata * -dstnodata * -r bilinear -tr $RES $RES
$LIST mosaik_$RES.tif

… I am also not sure about the stars there: they will be expanded by
the shell. What did you want to set?

I meant to set null value to *, now using -9999 instead.

Thanks,

–
Dr. Margherita Di Leo

9

On Mon, Jul 16, 2012 at 11:32 AM, Margherita Di Leo
<dileomargherita@gmail.com> wrote:
...

My aim was to retrieve the names of tiles in the LIST variable instead of
storing them in the CSV file produced by:
ogr2ogr -f CSV list.csv index_dem.shp -spat -11.0001389 33.9998611
43.0001389 72.0001389
How should I do it?

I don't know if it works your way but you need a space separated list
of names in the end...

ciao,
Markus

10

Markus,

On Mon, Jul 16, 2012 at 11:37 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Mon, Jul 16, 2012 at 11:32 AM, Margherita Di Leo
<dileomargherita@gmail.com> wrote:
…

My aim was to retrieve the names of tiles in the LIST variable instead of
storing them in the CSV file produced by:
ogr2ogr -f CSV list.csv index_dem.shp -spat -11.0001389 33.9998611
43.0001389 72.0001389
How should I do it?

I don’t know if it works your way but you need a space separated list
of names in the end…

It doens’t work indeed :slight_smile: So I created a file with a space separated list of names and then (with a little suggestion from Luca) :
LIST=“”
for i in cat /home/leomarg/Desktop/aster/elenco_aster_europa_riga;do LIST=“$LIST $i”; done

Eventually I ran:

gdalwarp $CACHE $BIGTIFF -srcnodata -9999 -dstnodata -9999 -r bilinear -tr $RES $RES $LIST mosaik_$RES.tif

But I got ERROR:

[…]
ERROR 1: Integer overflow : nDstXSize=49460, nDstYSize=70144
Processing input file ASTGTM_N55E011_dem_lzw.tif.
ERROR 1: Integer overflow : nDstXSize=49460, nDstYSize=70144
Processing input file ASTGTM_N55E012_dem_lzw.tif.
ERROR 1: Integer overflow : nDstXSize=49460, nDstYSize=70144
More than 1000 errors or warnings have been reported. No more will be reported from now.

Puzzled…

ciao madi

–
Dr. Margherita Di Leo

11

On Mon, Jul 16, 2012 at 2:42 PM, Margherita Di Leo
<dileomargherita@gmail.com> wrote:

Markus,

On Mon, Jul 16, 2012 at 11:37 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Mon, Jul 16, 2012 at 11:32 AM, Margherita Di Leo
<dileomargherita@gmail.com> wrote:
...
> My aim was to retrieve the names of tiles in the LIST variable instead
> of
> storing them in the CSV file produced by:
> ogr2ogr -f CSV list.csv index_dem.shp -spat -11.0001389 33.9998611
> 43.0001389 72.0001389
> How should I do it?

I don't know if it works your way but you need a space separated list
of names in the end...

It doens't work indeed :slight_smile: So I created a file with a space separated list of
names and then (with a little suggestion from Luca) :
LIST=""
for i in `cat /home/leomarg/Desktop/aster/elenco_aster_europa_riga`;do
LIST="$LIST $i"; done

If you have a "listfile.txt" (whatever name) with
file1
file2
...

just do a one-line :slight_smile:

LIST="`cat listfile.txt | tr '\n' ' '"

Eventually I ran:

gdalwarp $CACHE $BIGTIFF -srcnodata -9999 -dstnodata -9999 -r bilinear -tr
$RES $RES $LIST mosaik_$RES.tif

But I got ERROR:

[....]
ERROR 1: Integer overflow : nDstXSize=49460, nDstYSize=70144
Processing input file ASTGTM_N55E011_dem_lzw.tif.

Your GDAL installation is lacking bigtiff support.

Markus

12

Markus,

On Mon, Jul 16, 2012 at 2:45 PM, Markus Neteler <neteler@osgeo.org> wrote:

If you have a “listfile.txt” (whatever name) with
file1
file2
…

just do a one-line :slight_smile:

LIST=“`cat listfile.txt | tr ‘\n’ ’ '”

Thanks :wink:

Eventually I ran:

gdalwarp $CACHE $BIGTIFF -srcnodata -9999 -dstnodata -9999 -r bilinear -tr
$RES $RES $LIST mosaik_$RES.tif

But I got ERROR:

[…]
ERROR 1: Integer overflow : nDstXSize=49460, nDstYSize=70144
Processing input file ASTGTM_N55E011_dem_lzw.tif.

Your GDAL installation is lacking bigtiff support.

Strange, I just recompiled it with bigtiff support… how can I check if the support is actually active or not?

Thanks!

–
Dr. Margherita Di Leo

13

On Mon, Jul 16, 2012 at 2:59 PM, Margherita Di Leo
<dileomargherita@gmail.com> wrote:
...

Strange, I just recompiled it with bigtiff support.. how can I check if the
support is actually active or not?

When you run "configure", it will give you a list of enabled/disabled
options (prior to compilation). Check there...

And be sure that you have only one installation of the GDAL libs
on your system.

Markus

14

Markus,

Thanks for suggestions,

On Mon, Jul 16, 2012 at 10:46 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Mon, Jul 16, 2012 at 2:59 PM, Margherita Di Leo
<dileomargherita@gmail.com> wrote:
…

Strange, I just recompiled it with bigtiff support… how can I check if the
support is actually active or not?

When you run “configure”, it will give you a list of enabled/disabled
options (prior to compilation). Check there…

I get:

LIBTIFF support: internal (BigTIFF=yes)
LIBGEOTIFF support: internal

And be sure that you have only one installation of the GDAL libs
on your system.

Before compiling gdal I’ve removed the package coming from red hat.

Yesterday I’ve tried with:

CACHE=“–config GDAL_CACHEMAX 8000 -wm 2000”

Now I don’t get any error and the job is moving on somehow, but it is taking forever so I think I should try to adjust better the parameters…

–
Dr. Margherita Di Leo

15

Hi Helmut,

On Sun, Jul 15, 2012 at 10:14 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

using GDAL Virtual Format [1] by building a virtual dataset by gdalbuildvrt?

it’s really a nice gdal utility:

no need to patch all ASTER GDEM tiles within grass, just import the virtual
dataset by r.in.gdal or link it by r.external

[1] http://www.gdal.org/gdal_vrttut.html
[2] http://www.gdal.org/gdalbuildvrt.html

I decided to follow your hint and explore the way of gdalbuildvrt. I’m using:

gdalbuildvrt -input_file_list /home/leomarg/Desktop/aster/elenco_aster_europa
/home/leomarg/Desktop/aster/mosaic.vrt

and the process takes only few seconds, without complaining. The problem raises when i try to import it in GRASS:

r.external input=/home/leomarg/Desktop/aster/mosaic.vrt output=mosaic

Projection of input dataset and current location appear to match
Importing band 1 of 1…
ERROR 4: `ASTGTM_N33E000_dem_lzw.tif’ does not exist in the file system,
and is not recognised as a supported dataset name.

Link to raster map created

r.info map=mosaic
±---------------------------------------------------------------------------+
| Layer: mosaic Date: Tue Jul 17 15:43:08 2012 |
| Mapset: PERMANENT Login of Creator: leomarg |
| Location: ASTER_GDEM |
| DataBase: /forest/GRASS/grassdata |
| Title: ( mosaic ) |

Timestamp: none
Type of Map: raster Number of Categories: 0
Data Type: CELL
Rows: 140401
Columns: 198001
Total Cells: 27799538401
Projection: Latitude-Longitude
N: 72:00:00.5N S: 32:59:59.5N Res: 0:00:01
E: 44:00:00.5E W: 11:00:00.5W Res: 0:00:01
Range of data: min = 0 max = 0
Data Description:
generated by r.external
Comments:
r.external input=“/home/leomarg/Desktop/aster/mosaic.vrt” output="mo\
saic"
±---------------------------------------------------------------------------+

what am i missing?

Thanks!

–
Dr. Margherita Di Leo

16

hi,

r.external input=/home/leomarg/Desktop/aster/mosaic.vrt output=mosaic

Projection of input dataset and current location appear to match
Importing band 1 of 1...
ERROR 4: `ASTGTM_N33E000_dem_lzw.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

tested here with srtm-tiles for whole europe:

the tiles are in subfolders

C:\data\gisdata\srtm412011\srtm_35_03
C:\data\gisdata\srtm412011\srtm_36_04
[...]

the virtual dataset file is in

C:\data\gisdata\srtm412011

the link to the tiles within the vrt-file

[...]
<ComplexSource>
      <SourceFilename
relativeToVRT="1">srtm_35_03\srtm_35_03.tif</SourceFilename>
      <SourceBand>1</SourceBand>
      <SourceProperties RasterXSize="6000" RasterYSize="6000"
DataType="Int16" BlockXSize="6000" BlockYSize="1"/>
      <SrcRect xOff="0" yOff="0" xSize="6000" ySize="6000"/>
      <DstRect xOff="0" yOff="12000" xSize="6000" ySize="6000"/>
      <NODATA>-32768</NODATA>
    </ComplexSource>
[...]

link with r.external is ok:

r.external --verbose input=C:\data\gisdata\srtm412011\srtm41.vrt
output=linkedsrtm2
Die Projektionsinformationen des Eingabedatensatzes und der aktuellen
Location scheinen übereinzustimmen.
Fahre mit dem Import fort...
Importing band 1 of 1...
Erstelle Graustufen Farbtabelle für <linkedsrtm2> (Datenspanne).
Erstelle Support-Dateien für <linkedsrtm2>.
Link zur Rasterkarte <linkedsrtm2> erzeugt

r.info map=linkedsrtm2@srtm

+----------------------------------------------------------------------------+
| Layer: linkedsrtm2@srtm Date: Tue Jul 17 16:22:03 2012
|
| Mapset: srtm Login of Creator: myricaria
|
| Location: uwdwgs84
|
| DataBase: \grassdata
|
| Title: ( linkedsrtm2 )
|
| Timestamp: none
|

|----------------------------------------------------------------------------|
|
|
| Type of Map: raster Number of Categories: 0
|
| Data Type: CELL
|
| Rows: 24000
|
| Columns: 48000
|
| Total Cells: 1152000000
|
| Projection: Längen- und Breitengrad
|
| N: 60N S: 40N Res: 0:00:03
|
| E: 30E W: 10W Res: 0:00:03
|
| Range of data: min = -444 max = 4783
|
|
|
| Data Description:
|
| generated by r.external
|
|
|
| Comments:
|
| r.external input="C:\data\gisdata\srtm412011\srtm41.vrt" output="lin\
|
| kedsrtm2"
|
|
|

+----------------------------------------------------------------------------+

could it be a path issue on your side?

gdalbuildvrt -input_file_list
/home/leomarg/Desktop/aster/elenco_aster_europa \
/home/leomarg/Desktop/aster/mosaic.vrt

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/limits-of-r-patch-tp4988265p4988827.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

17

ERROR 4: `ASTGTM_N33E000_dem_lzw.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

what says gdalinfo about ASTGTM_N33E000_dem_lzw.tif?

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/limits-of-r-patch-tp4988265p4988828.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

18

On Tue, Jul 17, 2012 at 4:34 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

ERROR 4: `ASTGTM_N33E000_dem_lzw.tif’ does not exist in the file system,
and is not recognised as a supported dataset name.

what says gdalinfo about ASTGTM_N33E000_dem_lzw.tif?

gdalinfo ASTGTM_N33E000_dem_lzw.tif
Driver: GTiff/GeoTIFF
Files: ASTGTM_N33E000_dem_lzw.tif
Size is 3601, 3601
Coordinate System is:
GEOGCS[“WGS 84”,
DATUM[“WGS_1984”,
SPHEROID[“WGS 84”,6378137,298.257223563,
AUTHORITY[“EPSG”,“7030”]],
AUTHORITY[“EPSG”,“6326”]],
PRIMEM[“Greenwich”,0],
UNIT[“degree”,0.0174532925199433],
AUTHORITY[“EPSG”,“4326”]]
Origin = (-0.000138888888889,34.000138888888891)
Pixel Size = (0.000277777777778,-0.000277777777778)
Metadata:
AREA_OR_POINT=Area
TIFFTAG_DATETIME=2008:10:28 20:03:51
TIFFTAG_DOCUMENTNAME=created at
TIFFTAG_IMAGEDESCRIPTION=SILC TIFF
TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
TIFFTAG_SOFTWARE=IDL 6.3, Research Systems, Inc.
TIFFTAG_XRESOLUTION=100
TIFFTAG_YRESOLUTION=100
Image Structure Metadata:
COMPRESSION=LZW
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( -0.0001389, 34.0001389) ( 0d 0’ 0.50"W, 34d 0’ 0.50"N)
Lower Left ( -0.0001389, 32.9998611) ( 0d 0’ 0.50"W, 32d59’59.50"N)
Upper Right ( 1.0001389, 34.0001389) ( 1d 0’ 0.50"E, 34d 0’ 0.50"N)
Lower Right ( 1.0001389, 32.9998611) ( 1d 0’ 0.50"E, 32d59’59.50"N)
Center ( 0.5000000, 33.5000000) ( 0d30’ 0.00"E, 33d30’ 0.00"N)
Band 1 Block=3601x1 Type=Int16, ColorInterp=Gray

–
Dr. Margherita Di Leo

19

what says gdalinfo about ASTGTM_N33E000_dem_lzw.tif?

oh, I've meant: gdalinfo mosaic.vrt

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/limits-of-r-patch-tp4988265p4988833.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

20

what says gdalinfo about ASTGTM_N33E000_dem_lzw.tif?

oh, I've meant: gdalinfo mosaic.vrt

tested here now with some aster-tiles:

C:\data\gisdata\asterdem\Tiles_201102121133>gdalinfo asterdem.vrt
Driver: VRT/Virtual Raster
Files: asterdem.vrt
      
C:\data\gisdata\asterdem\Tiles_201102121133\ASTGTM_N42E006\ASTGTM_N42E006
\ASTGTM_N42E006_dem.tif
      
C:\data\gisdata\asterdem\Tiles_201102121133\ASTGTM_N43E004\ASTGTM_N43E004
\ASTGTM_N43E004_dem.tif
      
C:\data\gisdata\asterdem\Tiles_201102121133\ASTGTM_N43E005\ASTGTM_N43E005
\ASTGTM_N43E005_dem.tif
Size is 10801, 7201
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (3.999861111111111,44.000138888888891)
Pixel Size = (0.000277777777778,-0.000277777777778)
Corner Coordinates:
Upper Left ( 3.9998611, 44.0001389) ( 3d59'59.50"E, 44d 0' 0.50"N)
Lower Left ( 3.9998611, 41.9998611) ( 3d59'59.50"E, 41d59'59.50"N)
Upper Right ( 7.0001389, 44.0001389) ( 7d 0' 0.50"E, 44d 0' 0.50"N)
Lower Right ( 7.0001389, 41.9998611) ( 7d 0' 0.50"E, 41d59'59.50"N)
Center ( 5.5000000, 43.0000000) ( 5d30' 0.00"E, 43d 0' 0.00"N)
Band 1 Block=128x128 Type=Int16, ColorInterp=Gray

linking with r.external also works here:

r.info map=asterdemlinked@asterdem

+----------------------------------------------------------------------------+
| Layer: asterdemlinked@asterdem Date: Tue Jul 17 16:44:24 2012
|
| Mapset: asterdem Login of Creator: myricaria
|
| Location: uwdwgs84
|
| DataBase: \grassdata
|
| Title: ( asterdemlinked )
|
| Timestamp: none
|

|----------------------------------------------------------------------------|
|
|
| Type of Map: raster Number of Categories: 0
|
| Data Type: CELL
|
| Rows: 7201
|
| Columns: 10801
|
| Total Cells: 77778001
|
| Projection: Längen- und Breitengrad
|
| N: 44:00:00.5N S: 41:59:59.5N Res: 0:00:01
|
| E: 7:00:00.5E W: 3:59:59.5E Res: 0:00:01
|
| Range of data: min = 0 max = 642
|
|
|
| Data Description:
|
| generated by r.external
|
|
|
| Comments:
|
| r.external input="C:\data\gisdata\asterdem\Tiles_201102121133\asterd\
|
| em.vrt" output="asterdemlinked"
|
|
|

+----------------------------------------------------------------------------+

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/limits-of-r-patch-tp4988265p4988835.html
Sent from the Grass - Dev mailing list archive at Nabble.com.