I use gdalwarp to get a planisphere with the EPSG 4326 projection (equidistant cylindrical projection). Before with GDAL 2 I had no problem to use gdalwarp with this command :
gdalwarp -te lonMin latMin lonMax latMax -t_srs EPSG:4326 sphere.tiff planisphere.tiff
Example
gdalwarp -te -100 -10 -60 10 -t_srs EPSG:4326 sphere.tiff planisphere.tiff
But now with GDAL 3.0.4 it returns an error like if I made a mistake in coordinates.
Creating output file that is 0P x 0L. ERROR 1: Attempt to create 0x0 dataset is illegal,sizes must be larger than zero.
Do we need to install something else now? (maybe because now GDAL seems to use PROJ6).
If someone have the solution or an idea, I will be glad to hear it. Thanks !
Alright gdalwarp works well, this problem is due to gdal_translate.
Since GDAL 3, if you extract an image from netCDF file, it doesn't georeference automatically your tiff image. This is why gdalwarp wouldn't work because it was impossible to crop my image.
So if you have a non-georeferenced image, you have to georeference your image with gdal_translate.
Related
I am using gdal_rasterize and ogr2ogr with a goal to get a partial raster of .gpkg file.
With first command I want to clip a smaller area of a large map.
ogr2ogr -spat xmin ymin xmax ymax out.gpkg in.gpkg
This results in a file that with command ogrinfo out.gpkg gives expected output by listing the layers numbers and names.
Then trying to rasterize this new file with:
gdal_rasterize out.gpkg -burn 255 -ot Byte -ts 250 250 -l anylayer out.tif
results in: ERROR 1: Cannot get layer extent when tried with any of the layers names given by ogrinfo
Using the same command on the original in.gpkg doesnt give errors and results in expected .tiff file raster.
ogr2ogr --version GDAL 2.4.2, released 2019/06/28
gdal_rasterize --version GDAL 2.4.2, released 2019/06/28
This process should at the end be implemented with the gdal C++ API.
Are the commands given some how invalid this way, how?
Should the whole process be done differently, how?
What does the ERROR 1: Cannot get layer extent mean?
I’m trying to convert a full globe Robinson Projection to Mercator. For example, I use this image.
First, I apply geo-tagging:
gdal_translate -a_ullr -180 90 180 -90 -a_srs ESRI:54030 source.jpg source_tagged.tif
and finally warp it to Mercator:
gdalwarp -t_srs ESRI:54030 -s_srs EPSG:3857 source_tagged.tif target.tif
The outcome is slightly stretched vertically but nowhere near proper Mercator. What am I doing wrong?
There are a couple of issues in your commands. The first is that -180 90 isn't in the top left corner pixel of global Robinson projection GeoTIFFs. The top left corner would be something like -338.2187147689 90, and the bottom right would be 338.2187147689 -90. However, you're also specifying your srs as ESRI:54030, so those bounds need to be in projected coordinates, not lat/lons. The command to generate a GeoTIFF from your image would be:
gdal_translate -a_ullr -17005833.3305252 8625154.47184994 17005833.3305252 -8625154.47184994 -a_srs ESRI:54030 source.jpg source_tagged.tif
Your second command has the -t_srs and -s_srs switched. Given that you're projecting to EPSG:3857, you'll also need to provide bounds since Mercator goes to infinity at the poles. So the updated command will look like:
gdalwarp -s_srs ESRI:54030 -t_srs EPSG:3857 -te -180 -81 180 81 -te_srs EPSG:4326 source_tagged.tif target.tif
I made the following projected image from your example using these commands (cropping the whitespace in the image prior to running them).
i've been trying to convert a geotiff image to .rst and again back to geotiff (i need both ways and figured i could check wether the Output is equal to the original).
Problem is: the output Image is shifted and i really have no clue what im doing wrong.
here is what i do:
gdal_translate -of rst -a_srs EPSG:32632 Input.tif Output.rst
gdal_translate -of gtiff -a_srs EPSG:32632 Output.rst Output.tif
now the Output.tif is shifted upward by the size of the Image. My assumption is that somehow coordinates are being mixed up and the top left corner of the Input Image is used as the bottom left corner for the Output.
Does somebody have a clue how to fix this?
Thank you in advance.
Try being explicit about what the output corner coordinates should be. To assign/override the georeferenced bounds of the output file add the -a_ullr option and provide corner coordinates in the form of ulx uly lrx lry. GDAL usually will generate these implicitly from the metadata of the input file, but I've noticed that prescribing them myself sometimes eliminates these issues.
For example:
gdal_translate -of gtiff -a_srs EPSG:32632 -a_ullr ulx uly lrx lry Output.rst Output.tif
I have a small pixel map and want to resize it for better readability.
Using mogrify -resize 1600% I get an interpolated image: .
What I'm trying to get is this: .
Can this be done by ImageMagick or any other open source command line tool?
I finally found the solution: using -scale instead of -resize does the trick. It is 'hidden' under the heading Scale - Minify with pixel averaging, therefore I overlooked it at first, searching for magnification instead of minification.
This worked for me:
convert input.png -interpolate Integer -filter point -resize "10000%" output.png
Explanation:
Interpolation method "Integer" just picks a nearest value.
Filter 'point' is also necessary, but I do not know why.
display -sample 400% worked for me.
"Change the image size simply by directly sampling the pixels original from the image. When magnifying, pixels are replicated in blocks. When minifying, pixels are sub-sampled (i.e., some rows and columns are skipped over)."
https://imagemagick.org/script/command-line-options.php#sample
To keep the original values of the input image and avoid any blend or bluriness, you can use -interpolate nearest-neighbor or -interpolate integer.
It only works along -interpolative-resize. Be aware that -resize does not work correctly with -interpolate. You can check here on the imagemagick docs.
e.g.
convert input.png -interpolate nearest-neighbor -interpolative-resize 1600% output.png
I'm using gdal to create different kinds of layers, such as color reliefs and hillshades, and Mapnik to combine them into a single image to use as texture for the 3D dem model obtained from a single .hgt file.
Premising that I'm new to gdal, I'm facing some problem with the hillshade layer.By using the gdal command:gdal_translate N44E007.hgt N44E007.tif
I get the N44E007.tif file, which in IrfanView looks like this
With the following gdal command:gdaldem hillshade -of PNG .\tif\N44E007.tif .\hillshade_png\N44E007_hillshade.png
The N44E007_hillshade.png file I get is the following
How can I prevent gdal from creating these artifacts in the hillshade .png?
I'm using Windows 7 and cmd.
Update 1
This is the image I get by replacing gdal_translate N44E007.hgt N44E007.tif with gdalwarp -t_srs EPSG:32632 -r bilinear N44E006.hgt N44E006.tif
The problem is that the reprojected image is slightly rotated and stretched. How can I get a squared and straight image to use as texture for a 3d plane?
The reason for the artefacts in the first attempt is because the raster horizontal distance units are in degrees, and the vertical are in meters. You can use a scale option to normalise horizontal and vertical distance units, e.g. try:
gdaldem hillshade -s 111120 -compute_edges -of PNG N44E007.hgt N44E007_hs.png
The second attempt (Update 1) reprojects to WGS84 UTM zone 32, which is a transverse Mercator projection centred on a meridian at 9°E, which is close to the SRTM raster, which is centred on 7.5°E. Since the two meridians are not the same, it is expected the raster to be rotated. And it is stretched since the true distance of degrees are not equal in N-S and E-W directions, except at the equator.