Tag Info

8

While I don't know why GDAL provides this overlap in functionality, be sure to set the cache for gdalwarp to make it really fast: # assuming 3G of cache here: gdalwarp --config GDAL_CACHEMAX 3000 -wm 3000 $(list_of_tiffs) merged.tiff Be sure to not define more cache than having RAM on the machine. 5 This was a tough problem to track down because I had thought that the effect was at the edges of tiles when it fact they are throughout the data. You're right that the phenomena isn't in the data before mosaicking the data. The problem results from the resampling process that is inherent in mosaicking. You need to use either the cubic convolution or bilinear ... 5 I ran across this mosaicing the True Marble imagery as well, though I used gdalbuildvrt and then gdal_translate. From memory, the recalcitrant tiffs are stored as a single band with a color table. Just convert them to 3 band RGB with gdal_translate: gdal_translate -expand rgb TrueMarble.250m.21600x21600.B4.tif TrueMarble.250m.21600x21600.B4.RGB.tif 4 gdal_merge.py is the correct tool to 'stack' your input images. Assuming that your first band has a valid color table you could use: gdal_merge.py -separate -pct -o output_file.tif file1.tif file2.tif file3.tif Note: The command has been reformatted with -o output_file.tif before the list of inputs. From the docs: -pct: Grab a pseudocolor table ... 3 gdal_merge.py -o output.tif ls *.tif The back ticks mean execute whatever is inside the back ticks before the main command, so this will find all tif files in current directory, which will then be used as the input to gdal_merge.py. Instead of backticks, you can also use the$(command) syntax, ie, gdal_merge.py -o output.tif $(ls *.tif) is ... 3 This may have already been resolved but for future readers. Try QGIS' Saga Plugin > Grid Tools > Mosaick raster layers. You can combine a number of rasters and classify overlapping areas with blending, feathering, min and max values. 3 The first way I can think of is to build a vrt, edit and translate: gdalbuildvrt -separate output.vrt file1.tif file2.tif file3.tif add the color interp tag where needed: ... <VRTRasterBand dataType="Byte" band="1"> <ColorInterp>Red</ColorInterp> <NoDataValue>255</NoDataValue> <ComplexSource> <SourceFilename ... 3 It is nearest neighbor as written in http://lists.osgeo.org/pipermail/gdal-dev/2006-November/010619.html There is also a hint in the mail "If you want control over the resampling used, you should use gdalwarp instead." 3 Turns out this is a projection issue. Prior to merging, I'm reprojecting the tiles from EPSG:4326 to EPSG:3785. When this is done after the merge no problems occur. 2 You can set the GDAL_MERGE process up with QGIS using the GUI and that might be a good way to start testing. Also, test on two tiles that are next to each other first. I reckon it's something to do with NODATA. Please post your command in your question so that we can see how you're achieving the merge. 2 I have a solution! It IS because of the old and infuriating GDAL upside-down export to GeoTiff (see my comments above)! Before anybody tells me that this has been fixed - I agree it does appear to be fixed but I was using a mixture of data converted with a older version of GDAL about 4 years ago and data I converted with the latest version of GDAL about 3 ... 2 Open MSYS (It should have been downloaded along if you used OSGeo4W utility to install qgis) cd (Change Directory) to your folder with your data. cd c:/(path to)/(my data)/ (Hint: pressing tab, autocompletes) one-line it: gdal_merge.py -o out.tif$(ls *.tif) out.tif -> is your output file, name it to whatever you want. \$(ls *.tif) -> lists all the files ...

2

gdal_merge.bat is the name of your batch file, isn't it. The gdal command inside the batch file is "gdal_merge.py" On the other hand, I have two suggestions : first, you should launch you script with Python instead of BAT. Second is to use vrt files. For instance, this could make : import subprocess subprocess.call(["gdalbuildvrt" ,"-separate", ...

1

The easiest way to do this is by importing the path where gdal_merge.py is located, in my case, /usr/bin/ -- substitute with the path to gdal_merge on your system, which, obviously, could be a Windows path too. import sys sys.path.append('/usr/bin/') import gdal_merge as gm You will now have to build up an array for sys.argv, as if you were calling ...

1

I would build a GDAL virtual image using (something like): gdalbuildvrt myimage.vrt images/*.tif and then tile that using either gdal2tiles or gdal_retile: gdal2tiles.py myimage.vrt outputDir or gdal_retile.py -tileIndex tileIndexName myimage.vrt

1

The chosen value is stored in the PhotometricInterpretation TIFF tag, which defines the color space, i.e. how to interpret the values of the bands. Example for a 3-band GeoTIFF defined as RGB: band 1 = red, band 2 = green, band 3 = blue. CMYK stands for the Cyan, Magenta, Yellow, blacK color space, etc.

1

you can loop on your files and append them to your list command = [sys.executable,gmerge,'-o','C:\\r.tif','-of','GTiff'] images = glob.glob("D:\\*.tif") for image in images: command.append(image) subprocess.call(command)

1

If you are in a windows environment you can create a batch file: @echo off for /f %%A in ('dir "c:\your_Path\*.tif" /b/s') do ( echo %%A "c:\path\to\GDAL\bin\gdaladddo" -ro %%A 2 4 8 16 32 ) This is a batch file that says "for this folder and every subfolder, every file with the '.tif' extension run gdaladdo". You will need to change c:\path\to\GDAL\bin ...

1

gdal_merge is a python script. It may get installed by default with GDAL, but it won't work without the GDAL-python libraries which may not be installed by default or you may not have selected if you were doing things manually. Check to see that you have the OSGeo gdal-python package installed. For the windows installer, it's listed under the libs section. ...

1

I also suggest to build a virtual raster. Using the batch command processing on Windows, it is as simply as gdalbuildvrt -allow_projection_difference index.vrt *.tif If the images use paletted colours, it is necessary to expand that to rgba first: for %%N in (D:\Karten\gdal\gdal2tiles\NL50\*.tif) DO gdal_translate -of vrt -expand rgba %%N ...

1

Answering my own question: Those black pixels in the images represent a "NoData" value. If I tell the gdal merge code that pixels with a color value of 0 are "NoData," it can correctly stitch the images together. (The "NoData" value isn't necessarily set to 0, it can be any value not otherwise used in the image, but in the case of NAIP ortho images, it was ...

1

I also needed to know how to rename bands in an open source environment so spent a whole day looking for answers. There is no way to name bands in QGIS while merging. But it can be done after the file is created, by editing their .aux.xml file. It works for both .tif and .img files, as far as I've researched. The solution is to include after each ...

1

You mean something like Grass' r.cross?

1

Yes, the two different version of GDAL_merge do behave differently. I ran into a similar problem (see this post), though yours appears to be a little different. Basically, I think that the more recent version is the one to trust. The reason it works differently is because thankfully it has been updated, so it should not be unbelievable.

Only top voted, non community-wiki answers of a minimum length are eligible