[gdal-dev] gdal_merge with jython

Dear list, I am using Java to call gdal_merge(), but having troubles. Are there examples or tips? Thank you! ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_merge -of format

Thank you Andrew! From: Andrew C Aitchison Sent: January 11, 2024 6:00 AM To: ni hao Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdal_merge -of format On Wed, 10 Jan 2024, ni hao via gdal-dev wrote: > Hi list, > > > > question about:

Re: [gdal-dev] gdal_merge -of format

On Wed, 10 Jan 2024, ni hao via gdal-dev wrote: Hi list, question about: gdal_merge -of format besides GTiff, what other formats can I specify? May I specify USGS DEM format? Look in the output of gdalinfo --formats any raster format with rw for read-write can be used. # gdalinfo

[gdal-dev] gdal_merge -of format

Hi list, question about: gdal_merge -of format besides GTiff, what other formats can I specify? May I specify USGS DEM format? Thank you, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_merge tries create 377 GB raster

Puolesta Clive Swan Lähetetty: maanantai 12. joulukuuta 2022 23.49 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: [gdal-dev] gdal_merge tries create 377 GB raster /data/coastal.tif should be 6.9GB I get weird output from gdal_merge?? gdal_merge.py -o /data/coastal.tif -n - -co BIGTIFF=YES -co

[gdal-dev] gdal_merge tries create 377 GB raster

/data/coastal.tif should be 6.9GB I get weird output from gdal_merge?? gdal_merge.py -o /data/coastal.tif -n - -co BIGTIFF=YES -co COMPRESS=LZW -co BLOCKXSIZE=128 -co BLOCKYSIZE=128 -co NUM_THREADS=ALL_CPUS --config CPL_VSIL_USE_TEMP_FILE_FOR_RANDOM_WRITE YES --config GDAL_SWATH_SIZE 1

Re: [gdal-dev] gdal_merge

On Mon, 5 Dec 2022, Clive Swan wrote: The raster file details are: Extent: -180.,-90. : 180.,90. Width: 7200 Height: 3600 Pixel Size = (0.0008000,-0.0008000) Data type: Float32 - Thirty two bit floating point Compre

Re: [gdal-dev] gdal_merge

The raster file details are: Extent: -180.,-90. : 180.,90. Width: 7200 Height: 3600 Pixel Size = (0.0008000,-0.0008000) Data type: Float32 - Thirty two bit floating point Compression: LZW - Still getting an error f

Re: [gdal-dev] gdal_merge

On 12/5/2022 6:31 AM, Clive Swan wrote: Greetings,  I tried -ps 3600 7200   -ps 3600,7200 -ps x=3600  y=7200   Just get errors, I don't see any option to select LZW or any compression?

Re: [gdal-dev] gdal_merge

S=LZW -co TILED=YES" into the command. -Jukka Rahkonen- Lähettäjä: Clive Swan Lähetetty: maanantai 5. joulukuuta 2022 15.32 Vastaanottaja: Rahkonen Jukka Kopio: gdal-dev@lists.osgeo.org Aihe: Re: [gdal-dev] gdal_merge Greetings, I tried -ps 3600 7200 -ps 3600,7200 -ps x=3600 y=7200 Just

Re: [gdal-dev] gdal_merge

pressed > image into an uncompressed image, as I guess that you are doing, the output > will be much bigger. How big it will be can be calculated with a formula > that numpy showed (width x height) x (bytes/pixel). > > > > -Jukka Rahkonen- > > > > *Lähettäjä:* Clive S

Re: [gdal-dev] gdal_merge

*From:* Rahkonen Jukka *Sent:* Monday, December 5, 2022 11:34:53 AM *To:* Clive Swan ; gdal-dev@lists.osgeo.org *Subject:* Re: [gdal-dev] gdal_merge Hi, Maybe your rasters are far apart. Gdal_merge creates a raster with so large extent that all the source images fit within it. Even empty pixel

Re: [gdal-dev] gdal_merge

2022 13.47 Vastaanottaja: Rahkonen Jukka ; gdal-dev@lists.osgeo.org Aihe: Re: [gdal-dev] gdal_merge Hi, The raster one is the world, the second is the UK. The UK fits within the first raster... We want to update UK data in raster one. Regards, Clive Get Outlook for Android<https://eur06.safelinks

