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
Related
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 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.
I have a big GeoTIFF that I want to stream through a WMS within GeoServer (v.2.11). The size of the image is about 7GB, consisting on a very large high resolution RGB image. I have allowed enough heap space within JVM in order to display the imagery. However, I would like to compress the image so it can be more responsive when exploring through and so it will allocate less memory. I have followed some of the recommendations here.
My strategy was to compress the GeoTIFF with JPEG compression and use that as a data store in GeoServer. However, this seems not to work. This is the gdal command I have used to translate the image:
gdal_translate -of GTiff -co "BIGTIFF=YES" -co "COMPRESS=JPEG" -co "TILED=YES" -co "BLOCKXSIZE=512" -co "BLOCKYSIZE=512" -a_srs "EPSG:3057" D:\raster\image.tif
D:\raster\image_translate.tif
When previewing the image with openlayers, I got nothing, just a blank basemap. The log from GeoServer told me that something in the projection went bad:
2017-06-09 13:16:47,551 INFO [geoserver.wms] -
Request: getServiceInfo
2017-06-09 13:16:47,561 WARN [lite.gridcoverage2d] - Could not reduce the grid geometry inside the valid area bounds: ReferencedEnvelope[-1.7976931348623157E308 : 1.7976931348623157E308, -85.0 : 85.0]
Grid geometry isGridGeometry2D[GeneralGridEnvelope[0..357, 0..357], PARAM_MT["Affine",
PARAMETER["num_row", 3],
PARAMETER["num_col", 3],
PARAMETER["elt_0_0", 0.7353351955307262],
PARAMETER["elt_0_2", 584219.1848475977],
PARAMETER["elt_1_1", -0.7353351955307262],
PARAMETER["elt_1_2", 383937.61122240225]]]
2017-06-09 13:16:47,566 ERROR [geoserver.ows] -
org.geoserver.platform.ServiceException: Error rendering coverage on the fast path
I then tried to use another compression strategy with GDAL, i.e. "DEFLATE":
gdal_translate -of GTiff -co COMPRESS=DEFLATE -co PREDICTOR=2 -co ZLEVEL=9 -co "BIGTIFF=YES" -a_srs "EPSG:3057" D:\raster\image.tif D:\raster\image_translate2.tif
And that worked when previewing in openlayers. Here is the GeoServer log:
2017-06-09 13:28:27,137 INFO [geoserver.wms] -
Request: getServiceInfo
2017-06-09 13:28:27,146 WARN [lite.gridcoverage2d] - Could not reduce the grid geometry inside the valid area bounds: ReferencedEnvelope[-1.7976931348623157E308 : 1.7976931348623157E308, -85.0 : 85.0]
Grid geometry isGridGeometry2D[GeneralGridEnvelope[0..357, 0..357], PARAM_MT["Affine",
PARAMETER["num_row", 3],
PARAMETER["num_col", 3],
PARAMETER["elt_0_0", 0.7353351955307262],
PARAMETER["elt_0_2", 584219.1848475977],
PARAMETER["elt_1_1", -0.7353351955307262],
PARAMETER["elt_1_2", 383937.61122240225]]]
2017-06-09 13:28:27,231 INFO [geoserver.wms] -
Request: getMap
I have also tried to perform gdal_translate using JPEG compression and no tiling, and I got also errors with the GeoServer log and the openlayers preview displayed nothing.
So my question is, what is the best strategy to compress GeoTIFF files to be used in a WMS? At the moment, seems that DEFLATE is the only one working, but the compression is not the best. Has anyone been able to successfully upload a JPEG compressed GeoTIFF to Geoserver?
If it's any help the way I do it is as follows.
First I chop the raster up into smaller tiles, size is not important, for me it's generally either 256x256, 512x512 or 1024x124.
I use a number of different programs from gdal2tiles.py to my own homegrown c# apps.
What's important is that the tiles are square.
Once I have the tiles in a folder, I then use gdaltindex
This creates a shapefile with one square for each tile, correctly georeferenced (assuming your raster was) along with the name of each tile, I usually tell gdaltindex to write absolute paths to the shapefile.
I then reference the shape as a tile layer in mapserver, I can't say if geoserver will accept a shape based tile index, but since gdal can make them and the other WMS based server available open source (mapserver) can use them, then I would be very suprised if geoserver was not able to use them.
This would work in the case of tiff greater than 2GB. GeoServer can efficiently deal with large TIFF with overviews, as long as the TIFF is below the 2GB size limit.
Using image pyramid makes the tiff load faster as it makes multiple mosaic of images at different zoom levels.
Use the following command:-
mkdir bmpyramid
gdal_retile.py -v -r bilinear -levels 4 -ps 2048 2048 -co "TILED=YES" -co "COMPRESS=JPEG" -targetDir bmpyramid bmreduced.tiff
You can check here
https://docs.geoserver.org/stable/en/user/tutorials/imagepyramid/imagepyramid.html
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.