New answers tagged

0

Seems like there might be an issue when you: Save the output as a temporary file and Check the Open output file after running algorithm option. I would suggest saving the output as a normal file instead of a temporary one, works for me.


1

You need to use the -dstalpha option to gdalwarp e.g.: gdalwarp -cutline INPUT.shp -crop_to_cutline -dstalpha INPUT.tif OUTPUT.tif This will add an alpha band to the output tiff which masks out the area falling outside the cutline. P.S. duplicate question


0

The error itself means that GDAL fails when it tries to transform coordinates from the source srs into target srs. The source srs is supposed to be EPSG:4326 but by looking at the corner coordinates it can't be right. Corner Coordinates: Upper Left ( 0.0, 0.0) Lower Left ( 0.0,12698.0) Upper Right ( 1091.0, 0.0) Lower Right ( 1091.0,12698.0) ...


1

You might run into a problem with the antipodal point of the projection. If you clip your raster to the area of validity (that is Europe), it works: gdal_translate -projwin -26 75 44 28 -of GTiff bluemarble.tif bluemarble-Europe.tif gdalwarp -overwrite -s_srs EPSG:4326 -t_srs EPSG:3035 -of GTiff bluemarble-Europe.tif bluemarble-3035.tif You might take ...


-1

I have seen the same problem. In my case the raster and the clip vector are both in the same space so there is no need for a transformation. It worked with earlier versions of GDAL so I suggest regressing to 2.02 and it will work.


0

I didn't figure out how to make it work with the gdalwarp, but I downloaded VDatum and did a single point coversion. After which it identified that I needed to use the geoid12b. Then I found in the VDatum directory the geoid12b/*.gtx files. Opened the NED file in gdal and the geoid file in gdal and created a matching projection of the geoid into the NED and ...


1

You might get unexpected results because your dataset crosses the 180° meridian. As a consequence, the tile is squeezed around the globe when reprojected to WGS84. To avoid that, you have to cut the raster data at the +/- 179.99° meridian. The following batch works with pure GDAL: gdal_translate HDF4_EOS:EOS_GRID:"MOD11A1.A2004091.h34v10.005.2007261231833....



Top 50 recent answers are included