Re: [gdal-dev] gdal_merge

:34:53 AM To: Clive Swan ; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdal_merge Hi, Maybe your rasters are far apart. Gdal_merge creates a raster with so large extent that all the source images fit within it. Even empty pixels take space. -Jukka Rahkonen- Lähettäjä: gd

Re: [gdal-dev] gdal_merge

@lists.osgeo.org Aihe: [gdal-dev] gdal_merge Hi Even, Thanks the –configuration sorted out that issue. CPL_VSIL_USE_TEMP_FILE_FOR_RANDOM_WRITE is a configuration option / environment variable, so you have to pass it with --config CPL_VSIL_USE_TEMP_FILE_FOR_RANDOM_WRITE YES Now I am getting a memory

[gdal-dev] gdal_merge

Hi Even, Thanks the –configuration sorted out that issue. CPL_VSIL_USE_TEMP_FILE_FOR_RANDOM_WRITE is a configuration option / environment variable, so you have to pass it with --config CPL_VSIL_USE_TEMP_FILE_FOR_RANDOM_WRITE YES Now I am getting a memory issue?? << The input files are 6.9

Re: [gdal-dev] gdal_merge

Clive, CPL_VSIL_USE_TEMP_FILE_FOR_RANDOM_WRITE is a configuration option / environment variable, so you have to pass it with --config CPL_VSIL_USE_TEMP_FILE_FOR_RANDOM_WRITE YES Even Le 29/11/2022 à 20:12, Clive Swan a écrit : Greetings, I am trying to select band 1 and then use gdal_merge

[gdal-dev] gdal_merge

Greetings, I am trying to select band 1 and then use gdal_merge to merge two tiff files in an AWS bucket. Getting odd errors. gdal_merge.py -o /vsis3/summer-outputs/3_dataupdated/rcp26-2020-coastal_flood-NA-false.tif /vsis3/summer-outputs/3_data_ready_for_spectra/coastal-undefended-rcp26-2020.tif

Re: [gdal-dev] gdal_merge

] Sent: August-13-19 4:51 AM To: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdal_merge Hi, If you read https://urldefense.proofpoint.com/v2/url?u=https-3A__gdal.org_programs_gdal-5Fmerge.html&d=DwIGaQ&c=qv9gmtOiXdJCj9gMlMKtaw&r=ROy3ulwX11d_sGWoPYB0I5rYOqZ87kk4K

Re: [gdal-dev] gdal_merge

Hi, If you read https://gdal.org/programs/gdal_merge.html carefully you'll notice that -n is used for telling what nodata value is used in the source files and it is only needed if GDAL can't recognize it automatically. Try -a_nodata -32767 instead "Assign a specified nodata value to output bands.

[gdal-dev] gdal_merge

Hi list, I use gdal_merge to mosaic a set of DTED 1 and 2 chips. DTED contains -32767 as nodata. But after merging, -32767 are reset as 0. I tried to use "-n -32767" but getting the same result. Is there a way to keep the -32767 values? Thanks, Shawn This electronic correspondence, including an

[gdal-dev] gdal_merge unexpectedly setting nodata to zeros

Hi all, I am trying to merge 4 rasters containing nodata pixels using gdal_merge in a single file with separate bands. I use - as nodata value. In the output file, the first band has the correct nodata pixels (-) but the following 3 bands have some zeros, in pixels that were nodata in the

Re: [gdal-dev] gdal_merge nodata evaluation

Thanks Even. It also looks like gdal_merge always uses nearest neighbor interpolation, which is another reason we’ll have to use gdalwarp instead. Matt . Matthew Cechini Contractor, Science Systems and Applications, Inc. NASA GIBS Sy

Re: [gdal-dev] gdal_merge nodata evaluation

On Thursday 20 October 2016 20:27:14 Cechini, GSFC-423.0, Inc.] wrote: > All, >We’ve recently begun usage of the gdal_merge utility in our processing > workflow and have hit a snag. I’m not sure if the snag is by design or is > user error. Here’s the scenario: >We have two 24_bit PNG im

