Each set of 3 images below should be read such as "grey (band) + opacity (band) = transparent result". You can test these processes within minutes via the associated github hosted makefile. Process #3 is the one which I recommend, with a threshold between 170 (keeps strong shadows) and 220 (keeps all shadows). Process 3 provides the strongest ...
If you don' want the values above 255 to be cut, you need to scale them down. For that purpose gdal_translate provides the option -scale:
From the Manual:
-scale [src_min src_max [dst_min dst_max]]:
Rescale the input pixels values from the range src_min to src_max to the range dst_min to dst_max. If omitted the output range is 0 to
255. If ...
You can do this using GDAL, it directly supports XYZ format. It doesn't matter if your coordinates are UTM, gdal_translate will output in the same coordinate system.
So to convert to GeoTIFF is as simple as:
gdal_translate test.xyz test.tif
Look at the GeoTIFF doc for output options (such as compression) and the gdal_translate doc for more usage info. In ...
Since GDAL 2.1 (more info here) GDAL and OGR utilities can be used as library functions, so this task is incredibly simple now:
from osgeo import gdal
ds = gdal.Open('original.tif')
ds = gdal.Translate('new.tif', ds, projWin = [-75.3, 5.5, -73.5, 3.7])
ds = None
From the command line you can write
for %i in (*.tif) do gdal_translate -of "ENVI" %i %i.bil
The command above will convert all tif to bil in the actual directory. The output name will be some_name.tif.bil.
From a batch (.bat) file you must use double percent sign for variables.
for %%i in (*.tif) do gdal_translate -of "ENVI" %%i %%i.bil
If you would ...
gdal_translate can not use Multithreading for computing. But it can use multithreaded compression for some formats e.g. for GeoTiff using -co NUM_THREADS=ALL_CPUS
NUM_THREADS=number_of_threads/ALL_CPUS: (From GDAL 2.1) Enable multi-threaded compression by specifying the number of worker threads. Worth for slow compressions such as DEFLATE or LZMA. Will be ...
For aerial images like this, I suggest using TIFFs with JPEG compression. That way, there are no separate world files needed, all the metadata is stored in the TIFF as tags. Note, this will only work on RGB files with 8 bits per band.
It's lossy, so it's not suitable for DEMs (for those, lossless LZW will reduce file size by ~30 % to 40% in my experience)
You can do that in Python Console of QGIS by using a QgsRasterPipe object (pipe) for setting a renderer clone of the image employed as active layer before to use the 'writeRaster' method of QgsRasterFileWriter class (you don't need gdal_translate).
I used the following code:
layer = iface.activeLayer()
extent = layer.extent()
width, height = layer.width()...
Firstly, crop the image source (coords are expressed in pixels here) with:
gdal_translate -srcwin 115 18 1360 2156 2104.gif 2104_cropped.tif
Then, transform the known WGS84 coordinates of the upper left and lower right corners to the "WGS 84 / World Mercator" projection (EPSG:3395):
cs2cs +init=epsg:4326 +to +init=epsg:3395
I haven't found any specific commandline utility that can report if a tiff is tiled or striped. At least not directly or in a grepable form like TILED=YES.
There should be enough information in gdalinfo to make that decision, however.
I have a landsat scene, each made with gdal_translate:
landsat_tiled.tif : -co TILED=YES
landsat_notiled.tif: -co TILED=...
I noticed that gdal2tiles numbers the tiles from south to north (according to the TMS specification), while Openstreetmap and others do it from north to south. For my personal use, I changed the code of gdal2tiles to get it right again.
See also: http://osgeo-org.1560.x6.nabble.com/gdal2tiles-tiles-in-wrong-hemisphere-and-or-Openlayers-problem-td3742809....
Another way to get the same result of a non-grey canvas more suitable for combining with other layers is the 'combined' option in gdaldem.
It performs a slope and hill shade and combines the two in one operation. Areas of 0 slope are white. Areas of 90 degree slope are black for the slope shade, with some illumination added by the hillshade layer.
Jasper driver is useless for big JPEG2000 files. OpenJPEG driver is OK if source JPEG2000 is tiled, otherwise you will need JP2ECW, JP2KAK, or JP2MrSID driver. Check your drivers with gdalinfo --formats and use --config GDAL_SKIP for skipping the first JP2 drivers from the list for selecting the driver you want to use.
Example output from GDAL compiled with ...
Unless you use os/shell specific operations i.e. grep etc... there's no way that I know of to do this from the command line with gdalinfo.
A python alternative is to use the GetDefaultRAT() method and output to XML (which is what gdalinfo does):
from osgeo import gdal
import xml.etree.ElementTree as et #I much prefer the lxml library
You will find the borders in degrees in the enclosed html file. gdalinfo can give you the same values, but these are the corners of the tif including the legend, not the map canvas you are interested in. Unfortunately, the map is in a lcc projection, and thus the borders do not follow the exact degree of latitude and longitude, and are not even rectangular.
Here's a quick script I put together to correct the cell size of a folder of GeoTiff rasters:
import os, sys
from osgeo import gdal
from osgeo import gdalconst
WorkingFolder = sys.argv # first command line argument
# change to a hard path like r'c:\your\path' or 'c:\\your\\path'
# without the r if it suits your purposes..
for f in os.listdir(...
I do not believe that you can avoid creating additional files with AAIGrid output. AAIGRid format does not have native internal support for projections and other metadata that GDAL needs in order to make a round trip and convert from AAIGrid back to the original format.
I would call gdal_translate from a script/batch file. For Windows write a batch file "...
I suggest a batch file using OSGEO4W shell or the latest GDAL binaries from gisinternals.
for %%N in (/work/120614/mg_1164/*.cub) DO gdal_translate %%N /work/temp/%%~nN.tif
Note: Use %%N in a batch file and %N when typing manually on the command line.
with gdal, you can color an image based on gdal_dem (color_relief)
the syntax of the color configuration file is derived from the one
supported by GRASS r.colors utility. ESRI HDR color table files (.clr)
also match that syntax. The alpha component and the support of tab and
comma as separators are GDAL specific extensions
aspect: aspect oriented ...
You can improve the result with this command line:
gdal_translate -of GTiff PARAmap1.pdf out1File.tif --config GDAL_PDF_DPI 300
According to http://www.gdal.org/frmt_pdf.html, the default is 150dpi.
For higher quality than 300dpi, you have to be very patient ;-)
I was able to extract vector data from USGS topo PDFs with ogr2ogr in Convert GeoPDF with ...
The gdal_translate document page http://www.gdal.org/gdal_translate.html may indeed give an impression that the values for Ground Control Points should be closed between brackets
[-gcp pixel line easting northing [elevation]]*
However, that is not the case as close reading reveals and correct syntax for your case is
gdal_translate -of GTiff -a_srs EPSG:...
It doesn't have to read the whole thing. GDAL is heavily geared to sensible access either line by line or block by block (for tiles). It won't matter if you are selecting bands, and no the answer won't change if it's compressed - but the real details will depend on which compression and which internal tiling is used. See "Reading Raster Data" here
I can't reproduce your issue with GDAL 2.2-dev (yesterday's trunk version from gisinternals.com).
I downloaded a rando Sentinel2 zip file from https://scihub.copernicus.eu/dhus/#/home. It happened to be "S2A_MSIL1C_20170129T110311_N0204_R094_T31UCT_20170129T110306.zip".
I unzipped the file and changed my working directory into
First of all, I'd move the two raster layers in the same working directory in order to skip the long paths in command line.
We can transform the elevation layer to the same CRS of the satellite image, i.e. EPSG:32630:
gdalwarp -t_srs EPSG:32630 full.tif full_32630.tif
Then we can compute the common area between the two rasters:
Windows photo is not a GIS viewer and it does not know anything about georeferencing. Therefore is considers pixels as square.
However, as you can see from the gdalinfo report the pixel x and y size are not equal
Pixel Size = (0.068380000000000,-0.119760000000000)
I would say that you image is correct, QGIS is doing the right thing as GIS viewer and ...
After testing, the -a_ullr flag assigns the outermost coordinates of your raster. That is, the corners of grid cells located in the corners of the grid.
gdal_translate -of GTiff -a_srs '+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs' -a_nodata -9999 -A_ullr -124.733333333333 52.8749999999999 52.8749999999999 24.9499999999999 infile.dat ...