Re: [gdal-dev] warp taking time

2014-07-10 Thread Thornton, Michele M.
Hello,

I’m interested in this thread.  One comment I can add about gdal_merge.py is 
that it does not properly handle nodata values from the full (padded) extent of 
the input files.  gdalwarp, which can be VERY slow, does handle the nodata 
values correctly.

Michele Thornton

From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of bas smit
Sent: Thursday, July 10, 2014 7:52 AM
To: Chaitanya kumar CH
Cc: gdal dev
Subject: Re: [gdal-dev] warp taking time

I am wondering why you are using gdalwarp for mosaicing images having same 
projection instead of gdal_merge.py?

Bas Smit

On Thu, Jul 10, 2014 at 7:14 PM, Chaitanya kumar CH 
chaitanya...@gmail.commailto:chaitanya...@gmail.com wrote:
garfy,

Please provide the gdalwarp command you used. Did you modify GDAL_CACHEMAX?

On Thu, Jul 10, 2014 at 3:26 PM, garfy 
adiba.niz...@gmail.commailto:adiba.niz...@gmail.com wrote:
Dear All,

I am trying to generate mosaic of 28 input images using *gdalwarp*.
All are in same projection. It has taken 5 days to generate the final
output.
Please find the gdalinfo of input and output attached. The input files are
passed to warp in the order in which the gdalinfo is present in the
attachement.

Any input on improving the time would be really helpful.


Thanks
input_files_gdalinfo.txt
http://osgeo-org.1560.x6.nabble.com/file/n5150453/input_files_gdalinfo.txt
final_output_gdalinfo.txt
http://osgeo-org.1560.x6.nabble.com/file/n5150453/final_output_gdalinfo.txt





--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/warp-taking-time-tp5150453.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.orgmailto:gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
Best regards,
Chaitanya kumar CH.

+91-9494447584tel:%2B91-9494447584
17.2416N 80.1426E

___
gdal-dev mailing list
gdal-dev@lists.osgeo.orgmailto:gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] keep metadata tags when creating multiband file

2013-10-23 Thread Thornton, Michele M.
Hello List,

Apologies if this is a repeat post.  Not sure that I was subscribed properly.

I have a number of individual Landsat bands that I'm converting to GeoTiff and 
would then like to merge to a multiband file using either gdal_merge.py or 
another gdal utility (gdalbuildvrt, gdal_translate).  In the individually 
derived geotif files, I am able to internally label the corresponding Landsat 
band by creating a metadata tag.  For example, in using the following 
gdal_translate command from a file that is Landsat data for Band 1 called 
landsat.b1.dat:

gdal_translate -of GTiff -strict -stats -mo Band = LandsatBand ${f: -5:1} -co 
COMPRESS=LZW  -co PROFILE=GeoTIFF $f $f.tif

This creates a metadata tag in the tif file:
-
Metadata:
  AREA_OR_POINT=Area
  Band =LandsatBand 1

And there is a separate .aux.xml for each of the tif files:
---
PAMDataset
  Metadata
MDI key=Band LandsatBand 1/MDI
  /Metadata
  PAMRasterBand band=1
Metadata
  MDI key=STATISTICS_MAXIMUM255/MDI
  MDI key=STATISTICS_MEAN40.826976974681/MDI
  MDI key=STATISTICS_MINIMUM0/MDI
  MDI key=STATISTICS_STDDEV31.471508896152/MDI
/Metadata
  /PAMRasterBand


Now, I have for example 6 such separate files with Landsat bands labeled 1-5 
and 7 respectively.  I would like to keep these metadata tags (Band 
=LandsatBand #) when I derive a single multiband file to ensure that legacy in 
the file metadata.  In other words, more internal metadata information than 
Band_1 - Band_6 when in fact the bands are Landsat bands 1-5, and 7.

So far, gdal_merge.py and the other gdal utilities drop the metadata tags. I've 
tried the flag -co PROFILE=GeoTIFF in gdal_merge.py with no luck.Is it 
possible to create a multiband file and retain the metadata band information?

Thanks in advance,
Michele

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] keep metadata tags when creating multiband file

2013-10-23 Thread Thornton, Michele M.
Thank you Even,

Very useful information.  

Kind regards,
Michele

-Original Message-
From: Even Rouault [mailto:even.roua...@mines-paris.org] 
Sent: Wednesday, October 23, 2013 10:41 AM
To: gdal-dev@lists.osgeo.org
Cc: Thornton, Michele M.
Subject: Re: [gdal-dev] keep metadata tags when creating multiband file