[gdal-dev] gdal_merge nodata evaluation

All, We’ve recently begun usage of the gdal_merge utility in our processing workflow and have hit a snag. I’m not sure if the snag is by design or is user error. Here’s the scenario: We have two 24_bit PNG images, and existing image (E) and a new image (N) we are merging into E. They a

Re: [gdal-dev] gdal_merge error on linux debian. It dont find gdal_array.

Hi Even, many thx for your help. Infact installing numpy and recompiling the gdal_merge start to work . yup ! :) 2015-07-23 15:41 GMT+02:00 Even Rouault : > Andre, > > Make sure you have the python-numpy package installed and recompile the GDAL > python bindings > > Even > >> Hi >> >> I'm tryi

Re: [gdal-dev] gdal_merge error on linux debian. It dont find gdal_array.

Andre, Make sure you have the python-numpy package installed and recompile the GDAL python bindings Even > Hi > > I'm trying to use the gdal_merge.py. More explixitly I try this call: > > gdal_merge.py -separate /path-to-raster/LC81920292015189LGN00_rgb_hpf.tif \ > /path-to-raster/LC81930

[gdal-dev] gdal_merge error on linux debian. It dont find gdal_array.

Hi I'm trying to use the gdal_merge.py. More explixitly I try this call: gdal_merge.py -separate /path-to-raster/LC81920292015189LGN00_rgb_hpf.tif \ /path-to-raster/LC81930292015196LGN00_rgb_hpf.tif \ -o result_image.tif (the tiff are float32.) The gdal_merge.py gives this error: 0Trac

Re: [gdal-dev] gdal_merge vs gdalbuildvrt

Interesting... Thanks for the insights. And about performance, if I have 1000 JPEG files forming a mosaic, and want to run gdal tools over that mosaic, which option should I choose? - Build real merged tif file (gdal_merge) - Build virtual raster (gdalbuildvrt) For example, if I want to run gdal

Re: [gdal-dev] gdal_merge vs gdalbuildvrt

Hello Jukka, On 06/02/15 10:25, Jukka Rahkonen wrote: Even Rouault spatialys.com> writes: > >> >>> gdalbuildvrt is a more >>> powerful tool that provides a virtual raster that acts as a 'window' >>> into the >>> input datasets, potentially with reprojection amidst other options. >> >> Small c

Re: [gdal-dev] gdal_merge vs gdalbuildvrt

Even Rouault spatialys.com> writes: > > > gdalbuildvrt is a more > > powerful tool that provides a virtual raster that acts as a 'window' > > into the > > input datasets, potentially with reprojection amidst other options. > > Small correction: gdalbuildvrt can only deal with datasets of the s

Re: [gdal-dev] gdal_merge vs gdalbuildvrt

> gdalbuildvrt is a more > powerful tool that provides a virtual raster that acts as a 'window' > into the > input datasets, potentially with reprojection amidst other options. Small correction: gdalbuildvrt can only deal with datasets of the same projection. -- Spatialys - Geospatial professi

Re: [gdal-dev] gdal_merge vs gdalbuildvrt

Hello Jorge, I didn't see an answer to this question, so... On 29/01/15 15:39, Jorge Arévalo wrote: Hello, > > What's the difference between gdal_merge and gdalbuildvrt? If I'm not wrong, gdal_merge actually creates a new dataset, merging the input ones. And gdalbuildvrt just creates a VRT f

[gdal-dev] gdal_merge vs gdalbuildvrt

Hello, What's the difference between gdal_merge and gdalbuildvrt? If I'm not wrong, gdal_merge actually creates a new dataset, merging the input ones. And gdalbuildvrt just creates a VRT file, which works as descriptor for a mosaic. At the end, in both cases we have a mosaic from several inp

[gdal-dev] Gdal_merge question

When we use Gdal_merge.py to merge GeoTIFF tiles that have been warped using gdalwarp, we find that the resulting GeoTIFFs have gaps, although the positions within the images are correct. Importing the unmerged GeoTIFF tiles into a GIS application does not show the problem. I have samples that sh

