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/
10 matches
Mail list logo
