although there are several pages dedicated to this task, it seems that i can not make that work. I have a non georeferenced tif file which I provide you the output from gdalinfo
Driver: GTiff/GeoTIFF
Files: Arctic_r05c02.2017235.terra.250m.tif
Size is 4096, 4096
Coordinate System is `'
Metadata:
TIFFTAG_SOFTWARE=ppm2geotiff v0.0.9
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 4096.0)
Upper Right ( 4096.0, 0.0)
Lower Right ( 4096.0, 4096.0)
Center ( 2048.0, 2048.0)
Band 1 Block=4096x1 Type=Byte, ColorInterp=Red
Band 2 Block=4096x1 Type=Byte, ColorInterp=Green
Band 3 Block=4096x1 Type=Byte, ColorInterp=Blue
I do have the corner coordinate extention in lat/lon. Hence I am creating Ground Control Points with thee following command:
gdal_translate -of GTiff -gcp 0 0 -180.0000 +63.1066 -gcp 0 4096 -161.5651 +68.5979 -gcp 4096 0 +161.5651 +68.5979 -gcp 4096 4096 -180.0000 +76.3728 input.tif output.tif
which results to:
Driver: GTiff/GeoTIFF
Files: Arctic_r05c02.2017235.terra.250mproj.tif
Size is 4096, 4096
Coordinate System is `'
GCP Projection =
GCP[ 0]: Id=1, Info=
(0,0) -> (-180,63.1066,0)
GCP[ 1]: Id=2, Info=
(0,4096) -> (-161.5651,68.5979,0)
GCP[ 2]: Id=3, Info=
(4096,0) -> (161.5651,68.5979,0)
GCP[ 3]: Id=4, Info=
(4096,4096) -> (-180,76.3728,0)
Metadata:
TIFFTAG_SOFTWARE=ppm2geotiff v0.0.9
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 4096.0)
Upper Right ( 4096.0, 0.0)
Lower Right ( 4096.0, 4096.0)
Center ( 2048.0, 2048.0)
Band 1 Block=4096x1 Type=Byte, ColorInterp=Red
Band 2 Block=4096x1 Type=Byte, ColorInterp=Green
Band 3 Block=4096x1 Type=Byte, ColorInterp=Blue
The next step is to resample with gdalwarp in order to create a projected file.
gdalwarp -r near -s_srs epsg:4326 -t_srs epsg:3413 -tr 250 250 input.tif output.tif
But the file seems distort:
Any idea what I can further do? Is there a way to directly change the corner coordinates inside the tiff file instead of adding GCP's? Would that help?
Some more information which i forgot. The data can be downloaded at:
https://lance-modis.eosdis.nasa.gov/imagery/subsets/?subset=Arctic_r05c02.2017235.terra.250m
and for the bounding box definition:
https://lance-modis.eosdis.nasa.gov/imagery/subsets/?subset=Arctic_r05c02.2017235.terra.250m.met
Since the box definition from NASA's side looks a bit odd, i tried the same procedure for the following tile:
https://lance-modis.eosdis.nasa.gov/imagery/subsets/?subset=Arctic_r04c03.2017235.terra.250m
and box definition:
https://lance-modis.eosdis.nasa.gov/imagery/subsets/?subset=Arctic_r04c03.2017235.terra.250m.met
Although the box looks ok the following image was produced:
The data you downloaded is already projected (in epsg:3413), you are assigning a projection (epsg:4326) and bounding-box which is not correct.
You can view the correct settings by visiting:
https://lance-modis.eosdis.nasa.gov/imagery/subsets/?subset=Arctic_r05c02.2017235.terra.250m.gdal
About halfway down on the page you'll see the gdal_translate command, use that with your in- and outputs.
For example:
gdal_translate -of GTiff -outsize 4096 4096 -projwin -2097152 2097152 -1048576 1048576 -a_srs "+proj=stere +lat_0=90 +lat_ts=70 +lon_0=-45 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs" Arctic_r05c02.2017235.terra.250m.tif Arctic_r05c02.2017235.terra.250m_output.tif
Related
I run a complex cpp application, where gdal (3.5.3) is a part to get elevation data from eudem v 1.1. The eudem files are quite large and I want to reduce their file size, since I don't need an accuracy of 25m. This is one file I use and want to downsize.
gdalinfo E20N20.TIF
Driver: GTiff/GeoTIFF
Files: E20N20.TIF
Size is 40000, 40000
Coordinate System is:
PROJCS["ETRS89_ETRS_LAEA",
GEOGCS["ETRS89",
DATUM["European_Terrestrial_Reference_System_1989",
SPHEROID["GRS 1980",6378137,298.2572221010042,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6258"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4258"]],
PROJECTION["Lambert_Azimuthal_Equal_Area"],
PARAMETER["latitude_of_center",52],
PARAMETER["longitude_of_center",10],
PARAMETER["false_easting",4321000],
PARAMETER["false_northing",3210000],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]
Origin = (2000000.000000000000000,3000000.000000000000000)
Pixel Size = (25.000000000000000,-25.000000000000000)
Metadata:
AREA_OR_POINT=Area
DataType=Elevation
Image Structure Metadata:
COMPRESSION=LZW
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 2000000.000, 3000000.000) ( 20d45'24.21"W, 45d41'42.74"N)
Lower Left ( 2000000.000, 2000000.000) ( 16d36'13.25"W, 37d23'21.20"N)
Upper Right ( 3000000.000, 3000000.000) ( 8d 7'39.52"W, 48d38'23.47"N)
Lower Right ( 3000000.000, 2000000.000) ( 5d28'46.07"W, 39d52'33.70"N)
Center ( 2500000.000, 2500000.000) ( 12d41'50.60"W, 43d 6' 4.82"N)
Band 1 Block=128x128 Type=Float32, ColorInterp=Gray
NoData Value=-3.4028234663852886e+38
Metadata:
BandName=Band_1
RepresentationType=ATHEMATIC
```
I tried the following cmd, but w/out success. Its probably about wrong ts or tr values;
```
gdalwarp -r average -tr 1024 1024 -wm 4096 -multi -wo NUM_THREADS=ALL_CPUS -co TILED=YES \
-co NUM_THREADS=ALL_CPUS E20N20.TIF dz_E20N20.TIF
Creating output file that is 977P x 977L.
Processing E20N20.TIF [1/1] : 0Using internal nodata values (e.g. -3.40282e+38) for image E20N20.TIF.
Copying nodata values from source E20N20.TIF to destination dz_E20N20.TIF.
ERROR 1: Integer overflow : nSrcXSize=19989, nSrcYSize=19989
ERROR 1: Integer overflow : nSrcXSize=20012, nSrcYSize=19989
```
I'm lost, here.
Where is your GDAL coming from, this is a 32-bit error because your data exceeds 4GB?
Also, unless you are reprojecting, I strongly advise you to use gdal_translate instead which has much better performance when resampling:
gdal_translate -r average -tr 1024 1024 -wo NUM_THREADS=ALL_CPUS -co TILED=YES \
-co NUM_THREADS=ALL_CPUS E20N20.TIF dz_E20N20.TIF
You can probably use the official Docker images if you need another GDAL build.
Thank you for your time. I found the problem in -wm 4096. I use the Linux Subsystem for windows to make the resampling. I used 1024 a power of 2, because I didn't really understand, how -ts or -ts worked. I finally use:
gdalwarp -r average -ts 8000 8000 -multi -wo NUM_THREADS=ALL_CPUS -co TILED=YES \
-co NUM_THREADS=ALL_CPUS E20N20.TIF dz_E20N20.TIF
This reduces my file size about 75% and the pixel dim moves from 25x25m to 125x125m.
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 am trying to use gdalwarp to project a polar stereographic image to a mercator projection epsg 28992 (for use in leaflet)
gdalinfo "HDF5:\"RAD_NL25_PCP_NA_202010271205.h5\"://image1/image_data"
Driver: HDF5Image/HDF5 Dataset
Files: RAD_NL25_PCP_NA_202010271205.h5
Size is 700, 765
Metadata:
geographic_geo_column_offset=0
geographic_geo_dim_pixel=KM,KM
geographic_geo_number_columns=700
geographic_geo_number_rows=765
geographic_geo_par_pixel=X,Y
geographic_geo_pixel_def=LU
geographic_geo_pixel_size_x=1.0000035
geographic_geo_pixel_size_y=-1.0000048
geographic_geo_product_corners=0 49.362064 0 55.973602 10.856453 55.388973 9.0093002 48.895302
geographic_geo_row_offset=3649.9819
geographic_map_projection_projection_indication=Y
geographic_map_projection_projection_name=STEREOGRAPHIC
geographic_map_projection_projection_proj4_params=+proj=stere +lat_0=90 +lon_0=0 +lat_ts=60 +a=6378.14 +b=6356.75 +x_0=0 y_0=0
image1_calibration_calibration_flag=Y
image1_calibration_calibration_formulas=GEO = 0.500000 * PV + -32.000000
image1_calibration_calibration_missing_data=0
image1_calibration_calibration_out_of_image=255
image1_image_bytes_per_pixel=1
image1_image_geo_parameter=REFLECTIVITY_[DBZ]
image1_image_product_name=RAD_NL25_PCP_H1.5_NA
image1_image_size=535500
image1_statistics_stat_max_value=44.5
image1_statistics_stat_min_value=-31.5
overview_hdftag_version_number=3.6
overview_number_image_groups=1
overview_number_radar_groups=3
overview_number_satellite_groups=0
overview_number_station_groups=0
overview_products_missing=NA
overview_product_datetime_end=27-OCT-2020;12:05:00.000
overview_product_datetime_start=27-OCT-2020;12:05:00.000
overview_product_group_name=RAD_NL25_PCP_NA
radar1_radar_location=5.17834 52.101681
radar1_radar_name=DeBilt
radar1_radar_operational=0
radar2_radar_location=4.7999701 52.953339
radar2_radar_name=DenHelder
radar2_radar_operational=1
radar3_radar_location=5.1381001 51.836899
radar3_radar_name=Herwijnen
radar3_radar_operational=1
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 765.0)
Upper Right ( 700.0, 0.0)
Lower Right ( 700.0, 765.0)
Center ( 350.0, 382.5)
Band 1 Block=700x765 Type=Byte, ColorInterp=Undefined
Metadata:
image1_image_data_CLASS=IMAGE
image1_image_data_PALETTE=
image1_image_data_VERSION=1.2
gdalwarp -s_srs "+proj=stere +lat_0=90 +lon_0=0 +lat_ts=60 +a=6378.14 +b=6356.75 +x_0=0 y_0=0" -t_srs "epsg:28992" "HDF5:\"RAD_NL25_PCP_NA_202010271205.h5\"://image1/image_data" output.tif
which results in this error message:
Processing HDF5:"RAD_NL25_PCP_NA_202010271205.h5"://image1/image_data [1/1] : 0ERROR 1: The transformation is already "north up" or a transformation between pixel/line and georeferenced coordinates cannot be computed for HDF5:"RAD_NL25_PCP_NA_202010271205.h5"://image1/image_data. There is no affine transformation and no GCPs. Specify transformation option SRC_METHOD=NO_GEOTRANSFORM to bypass this check.
What am i missing? If i set the flag SRC_METHOD=NO_GEOTRANSFORM i dont get the expected result
Georeference support for HDF5 data in GDAL is very limited (https://gdal.org/drivers/raster/hdf5.html). Therefore, your HDF5 file is not recognized by GDAL as georeferenced data.
My solution is to divide your command into two steps:
Georeferencing to stereographic projection using gdal_translate
Transformation to epsg:28992 using gdalwarp
First, the definition of SRS, the size of the Earth should be expressed in m as follows.
+proj=stere +lat_0=90 +lon_0=0 +lat_ts=60 +a=6378140 +b=6356750 +x_0=0 +y_0=0
Next, assuming that the metadata geographic_geo_product_corners represents the latitude and longitude of the four corners of the image, we find the projected coordinates of the corners of the image.
LL (0, -4415002.84084825)
UL (0, -3649999.11191775)
UR (700002.437056242, -3649999.05174429)
LR (700002.440031711, -4415003.15918867)
I used gdaltransform to find this.
gdaltransform -s_srs "+proj=latlong" -t_srs "+proj=stere +lat_0=90 +lon_0=0 +lat_ts=60 +a=6378140 +b=6356750 +x_0=0 y_0=0"
So, the conversion in your question can be done with the following command
gdal_translate -of VRT -a_srs "+proj=stere +lat_0=90 +lon_0=0 +lat_ts=60 +a=6378140 +b=6356750 +x_0=0 +y_0=0" -a_ullr 0 -3649999.05174429 700002.440031711 -4415003.15918867 "HDF5:\"RAD_NL25_PCP_NA_202010271205.h5\"://image1/image_data" /vsistdout/ | gdalwarp -of GTiff -t_srs epsg:28992 /vsistdin/ output.tif
For information on how to combine two gdal command with a pipe, see the answer in How to convert projection of png tile from epsg:4326 to epsg:3857 by one command using gdal.
I have a projected tiff file from sentinel1 data (s1a-ew-grd-hh-20180208t071218-20180208t071323-020512-023164-001.tiff) (lets call it test.tiff) with the following projection in WKT format:
PROJCS["WGS 84",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4326"]],PROJECTION["Polar_Stereographic"],PARAMETER["latitude_of_origin",70],PARAMETER["central_meridian",-45],PARAMETER["scale_factor",1],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]]]
This should be equivalent to the Arctic Polar Stereographic (epsg 3995). My goal is to slightly tune the image by inserting some GCP's and warp it. To double check this method I am starting with the trivial case, where I get the corner coordinates from the projected image (test.tiff):
Size is 17959, 18039
Corner Coordinates:
Upper Left ( 457598.467, -240151.021) ( 17d18'33.06"E, 85d13'55.33"N)
Lower Left ( 457598.467,-1142101.021) ( 23d 9'56.93"W, 78d40'39.65"N)
Upper Right ( 1355548.467, -240151.021) ( 34d57'13.08"E, 77d20'28.88"N)
Lower Right ( 1355548.467,-1142101.021) ( 4d53' 4.53"E, 73d44'33.76"N)
Center ( 906573.467, -691126.021) ( 7d40'47.73"E, 79d30'17.56"N)
and I set the GCP according to that. Hence:
gdal_translate -gcp 0.0 0.0 457598.467 -240151.021 -gcp 0.0 18039.0 1355548.467 -240151.021 -gcp 17959.0 18039.0 1355548.467 -1142101.021 -gcp 17959.0 0.0 457598.467 -1142101.021 -a_srs WKT_PROJECTION test.tiff gcp.tiff
Then I warp the image using the -tps option to force warping using the GCP information.
gdalwarp -tps gcp.tiff gcp_warped.tiff
One would expect that the test.tiff and the gcp_warped.tiff files should coincide which is unfortunately not the case:
Is there something that I miss during the above mentioned procedure? Or is there another work around?
I can't figure out how to convert a "landscape" PDF file with a single picture on it (eg. paperwidth=842 and paperheight=595 points with an image that fills the whole page) with the tool pdftocairo to an EPS file.
The output I get is either a shrinked version of the original file (width is scaled from 842 to 595 to fit the "incorrect" pagewidth 595 of the EPS file), or an EPS where the content between 595 and 842 is just cut off (with the -noshrink parameter).
Any ideas?
Edit1: pdftocairo version 0.43.0
Input PDF:
pdfinfo test.pdf
Creator: DocType PDF-Emitter (DocType PDF-Emitter v1.9.37-9-g1b2b6f3)
Producer: Haru Free PDF Library 2.3.0RC2
CreationDate: Mon Jun 4 11:18:30 2018
Tagged: no
UserProperties: no
Suspects: no
Form: none
JavaScript: no
Pages: 1
Encrypted: no
Page size: 595.44 x 841.68 pts
Page rot: 90
File size: 149246 bytes
Optimized: no
PDF version: 1.3
Landscape PDF
Converted with pdftocairo -eps test.pdf
Landscape EPS
The most recent version of Poppler (on my system, it's v0.42.0) has the following command line options which may be of help:
$ pdftocairo -h
pdftocairo version 0.42.0
Copyright 2005-2016 The Poppler Developers - http://poppler.freedesktop.org
Copyright 1996-2011 Glyph & Cog, LLC
Usage: pdftocairo [options] <PDF-file> [<output-file>]
[....]
-eps : generate Encapsulated PostScript (EPS)
[....]
-r <fp> : resolution, in PPI (default is 150)
-rx <fp> : X resolution, in PPI (default is 150)
-ry <fp> : Y resolution, in PPI (default is 150)
-scale-to <int> : scales each page to fit within scale-to*scale-to pixel box
-scale-to-x <int> : scales each page horizontally to fit in scale-to-x pixels
-scale-to-y <int> : scales each page vertically to fit in scale-to-y pixels
-x <int> : x-coordinate of the crop area top left corner
-y <int> : y-coordinate of the crop area top left corner
-W <int> : width of crop area in pixels (default is 0)
-H <int> : height of crop area in pixels (default is 0)
-sz <int> : size of crop square in pixels (sets W and H)
-cropbox : use the crop box rather than media box
[....]
-level2 : generate Level 2 PostScript (PS, EPS)
-level3 : generate Level 3 PostScript (PS, EPS)
-origpagesizes : conserve original page sizes (PS, PDF, SVG)
-paper <string> : paper size (letter, legal, A4, A3, match)
-paperw <int> : paper width, in points
-paperh <int> : paper height, in points
-nocrop : don't crop pages to CropBox
-expand : expand pages smaller than the paper size
-noshrink : don't shrink pages larger than the paper size
-nocenter : don't center pages smaller than the paper size
[....]