Re: [gdal-dev] gdal_merge gdal-dev Digest, Vol 118, Issue 59

Hi, I need to merge two images and want get a smooth blending effect in the overlap region of the two images. I have not get a successful result by trying gdal_merge.py. Using the gdalwarp,I just got a result that one image replaces the other within the overlay region and a sharpen seamline

Re: [gdal-dev] gdal_merge (was: gdal-dev Digest, Vol 118, Issue 58)

On 27/03/2014 07:21, ridgewang wrote: > Hi， > I have 2 suggestions： > 1. supply an option that can build the gdal using the static c++ runtime > library, so we can use it not depends on the msvcr80.dll and msvcp80.dll. > Hi, You can use gdalwarp to merge several files.

Re: [gdal-dev] gdal_merge does not mosaic

Thanks Frank. I have been able to solve the issue. Using your clue, I am reprojecting all the input images to common projected coordinate system (of the image which will be at mosaic'c center) and then mosaicing. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-merge-do

Re: [gdal-dev] gdal_merge does not mosaic

Adi, As previously mentioned the input images have different coordinate systems. gdal_merge.py does not support this situation. I was able to somewhat successfully merge them like this: gdalwarp img1.img img1_wgs84.img -t_srs WGS84 gdalwarp img2.img img2_wgs84.img -t_srs WGS84 gdal_merge.py img

Re: [gdal-dev] gdal_merge does not mosaic

img1.img img2.img I have attached the inputs images ( reduced resolution). -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-merge-does-not-mosai

Re: [gdal-dev] gdal_merge does not mosaic

On Tue, Jun 4, 2013 at 6:59 AM, adi_khan wrote: > Hi All, > > Could you please suggest any open source library/API/ command line tools > (on > Linux) that can mosaic images of the kind I posted earlier (with different > paramters etc..)? > > Also if I am to use gdal_merge then I will have to rep

Re: [gdal-dev] gdal_merge does not mosaic

adi_khan gmail.com> writes: > > Hi All, > > Could you please suggest any open source library/API/ command line tools (on > Linux) that can mosaic images of the kind I posted earlier (with different > paramters etc..)? > > Also if I am to use gdal_merge then I will have to reproject all input

Re: [gdal-dev] gdal_merge does not mosaic

Hi All, Could you please suggest any open source library/API/ command line tools (on Linux) that can mosaic images of the kind I posted earlier (with different paramters etc..)? Also if I am to use gdal_merge then I will have to reproject all input images to one projcs and then try mosaicing ?

Re: [gdal-dev] gdal_merge does not mosaic

Thanks! On Tue, Jun 4, 2013 at 2:57 PM, Rahkonen Jukka [via OSGeo.org] < ml-node+s1560n5057691...@n6.nabble.com> wrote: > adi_khan gmail.com> writes: > > > > > > >

Re: [gdal-dev] gdal_merge does not mosaic

adi_khan gmail.com> writes: > > > > > > Hi all, > here please find the input and output I used. >

Re: [gdal-dev] gdal_merge does not mosaic

Hi all, here please find the input and output I used. The attached images : 1. First image is a snap

Re: [gdal-dev] gdal_merge does not mosaic

On Fri, May 31, 2013 at 7:47 PM, Jean-Claude Repetto wrote: > On 31/05/2013 19:48, adi_khan wrote: > >> Thanks for your reply frank. >> I understand that the GDAL I am using is ancient, but considering >> 'upgrading >> to other version' not an option could you tell me if there's a way I can >> mos

Re: [gdal-dev] gdal_merge does not mosaic

On 31/05/2013 19:48, adi_khan wrote: Thanks for your reply frank. I understand that the GDAL I am using is ancient, but considering 'upgrading to other version' not an option could you tell me if there's a way I can mosaic using 1.4.5 only? Another option is to use gdalwarp instead of gdal_merg

Re: [gdal-dev] gdal_merge does not mosaic

Thanks for your reply frank. I understand that the GDAL I am using is ancient, but considering 'upgrading to other version' not an option could you tell me if there's a way I can mosaic using 1.4.5 only? Input images are spatially distinct. And the output image I.e. mosaic.img was not already crea

Re: [gdal-dev] gdal_merge does not mosaic

Am 31.05.2013 07:36, schrieb adi_khan: I am using gdal 1.4.5 and wish to use gdal_merge to mosaic *.img images. Please update to the current version. GDAL 1.10.0 is out now, available for Windows via gisinternals.com. Greetings, André Joost ___

Re: [gdal-dev] gdal_merge does not mosaic

Hi, GDAL 1.4.5 is ancient. Consider upgrading. The last release was 1.10.0. Your commandline looks ok. Without knowing much about your input images or what your output looks like it is hard to judge what went wrong. Are img1.img, img2.img and img3.img spatially distinct? Is the produced mosa

Re: [gdal-dev] gdal_merge does not mosaic

Update to gdal 1.9 and try again. On Fri, May 31, 2013 at 2:36 AM, adi_khan wrote: > I am using gdal 1.4.5 and wish to use gdal_merge to mosaic *.img images. > > The command runs successfully (no error is reported) but the output file > contains the last input image and not mosaiced output. > I

[gdal-dev] gdal_merge does not mosaic

I am using gdal 1.4.5 and wish to use gdal_merge to mosaic *.img images. The command runs successfully (no error is reported) but the output file contains the last input image and not mosaiced output. I use openEV to see the output file. This is how is used the command : gdal_merge.py -of HFA -o

Re: [gdal-dev] gdal_merge and HFA band statistics

Matt Hanneman wrote: Can anyone tell me why the option 'STATISTICS=YES' works when using gdal_translate to translate from TIF to HFA (Erdas Imagine), but will NOT work when using gdal_merge to stack multiple TIFs into HFA? I need ArcMap to read the statistics, but it doesnt seem that they are

[gdal-dev] gdal_merge and HFA band statistics

Can anyone tell me why the option 'STATISTICS=YES' works when using gdal_translate to translate from TIF to HFA (Erdas Imagine), but will NOT work when using gdal_merge to stack multiple TIFs into HFA? I need ArcMap to read the statistics, but it doesnt seem that they are being written to the f

Re: [gdal-dev] gdal_merge / negative size

Ghislain, It may be counter intuitive to have smaller y-coordinate for lower lines but you will have to take the pixel size into account. Consider what would happen if you want to stitch such images together and you try to reverse all the y coordinates. On Tue, Nov 2, 2010 at 12:34 AM, Ghislain P

Re: [gdal-dev] gdal_merge / negative size

Ghislain, It may be counter intuitive to have smaller y-coordinate for lower On Tue, Nov 2, 2010 at 12:34 AM, Ghislain Picard < ghislain.pic...@lgge.obs.ujf-grenoble.fr> wrote: > > Hi All, > > I have an image having y-coordinate increasing in the downward direction. > To display the image, the p

[gdal-dev] gdal_merge / negative size

Hi All, I have an image having y-coordinate increasing in the downward direction. To display the image, the pixel size is -1000 on the y-axis (see ENVI header file below). This works perfectly except in gdal_merge when use to clip the raster (using QGis GdalTools(s plugin for instance). For

RE: [gdal-dev] gdal_merge: stacking and band statistics

ategorical scheme, I would greatly appreciate that knowledge! Best, Jason -Original Message- From: Peter J Halls [mailto:p.ha...@york.ac.uk] Sent: Thursday, October 21, 2010 2:12 AM To: Jason Roberts Cc: 'Matt Hanneman'; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdal_merge: stac

Re: [gdal-dev] gdal_merge: stacking and band statistics

-boun...@lists.osgeo.org] On Behalf Of Matt Hanneman Sent: Wednesday, October 20, 2010 4:51 PM To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] gdal_merge: stacking and band statistics Hi, Can anyone help a newbie? I have been trying to calculate statistics with gdal_merge when merging/stacking several