Michele,

 
 I have a number of individual Landsat bands that I'm converting to 
 GeoTiff and would then like to merge to a multiband file using either 
 gdal_merge.py or another gdal utility (gdalbuildvrt, gdal_translate).  
 In the individually derived geotif files, I am able to internally 
 label the corresponding Landsat band by creating a metadata tag.  
 For example, in using the following gdal_translate command from a file 
 that is Landsat data for Band 1 called landsat.b1.dat:
 
 gdal_translate -of GTiff -strict -stats -mo Band = LandsatBand ${f: -5:1}
 -co COMPRESS=LZW  -co PROFILE=GeoTIFF $f $f.tif
 
 This creates a metadata tag in the tif file:
 -
 Metadata:
   AREA_OR_POINT=Area
   Band =LandsatBand 1
 
 And there is a separate .aux.xml for each of the tif files:
 ---
 PAMDataset
   Metadata
 MDI key=Band LandsatBand 1/MDI
   /Metadata
   PAMRasterBand band=1
 Metadata
   MDI key=STATISTICS_MAXIMUM255/MDI
   MDI key=STATISTICS_MEAN40.826976974681/MDI
   MDI key=STATISTICS_MINIMUM0/MDI
   MDI key=STATISTICS_STDDEV31.471508896152/MDI
 /Metadata
   /PAMRasterBand
 

Instead of setting the band name at the dataset level, you should set it at the 
band level instead. There's currently no way to do that with gdal_translate. 
You have to edit the .aux.xml file manually :

For example let's consider band1.tif with band1.tif.aux.xml :

PAMDataset
  PAMRasterBand band=1
Metadata
  MDI key=BandLandsatBand 1/MDI
/Metadata
  /PAMRasterBand
/PAMDataset

and band2.tif with band2.tif.aux.xml :

PAMDataset
  PAMRasterBand band=1
Metadata
  MDI key=BandLandsatBand 2/MDI
/Metadata
  /PAMRasterBand
/PAMDataset

and then you would want to run gdalbuildvrt -separate merged.vrt band1.tif 
band2.tif. Unfortunately I see that it also loses band metadata. I don't think 
there's a fundamental reason to explain that they are lost, except that it 
hasn't been coded yet.

You can still put then again by editing the merged.vrt and adding the 
Metadata  MDI key=BandLandsatBand X/MDI /Metadata at 
appropriate place.

See below :

VRTDataset rasterXSize=20 rasterYSize=20
  SRSPROJCS[NAD27 / UTM zone
11N,GEOGCS[NAD27,DATUM[North_American_Datum_1927,SPHEROID[Clarke
1866,6378206.4,294.9786982139006,AUTHORITY[EPSG,7008]],AUTHORITY[EPSG,6267]],PRIMEM[Greenwich,0],UNIT[degree,0.0174532925199433],AUTHORITY[EPSG,4267]],PROJECTION[Transverse_Mercator],PARAMETER[latitude_of_origin,0],PARAMETER[central_meridian,-117],PARAMETER[scale_factor,0.9996],PARAMETER[false_easting,50],PARAMETER[false_northing,0],UNIT[metre,1,AUTHORITY[EPSG,9001]],AUTHORITY[EPSG,26711]]/SRS
  GeoTransform  4.4072e+05,  6.e+01, 
0.e+00,  3.75132000e+06,  0.e+00, 
-6.e+01/GeoTransform
  VRTRasterBand dataType=Byte band=1
Metadata
  MDI key=BandLandsatBand 1/MDI
/Metadata
SimpleSource
  SourceFilename relativeToVRT=1byte1.tif/SourceFilename
  SourceBand1/SourceBand
  SourceProperties RasterXSize=20 RasterYSize=10 DataType=Byte 
BlockXSize=20 BlockYSize=10 /
  SrcRect xOff=0 yOff=0 xSize=20 ySize=10 /
  DstRect xOff=0 yOff=0 xSize=20 ySize=10 /
/SimpleSource
  /VRTRasterBand
  VRTRasterBand dataType=Byte band=2
Metadata
  MDI key=BandLandsatBand 2/MDI
/Metadata
SimpleSource
  SourceFilename relativeToVRT=1byte2.tif/SourceFilename
  SourceBand1/SourceBand
  SourceProperties RasterXSize=20 RasterYSize=20 DataType=Byte 
BlockXSize=20 BlockYSize=20 /
  SrcRect xOff=0 yOff=0 xSize=20 ySize=20 /
  DstRect xOff=0 yOff=0 xSize=20 ySize=20 /
/SimpleSource
  /VRTRasterBand
/VRTDataset


And then

$ gdal_translate merged.vrt merged.tif 

$ gdalinfo merged.tif
Driver: VRT/Virtual Raster
Files: merged.tif
Size is 20, 20
Coordinate System is:
PROJCS[NAD27 / UTM zone 11N,
GEOGCS[NAD27,
DATUM[North_American_Datum_1927,
SPHEROID[Clarke 1866,6378206.4,294.9786982139006,
AUTHORITY[EPSG,7008]],
AUTHORITY[EPSG,6267]],
PRIMEM[Greenwich,0],
UNIT[degree,0.0174532925199433],
AUTHORITY[EPSG,4267]],
PROJECTION[Transverse_Mercator],
PARAMETER[latitude_of_origin,0],
PARAMETER[central_meridian,-117],
PARAMETER[scale_factor,0.9996],
PARAMETER[false_easting,50],
PARAMETER[false_northing,0],
UNIT[metre,1,
AUTHORITY[EPSG,9001]],
AUTHORITY[EPSG,26711]]
Origin = (440720.000,3751320.000)
Pixel Size