Hot answers tagged gdalwarp
5
You could explicitly set the output coordinate range using the target extent option to gdalwarp (ie. "-te -180 -90 180 90") but you can also use the CENTER_LONG configuration option to force rewrapping around a new central longitude. Something like this:
gdalwarp -t_srs WGS84 ~/0_360.tif 180.tif -wo SOURCE_EXTRA=1000 \
--config CENTER_LONG 0
...
4
If you're using GDAL 1.8.0 (which I recommend because it adds a number of useful features), you can use:
gdalwarp -cutline "PG:dbname=gisdb" -csql 'select * from polytest where id=1' -crop_to_cutline -of GTiff -srcnodata -9999 -dstnodata -9999 src.tif dest.tif
Note the "-crop_to_cutline" parameter.
With gdalwarp, I have found it always pays to use ...
3
Your source coordinate system is most likely not defined in the CVS file that GDAL searches for proj4 strings. It looks like you might be able to pass the source EPSG as 3031 (from spatialreference.org)
Note that it looks like your input is in a local projection. Is this clipped from a larger raster?
To explicitly define the source you could just provide ...
3
I would not recommend using the MODIS sinusoidal projection in analysis. It would be prudent to project your MODIS data to something a bit more tractable. You can request MODIS in a projected geographic (lat/long) coordinate system on the MODIS Golbal Subsets site .
That said I have used this as my CRS for MODIS "+proj=sinu +R=6371007.181 +nadgrids=@null ...
3
I think its because there's no inverse Winkel-Tripel projection in Proj4.
You need the inverse to project a grid forward, since the target grid is derived by inverse projection from its grid points to the source grid.
If you did it the other way, by mapping each source grid to a grid square in the target projection, you wouldn't end up with a regular grid ...
3
It looks like your version of GDAL doesn't have the definition for Spherical Mercator, AKA Web Mercator, AKA Google Mercator. You could try using EPSG 900913 which is the old code for 3857 - you only need to run gdal_translate -a_srs EPSG:900913 ... on your sources.
But ideally you should get GDAL version 1.9.0
2
Regarding execution times: Lanczos is extremely slow, but other resampling algorithms produce similar (perhaps even better) results:
near (11s)
bilinear (17s)
average (27s, a bit soft)
bicubic (30s, called cubic in GDAL, text thickness sometimes odd)
antialias (45s, requires pil and numpy)
cubicspline (1m53s, way too soft)
lanczos (11m8s, extremely ...
2
gdal2tiles uses the bottom-left point of origin, not top-left, so the filename pattern is {zoom}/{x}/{tilenum-y}.png where tilenum is the number of vertical tiles for the zoom level.
It's also worth noting that gdal2tiles.py does not require the source data to be pre-warped, but it does require it to be RGB or RGBA.
2
You don't necessarily need pyramids, unless you have hundreds of GB of data. For lower amounts of data a mosaic should work just fine, provided you add inner tiling and overviews in your data.
Have a look here for directions:
http://demo.geo-solutions.it/share/foss4g2011/gs_steroids_sgiannec_foss4g2011.pdf
2
You can use gdal2tiles with the -k option to force a KML output. That will create a SuperOverlay you can open and visualize in Google Earth.
Here are some instructions you may want to reference:
https://developers.google.com/kml/articles/raster
2
Basically you need to cut the raster into two parts and piece them back together with a new offset/scale.
There's an example here of how to do that from [-180,180] to [0,360] with gdal_translate and the VRT driver:
http://trac.osgeo.org/gdal/wiki/UserDocs/RasterProcTutorial
Scan down to the "5 min tutorial" and the details are under "Virtual Files". It ...
2
How about using gdalwarp?
First copy the above well known text to 'target_srs.prf' (or whatever name you like). Then:
gdalwarp -t_srs target_srs.prf inputraster outputraster
Full documentation on gdalwarp is here. I think that you can safely omit the s_srs flag as gdal should read the inputraster to get the srs.
Alternatively, what is your ...
2
Try to specify the nodata-value from your input raster and set it for the output as well. Furthermore add the option -crop_to_cutline to make exact crops. More about the options here.
gdalwarp -srcnodata <in> -dstnodata <out> -crop_to_cutline -cutline INPUT.shp INPUT.tif OUTPUT.tif
2
You have to specifiy the path to gdalwarp (in the example below I took: "C:\python32\python.exe", but you have to change it to your intallation path) and change your call function like that:
call(['C:\Program Files\GDAL\gdalwarp.exe', '-t_srs ' + crs, '-dstnodata 0', '-q', '-cutline ' + mask, '-dstalpha', '-of GTIFF', input, output]).
or:
...
1
I assume you have data in EPSG:31276 MGI Balkans 6. The correct projection string is:
+proj=tmerc +lat_0=0 +lon_0=18 +k=0.9999 +x_0=6500000 +y_0=0 +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 +units=m +no_defs
There are some bugs in different QGIS installations which result in a projection string with only three non-zero ...
1
While I don't know why GDAL provides this overlap in functionality, be sure to set the cache for gdalwarp to make it really fast:
# assuming 3G of cache here:
gdalwarp --config GDAL_CACHEMAX 3000 -wm 3000 $(list_of_tiffs) merged.tiff
Be sure to not define more cache than having RAM on the machine.
1
I started digging into the gdal source found where I could make the changes but figured that I might not want to do it this way after all. What I decided to do instead (but have yet to do) was:
Iterate through the images, grabbing the bbox of each, then based on each bbox make groups of non-overlapping images. Then use gdalwarp to combine each ...
1
OK, I found the solution (work around). I realized, that I was working with an old version of gdalwarp, where the -cut_to_cropline option was not supported! Anyway I got an upgrade done and it seem to accept this option. I still got the "Cannot compute bounding box of cutline" error, that obviously has something to do with my cutline shape file. I removed ...
1
Try the combination of options from the link below. It worked for me and shows the correct transparency in QGIS. You can grab the gralwarp command-line from there or try using the UI.
Clip a Raster in an Irregular Shape using QGIS
1
EDITED after feedback from question poster.
Step 1: if files are not georeferenced, try the methods described here,
georeferencing using gdal tools.
Also world files could work for weither png or tif (http://en.wikipedia.org/wiki/World_file; http://www.gdal.org/gdal_translate.html).
Step 2: two methods could work for the clipping. Trying gdaltranslate ...
1
Can you do it for just one vector? If you can its easy to batch it.
eg if this works for you:
v.transform input=in_vector_1 output=out_vector_1 xshift=11 yshift=12
then you can run this to one-shot them all:
for i in $(seq 1 74); do
echo Transforming in_vector_$i
v.transform input=in_vector_$i output=out_vector_$i xshift=11 yshift=12
echo ...
1
There are a few ways to do this. One is through arcCatalog 10.1 and the new mosiac datset option. Under the Product Properties drop down there are options to select each band and the min/max values for each band.
Identify what the highest and lowest pixel values are for the data that you do not want. List them for each band.
The second option is to use ...
1
I can't answer all your questions, but I have noticed a couple of things that might help. First, your apparent off-by-0.04 is because by default, GDAL assumes the centre of a pixel represents the coordinate, not the corner. So by shifting your xllcorner and yllcorner by -0.02 will end up with the right coverage.
Secondly, most CRSs that I'm aware of have a ...
1
I think you need to specify the -ts option rather than the -tr option. In other words, you know the exact size of your output array, so specify it rather than let GDAL calculate it. Otherwise, gdalwarp tries to calculate it (note sure where this is in the codebase, but see this.
1
The reason you seem to be getting very small values is because your original image is projected, so it uses linear units - which in this case PROJ4 I think defaults to metres - rather than degrees. So you're specifying a ~680 square metre part of the western US.
Now, how you can determine the right coordinates to use is a tricky matter because your image ...
1
I don't know if there is something wrong in your command strings, but you can also use QGIS, who has nice GUIs for the gdal utilities and it works also in batch mode. Using QGIS raster tools (gdal tools) it useful also because when you choose the parameters it show you a window with the actual CLI string that will be used.
Only top voted, non community-wiki answers of a minimum length are eligible