RE: [gdal-dev] gdal_merge: stacking and band statistics

l-dev@lists.osgeo.org Subject: [gdal-dev] gdal_merge: stacking and band statistics Hi, Can anyone help a newbie? I have been trying to calculate statistics with gdal_merge when merging/stacking several tiffs together into a HFA format (see below for syntax). However, when loaded into ArcGIS it re

Re: [gdal-dev] gdal_merge: stacking and band statistics

Matt out of curiosity is this a new install of ArcGIS you're talking about, maybe version 9.2?  As I recall installs of 9.2 require a service pack to calc raster stats.  Otherwise, rasters show all black when loaded, etc. Elijah, VillaGIS, Inc., Branson, MO Matt Hanneman wrote: Hi, C

[gdal-dev] gdal_merge: stacking and band statistics

Hi, Can anyone help a newbie? I have been trying to calculate statistics with gdal_merge when merging/stacking several tiffs together into a HFA format (see below for syntax). However, when loaded into ArcGIS it reports that there are no statistics calculated for any of the bands. Will the '

Re: [gdal-dev] gdal_merge is very slow

On Jul 18, 2010, at 6:09 PM, Leith Bade wrote: > they only have a 32-bit build Not true. The complaint that Kakadu has never offered 64 bit versions of their command line executables for free is false. The Kakadu web site now offers, for free, version 6.4 for Mac OS X compiled for 32 bit and 64

