Tag Info

Hot answers tagged


For merely converting a raster from one format to another, many of the GDAL tools will do that along with their specialized functions so either GDALWARP or GDAL_TRANSALTE will do fine for your purposes (which also explains why they give you the same error). The information you mention in the documentation in your links is applicable to using GDAL. Most of ...


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


Using the GRASS r.out.gdal module, you specify createopt="TFW=YES" to get a *.tfw world file. When exporting with type=UInt16 you should also get the proper colors saved into the geotiff. (I don't know specifically if Adobe iluustrator will read those tif color ramp headers)


All GRASS color tables formats (v.6.4) are in this link: https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/lib/gis/colors/ If you have GRASS 6.4 in Linux, they are in /usr/lib/grass64/etc/colors. For example, if you used the elevation table, this is the format: 0% 0 191 191 20% 0 255 0 40% 255 255 0 60% 255 127 0 80% 191 127 ...


Found a quick solution - replacing "-hidenodata" with "-srcnodata 0" in the .vrt build: gdalbuildvrt -srcnodata 0 mosaic.vrt geo_pict20140910_131*


In the past, I have used a script to unzip the kmz and extract the bounding box coordinates from the KML and used gdal_translate to georeference the image The LatLonBox coordinates will map to the following values when using gdal_translate ulx = west uly = north lrx = east lry = south gdal_translate -a_ullr ulx uly lrx lry -a_srs EPSG:4326 input.jpg ...

Only top voted, non community-wiki answers of a minimum length are eligible