3

GDAL ver     : GDAL 3.1.1, released 2020/06/22
Python         : 3.8.0
OS:               : windows 10
Input file       : 7200 x 3600 GeoTIF in epsg:4326
File link        : [https://www.dropbox.com/s/z9th2kbp6n3zvbu/sst_bw.tif?dl=0] (~100mb; Sea Surface Temperature data)
Req output   : in epsg:3413 SRS
in WKT: "+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"

Console command:

gdalwarp -s_srs "EPSG:4326" -t_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" sst_bw.tif sst_bw_3413.tif

Error:

Creating output file that is 5692P x 5692L.
Processing sst_bw.tif [1/1] : 0Using internal nodata values (e.g. -32768) for image sst_bw.tif.
Copying nodata values from source out_data\sst_bw.tif to destination sst_bw_3413.tif.
ERROR 1: Too many points (529 out of 529) failed to transform, unable to compute output bounds.
Warning 1: Unable to compute source region for output window 0,0,5692,5692, skipping.
...10...20...30...40...50...60...70...80...90...100 - done.

Can someone suggest how to get it working and output correctly. Currently, it creates a file with no data with the primary error:

'ERROR 1: Too many points (529 out of 529) failed to transform, unable to compute output bounds.'

My apologies if the question seems trivial, as I'm very new to GDAL. I searched through similar questions but they have either not been answered or do not have test data. So, I thought of making a complete post with test data.

Vince
  • 20,017
  • 15
  • 45
  • 64
PDash
  • 383
  • 2
  • 12
  • You might want to check that the input raster is already georeferenced to 4326. All reference points failed so there's something drastically wrong when trying to perform the reprojection. – mkennedy Jul 12 '20 at 02:18
  • 2
    @mkennedy Thanks for your effort. After spending a few hours, I actually figured it out, mostly by trial & error. The reason and solution are below:

    Background: Original files are correct (no issues). In stereographic projection, data in one of the poles is not viewable from the other pole. GDAL does not automatically check for this and throws an error; so the trick is to first subset valid data.

    Steps:

    1. gdal_translate -of VRT -projwin -180 90 180 70 inFile.tif subsetFile.vrt
    2. gdalwarp -t_srs {proj info} subsetFile.vrt outFile.tif

    Let me know if of further interest.Cheers

     – PDash Jul 12 '20 at 20:41
  • 1
    Thank you! You might think about adding that as an answer. – mkennedy Jul 12 '20 at 21:03
  • I did not know that I could answer my question (still juggling with understanding this platform). Thanks for pointing this out- adding now. – PDash Jul 12 '20 at 21:05
  • 1
    There's a delay until you can accept it, but you should do so in a few days. – mkennedy Jul 12 '20 at 23:05

1 Answers1

2

Background: In stereographic projection, data in one of the poles is not viewable from the other pole. GDAL does not automatically check for this (I think) and throws an error. So the trick is to first subset valid data coverage for the target projection.

Steps:

  1. gdal_translate -of VRT -projwin -180 90 180 70 inFile.tif subsetFile.vrt

-projwin -180 90 180 70 covers the EPSG 3413 Arctic Stereographic projection

  1. gdalwarp -t_srs {proj info} subsetFile.vrt outFile.tif
PDash
  • 383
  • 2
  • 12
  • What about the projection epsg: 28992 (Amersfoort / RD New -- Netherlands)? I have the same problem. How could I fix it? – Ilias Machairas Aug 06 '20 at 16:58
  • @iliasm: I have not tried this particular CRS but the -projwin left top right bottom parameters must correspond to the Unit of the applied CRS. I guess epsg28992 has units in meters, so try to set the -projwin with meters. Post here after trying if it does not work, we can take a look then. – PDash Aug 07 '20 at 06:14
  • After checking, the problem in my case is that the crs of the raster is wrong but the extent is right. The crs is WGS84 geographic, and the extent is for epsg28992. I may ask a separate question if I did not find relevant answers. – Ilias Machairas Aug 08 '20 at 09:39
  • @ilias: okay thanks., drop a line here which maybe helpful for our collective understanding. cheers – PDash Aug 08 '20 at 21:51