Re: [gdal-dev] gdal_merge is very slow

Unfortunately I can't afford a Kakadu license for personal use so I am using the precompiled demo binaries. ( http://www.kakadusoftware.com/index.php?option=com_content&task=view&id=26&Itemid=22 ) As you can see they only have a 32-bit build (and it is not even compiled as Large Address Aware http

Re: [gdal-dev] gdal_merge is very slow

On Jul 18, 2010, at 12:44 AM, Leith Bade wrote: > kdu_compress also has a memory limit at 2 GB Not true. Based on your comment, I suspect that you are using a version of Kakadu that is more than 3 years old, or that was deliberately compiled for a 32 bit environment. Since version 6.0, releas

Re: [gdal-dev] gdal_merge is very slow

Leith, For the record, I've just made changes in the development version that allow specifying more than 2 GB (the effective value might be 2GB or 3GB on 32 bit operating systems). See http://trac.osgeo.org/gdal/ticket/3689 And the current limit is 2047, not 2147. (2147 * 1024 * 1024 is a negat

Re: [gdal-dev] gdal_merge is very slow

That seemed to do the trick. It finished overnight, a lot faster than before. Final file was 83GB. (Only 1/2 the dataset was used) Is there a reason GDAL_CACHEMAX 2147 is the maximum? Under 64-bit a 32-bit process has 4GB of virtual memory rather than 2GB under 32-bit (or 3GB with the /3GB Window

Re: [gdal-dev] gdal_merge is very slow

Since you have 4 GB RAM, I suggest overriding the 40 MB GDAL_CACHEMAX default, and increasing it gdal_merge.py --config GDAL_CACHEMAX 1000 The maximum possible GDAL_CACHEMAX is gdal_merge.py --config GDAL_CACHEMAX 2147 Greg On Jul 16, 2010, at 9:19 PM, Leith Bade wrote: > Hi, > > I am trying t

Re: [gdal-dev] gdal_merge is very slow

OK I will try the tiling. The aim of this merge is to generate an input for creating a compressed JPEG 2000 image (either using GDAL, Kakadu tools or the ER Image Compressor). In the meantime I have installed the 30-day demo of ER Mapper. This program was able to generate a mosaic in only a few s

Re: [gdal-dev] gdal_merge is very slow

I do not see that you specified that the output TIFF image be tiled -co TILED=YES -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 gdal_merge.py supports the -v input option that reports progress as a % for every source image merged into the destination image. It is better to do the initial gdal_merge.py un

[gdal-dev] gdal_merge is very slow

Hi, I am trying to use gdal_merge to mosaic a very large topo GeoTIFF set. Uncompressed the data set is 60GB, but I keep it stored with DEFLATE compression which results in a dataset under 10GB. Mosaicked the uncompressed file will be 125GB because of the large regions of nodata generated. Unfor

Re: [gdal-dev] gdal_merge GeoTIFF output twice correct size

On Mar 25, 2010, at 3:49 PM, Frank Warmerdam wrote: > Nathan Vander Wilt wrote: >> I used gdal_merge to combine four tiles into a perfectly square image. >> However, the resulting file was double the size on disk than I would expect >> based on its dimensions and bit depth. I opened it in a hex edi

Re: [gdal-dev] gdal_merge GeoTIFF output twice correct size

Nathan Vander Wilt wrote: I used gdal_merge to combine four tiles into a perfectly square image. However, the resulting file was double the size on disk than I would expect based on its dimensions and bit depth. I opened it in a hex editor, and there is a huge pattern of data that repeats 0x3

[gdal-dev] gdal_merge GeoTIFF output twice correct size

I used gdal_merge to combine four tiles into a perfectly square image. However, the resulting file was double the size on disk than I would expect based on its dimensions and bit depth. I opened it in a hex editor, and there is a huge pattern of data that repeats 0x3075 followed by a ton of

Re: [gdal-dev] gdal_merge on large files

Peter, In fact, tiling the input or output won't help for the issue. The main limitation of gdal_merge.py is that it ingests each input file in one gulp. So the limit is on the dimensions of the input files. The buffer must hold in RAM and be smaller than 2GB (the maximum size of a 32bit intege

Re: [gdal-dev] gdal_merge on large files

Peder, The problem here is the lack of or very large tiles/blocks in the image. BandReadAsArray() was asked to read a whole 27989 x 62863 block into memory. That's 1.76 Giga pixels. Too big. Greg Coats' tiff file had tiles of 512 x 512 size. Creating tiled tiffs is a good place to start. Use the

Re: [gdal-dev] gdal_merge on large files

On Jan 28, 2010, at 3:13 AM, Peder Axensten wrote: > What is the raster size restrictions in gdal/numpy? I have successfully used gdal_merge.py to create a 142 GB .tif file, on a computer with only 3 GB RAM, under Apple Mac OS X 10.6. Greg tiffinfo dcua0002.tif Image Width: 26 Image Lengt

[gdal-dev] gdal_merge on large files

I want to run gdal_merge (and another program I made, based on gdal_merge) on rather large files -- typically 3-7 Gbytes. Not surprisingly I run into problems. I'm not very experienced in Python, but am I right to assume that the error below probably is an indication on a size problem? What is t

Re: [gdal-dev] Gdal_merge

Denis Rykov wrote: Hi! I need merge two images - the first image is mutiband and second image is singleband. Can I do this operation with gdal_merge or gdal_merge works only with images with same number of bands? What utility from gdal library I can use for separate multiband image into some s

[gdal-dev] Gdal_merge

Hi! I need merge two images - the first image is mutiband and second image is singleband. Can I do this operation with gdal_merge or gdal_merge works only with images with same number of bands? What utility from gdal library I can use for separate multiband image into some singleband images? Thanks

Re: [gdal-dev] gdal_merge problems: Negative size passed to PyString_FromStringAndSize

Hi Even, Thank you for your very detailed explanation. I can now see what the problem is and was able to work around it by splitting up the larger files first that would exceed the maximum size. Andreas On Wed, May 6, 2009 9:36 pm, Even Rouault wrote: > Le Wednesday 06 May 2009 16:48:06 Andreas

Re: [gdal-dev] gdal_merge problems: Negative size passed to PyString_FromStringAndSize

Le Wednesday 06 May 2009 16:48:06 Andreas Neumann, vous avez écrit : > Hi, > Filename: a25.tif > File Size: 25472x25427x1 > Pixel Size: 42.431795 x -42.431795 > UL:(697837651.400476,244274906.596461) > LR:(698918474.082743,243195993.344970) > Copy 0,0,25472,25427 to 205747,211643,50722,50632. -->

[gdal-dev] gdal_merge problems: Negative size passed to PyString_FromStringAndSize

Hi, when trying to merge several tif-files (which had been converted previously from Intergraph cit files), I am running into this error message: -- Traceback (most recent call last): File "/usr/local/bin/gdal_merge.py", line 427, in fi.copy_into( t_fh, band, band, nodata )

Re: [gdal-dev] gdal_merge error with large 16 bit images

On Mon, Mar 23, 2009 at 5:04 AM, Ned Horning wrote: > Greetings, > > I am having trouble running gdal_merge on large unsigned 16 bit imagery. I > am using the OSGeo4W installation of gdal_merge.py. When I run it on 8-bit > unsigned GeoTiff imagery (Landsat TM) the program works as expected. When I

[gdal-dev] gdal_merge error with large 16 bit images

Greetings, I am having trouble running gdal_merge on large unsigned 16 bit imagery. I am using the OSGeo4W installation of gdal_merge.py. When I run it on 8-bit unsigned GeoTiff imagery (Landsat TM) the program works as expected. When I run it on two small 16-bit unsigned int GeoTiff subsets

Re: [Gdal-dev] gdal_merge: merge/mosaic NITF files

Charles, from the dimensions and size of your NITF tiles, I suppose they belong to a CADRG or CIB dataset. You will certainly find a file named A.TOC in an upper directory of your tiles. GDAL contains a driver called RPFTOC that is able to deal with such files. You can do a gdalinfo on it and i

Re: [Gdal-dev] gdal_merge: merge/mosaic NITF files

Charles Chung wrote: Hi all, I am new using GDAL and raster format. Here is my situation. With GDAL 1.6.0dev, I want to merge or mosaic many NITF files into one NITF or GeoTIFF file. Each NITF file is about 284 KB and its characterists are: Driver: NITF/National Imagery Transmission Format Fil

[Gdal-dev] gdal_merge: merge/mosaic NITF files

Hi all, I am new using GDAL and raster format. Here is my situation. With GDAL 1.6.0dev, I want to merge or mosaic many NITF files into one NITF or GeoTIFF file. Each NITF file is about 284 KB and its characterists are: Driver: NITF/National Imagery Transmission Format Files: ???.??? Size i

Re: [gdal-dev] gdal_merge

By the way, to get the order of precidence you want you should also reverse the order of the input images so that image1.tif is last (overlayed to top of everything else). Thanks for clarifying this Frank. Is there way to do the same with gdalwarp? I ask because I sometimes need to stack image

Re: [gdal-dev] gdal_merge

Thank you Frank: It solved my problem :) Best regards, William From: Frank Warmerdam <[EMAIL PROTECTED]> To: william paul <[EMAIL PROTECTED]> Cc: gdal-dev@lists.osgeo.org Sent: Friday, October 31, 2008 3:12:07 PM Subject: Re: [gdal-dev] gdal_me

