Hi Jeremy,
You can install QGIS with GDAL and python bindings using alternative
installer by NextGIS (http://nextgis.com/nextgis-qgis/).
GDAL python bindings working, gdal_merge also included.
This is previous QGIS LTR release 2.18.25, but with fresh GDAL 2.3.2 and
other libraries. This inst
Thanks for the help Even.
Is there a simple way to check if the python bindings are installed? I
installed GDAL through the QGIS installer. I tried running gdal_merge.py
after downloading the file from github and have had no success.
--
Jeremy A. Salerno
Weston Geophysical Corp.
181 Bedford St.
Jeremy,
> I cannot even find the gdal_merge.py file in
> /Library/Frameworks/GDAL.framework/Versions/Current/Programs/ or anywhere
> else in the gdal framework directory.
Should be reported to the creator of the package. I believe this is
William Kyngesburye (CC'ed) but I'm not completely sure.
Hi All,
When I type gdal_merge.py into Terminal, the output is -bash:
gdal_merge.py: command not found.
I installed 3.4.0 Madeira [from this link] for macOS 10.13 (
https://www.qgis.org/en/site/forusers/download), which came with a gdal
installer.
I cannot even find the gdal_merge.py file in
/Li
On lundi 12 mars 2018 05:55:10 CEST Ian Reese wrote:
> No matter which variation of merge I run, those regions that once contained
> 'nodata' or '-' are converted to '0' and the nodata value is not
> retained after the merge. When I load the test_merge_wnodata.tif into
> QGIS, those regions on
Hi Gdal,
I am having some issues with gdal_merge.py.
When I merge two tifs together, the original nodata value is converted to 0, no
matter what that original no data was. Here is my test case:
Data:
https://data.linz.govt.nz/x/9iitN4 DEM_BA32_3501_2013
https://data.linz.govt.nz/x/WLurgo DEM
I run the echo %pythonpath% and it displays the right directions. And I add the
system python direction before the gdal python direction, it still reports the
same error. I installed by run the gdal-1.10.1.win32-py2.7.msi.
发自我的 iPhone
在 2014-3-10，14:13，Chaitanya kumar CH 写道：
> Ridge,
>
> How
On 10/03/2014 05:47, ridgewang wrote:
> Hi,
> I want to use gdal_merge.py to merge two image files. But it reports
> cannot load _gdal library and %1 is not a valid win32 module. Here the %1
> means the _gdal, maybe. In python CUI, I run 'import osgeo.gdal' or 'import
> gdal' command,
Ridge,
How did you install GDAL?
This usually happens when python cannot find the gdal libraries. Setting
PYTHONPATH env variable may help.
On Mon, Mar 10, 2014 at 10:17 AM, ridgewang wrote:
> Hi,
> I want to use gdal_merge.py to merge two image files. But it reports
> cannot load _gdal l
Hi,
I want to use gdal_merge.py to merge two image files. But it reports
cannot load _gdal library and %1 is not a valid win32 module. Here the %1
means the _gdal, maybe. In python CUI, I run 'import osgeo.gdal' or 'import
gdal' command, it reports the same error information.
I u
Yes, anaconda is a python distribution. Unfortunate that those don't play
nice.
Confusion was indeed the problem. I deleted the /usr/local/lib/python2.7
folder and uninstalled the brew gdal. I reinstalled GDAL Complete 1.10
framework and was getting an import error:
iMac:~ $ gdal_merge.py
Tracebac
Looks like a confused gdal and python installation mess...
If you're using my GDAL framework, it uses my UnixImageIO framework for libpng.
And, the included gdal-python uses the system python.
But according to the error python is looking for python modules (thus
gdal-python) in /usr/local. Th
anyone have any suggestions?! I'm at a complete loss how to troubleshoot.
Dominik Schneider
o 303.735.6296 | c 518.956.3978
On Tue, Jul 2, 2013 at 10:52 AM, Dominik Schneider <
dominik.schnei...@colorado.edu> wrote:
> Hi,
> I am trying to run:
> gdal_merge.py -init - -n 2001 -o
> MOD09GA.
Hi,
I am trying to run:
gdal_merge.py -init - -n 2001 -o
MOD09GA.A2012001.h08v05.005.NRTsnow_fraction.tif.1
MOD09GA.A2012001.h08v05.005.NRTsnow_fraction.tif
The Error:
Traceback (most recent call last):
File "/Library/Frameworks/GDAL.framework/Programs/gdal_merge.py", line
36, in
import
Hi Aaron,
Rasters are rectangular grids of data. But the data is not always
rectangular. It may have holes. It may be skewed, especially if it was
warped from another projection. To note the areas with these hole and areas
with no information, we define a certain pixel value. We call it nodata
val
It looks like using -srcnodata 0 -dstnodata 5 worked using gdalwarp. Thanks
for the help!
What exactly do the 'values' mean?
Thanks,
Aaron
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/gdal-merge-py-on-large-Tiff-s-gdalwarp-not-working-properly-tp4986729p4987481.html
S
Aaron,
This could be solved by using the nodata attribute. You can set the nodata
value in the source in the vrt file[1]. The vrt driver will ignore the
nodata areas.
If you have problem with that, rerun the gdalwarp operation and make sure
you get the nodata values.
Use the -srcnodata and -dstnod
Hi Jean-Claude. Thanks for the idea. Unfortunately it made the split a little
larger. Is it possible to make the borders transparent, or remove them so
the blending works properly as it does in gdal_merge.py?
Thanks,
Aaron
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/gdal
On 07/08/2012 07:48 PM, aphunter wrote:
> Definitely, thanks for the help. I am sort of new to this stuff. Below is the
> imagery from the small images I'm testing with.
Hi,
Since you have reprojected one of the images, it has a black border. Try
to change the images order in the gdalwarp command.
Definitely, thanks for the help. I am sort of new to this stuff. Below is the
imagery from the small images I'm testing with.
Here is the info for the reprojected image (EPSG26910 -> EPSG26911)
Driver: GTiff/GeoTIFF
Files: 26910_rs.tif
Size is 4577, 11883
Coordinate System is:
PROJCS["NAD83 / UTM
Aaron,
Can you provide some info about the images?
The gdalinfo output of each dataset and, if possible, the small images.
On Sun, Jul 8, 2012 at 12:08 PM, aphunter wrote:
> Thanks for the suggestion. Unfortunately building the .vrt file as you
> suggested, and using gdal_translate, gives me th
Thanks for the suggestion. Unfortunately building the .vrt file as you
suggested, and using gdal_translate, gives me the same fractured image that
gdal_warp does. I am not sure why gdal_merge.py works properly while the
others don't.
--
View this message in context:
http://osgeo-org.1560.n6.nabbl
Aaron,
You can use a combination of gdalbuildvrt and gdal_translate.
gdalbuildvrt both.vrt one_26911.tif two_26911.tif
gdal_translate both.vrt both.tif
On Sun, Jul 8, 2012 at 5:44 AM, aphunter wrote:
> Hi community!
>
> Here's my issue. I currently have two halves of California, one in
> EPSG:
Hi community!
Here's my issue. I currently have two halves of California, one in
EPSG:26910, and one in EPSG:26911. I successfully reprojected the 26910
segment into zone 26911, and if I make the images small, to test,
gdal_merge.py works properly. See below:
http://osgeo-org.1560.n6.nabble.com/
Am 29.06.2010 18:23, schrieb Chaitanya kumar CH:
Stefan,
I haven't tested the script but doesn't the current code copy the
alpha band? If it does, it might be more preferable to copy all the
pixels and the alpha band.
Yes the current code copies the alpha band, but it uses the same nodata
set
Stefan,
I haven't tested the script but doesn't the current code copy the alpha
band? If it does, it might be more preferable to copy all the pixels and the
alpha band.
Please create a ticket at http://trac.osgeo.org/gdal/newticket and attach
your patch.
On Tue, Jun 29, 2010 at 8:19 PM, Stefan K
Hi,
gdal_merge.py doesn't handle tiff files with alpha masks so I've added
this functionality.
My patch changes the behaviour of gdal_merge as follows:
- If a band is recognized as Alpha Band it is automatically treated as
having a NODATA value of 0.
I'm not sure if this is the way to go. But
Luca Fasano wrote:
Hi list,
I'm trying to use gdal_merge.py of GDAL 1.6.3 version.
I encountered some problem merging datasets represented in GDAL
subdataset format (i.e. DRIVERNAME:FILENAME://SUBDATASETS). In
particular I'm trying to merge two HDF5 subdatasets.
In this case the script crashes re
Hi list,
I'm trying to use gdal_merge.py of GDAL 1.6.3 version.
I encountered some problem merging datasets represented in GDAL
subdataset format (i.e. DRIVERNAME:FILENAME://SUBDATASETS). In
particular I'm trying to merge two HDF5 subdatasets.
In this case the script crashes returning strange messa
Dori wrote:
Hi,
I have used gdal_merge.py to stitch geotiff images created with a 3rd
party software for a couple of years now.
These programs were moved to new hosts a while ago and from there on,
although the stitching works the output image seems to loose the
projection information when the
Hi,
I have used gdal_merge.py to stitch geotiff images created with a 3rd party
software for a couple of years now.
These programs were moved to new hosts a while ago and from there on,
although the stitching works the output image seems to loose the projection
information when they are created at
Andrew Brooks wrote:
On Fri, 24 Oct 2008 19:21:22 +0100, Even Rouault <[EMAIL PROTECTED]> wrote:
my guess is that your merged1.tif TIFF has areas which are not initialized
(black/transparent areas). gdal_merge.py probably doesn't write any data in
them, thus leading to missing blocks in the fil
On Fri, 24 Oct 2008 19:21:22 +0100, Even Rouault <[EMAIL PROTECTED]> wrote:
> my guess is that your merged1.tif TIFF has areas which are not initialized
> (black/transparent areas). gdal_merge.py probably doesn't write any data in
> them, thus leading to missing blocks in the file.
Thanks for the
Andrew,
my guess is that your merged1.tif TIFF has areas which are not initialized
(black/transparent areas). gdal_merge.py probably doesn't write any data in
them, thus leading to missing blocks in the file. GDAL support them in
reading, but those kind of tiff files are maybe not supported by
Hello
When I use gdal_merge.py to merge two files and write a geotiff
it creates a file which PhotoshopCS3 cannot read. Yet the result
of passing that tiff through gdal_translate produces a different
tiff (of a completely different size) which *is* readable.
% gdal_merge.py -v -o merged1.tif -of
35 matches
Mail list logo
