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
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
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
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
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/