Re: [gdal-dev] gdal_merge

william paul wrote: Hello to everybody: I want to use gdal_merge.py to mosaic four images. The images have the same size, but the content of the images overlaps only in some areas. The value for each images is something like : 1, 2, 3, 4 I want to mosaic all the files, but I want to be able

[gdal-dev] gdal_merge

Hello to everybody: I want to use gdal_merge.py to mosaic four images. The images have the same size, but the content of the images overlaps only in some areas. The value for each images is something like : 1, 2, 3, 4 I want to mosaic all the files, but I want to be able to specify which image

Re: [gdal-dev] gdal_merge and the treatment of nodata value

Hi Andreas, If you use gdalwarp rather than gdal_merge you could use the -srcnodata and -dstnodata flags to change the null value: gdalwarp in-01.tif in-02.tif outimage.tif -srcnodata 0 -dstnodata 255 This assumes the nodata in all the input images are the identical (0, or black). Since

Re: [gdal-dev] gdal_merge and the treatment of nodata value

Thanks for having a look at my problem. I am adding more information: I am merging a number of rgb tiff files (scanned city maps), but they don't align perfectly at the outer edges. This means that on the edges of the resulting output file, where the tiff files don't align, I get borders with nod

Re: [gdal-dev] gdal_merge and the treatment of nodata value

Andreas Neumann wrote: Hi, I am using gdal_merge to merge different rasters. The problem is that the nodata values appear as black and I want to have them white. Is there an option to set nodata values to white with gdal_merge? Or would I have to do this as a postprocessing? The problem is tha

[gdal-dev] gdal_merge and the treatment of nodata value

Hi, I am using gdal_merge to merge different rasters. The problem is that the nodata values appear as black and I want to have them white. Is there an option to set nodata values to white with gdal_merge? Or would I have to do this as a postprocessing? The problem is that the images are too larg