GDAL: gdalwarp wrong transformation to “South_Pole_Lambert_Azimuthal_Equal_Area” EPSG:102020

Question

I am trying to reproject a raster that is defined in EPSG:4326 to EPSG:102020.

Command used

gdalwarp -ot Float32 -s_srs EPSG:4326 -t_srs EPSG:102020 -r near -of GTiff -co COMPRESS=DEFLATE -co PREDICTOR=1 -co ZLEVEL=6 etopo1.tif etopo1_warped_cli.tif

but the output has a wrong coordinate reference system, as it is shown as

+proj=laea +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs

instead of

+proj=laea +lat_0=-90 +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs

On the other hand if I manually specify the parameters for the target srs then transformation is ok and the raster is recognized as EPSG:102020 in Desktop GIS software:

gdalwarp -ot Float32 -s_srs EPSG:4326 -t_srs "+proj=laea +lat_0=-90 +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs" -r near -of GTiff -co COMPRESS=DEFLATE -co PREDICTOR=1 -co ZLEVEL=6 etopo1.tif etopo1_warped_cli.tif

NOTE: the above is on Windows, because on Linux the operation returns

ERROR 6: EPSG PCS/GCS code 102020 not found in EPSG support files.  Is this a valid
EPSG coordinate system?
ERROR 1: Translating source or target SRS failed:
EPSG:102020

Answer 1

As noted in the comments, 102020 is not an EPSG code, but an ESRI one.

So the safe solution is to use

gdalwarp -ot Float32 -s_srs EPSG:4326 -t_srs "+proj=laea +lat_0=-90 +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs" -r near -of GTiff -co COMPRESS=DEFLATE -co PREDICTOR=1 -co ZLEVEL=6 etopo1.tif etopo1_warped_cli.tif

In Desktop GIS like QGIS a custom CRS can be created (with any name, the internal code will be auto-generated) with this definition

+proj=laea +lat_0=-90 +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs

and then use this instead of the default one (code 102020).