I am trying to use gdal_translate to convert a WCS source to a tif target. I am trying to achieve this using a WCS XML service description file. The gdal_translate call looks like this

"C:\OSGeo4W\bin\gdal_translate.exe" -tr 250 250 -projwin -337500 1242500 152500 527500 -of "GTiff" -projwin_srs "ESRI:54052" -co "TILED=YES" -co "COMPRESS=DEFLATE" -co "PREDICTOR=2" -co "BIGTIFF=YES" "./sg.xml" "./test.tif"

The sg.xml file looks like this:


Unfortunately, I am getting the following result:

ERROR 1: PROJ: proj_create_from_database: crs not foundInput file size is 159246, 580340...10...20...30...40...50...60...70...80...90...100 - done.

The good news is that I actually get a file. The extents are almost right, because I suspect the coordinates are converted through a few other srs. Regardless, I am bothered by the error, as I cannot trust the result each and every time.

While ESRI:54052 might not be the most common projection, it is in the proj.db database as pointed out by gdalsrsinfo ESRI:54052 -v, which returns Validate Succeeds.

I don't understand why is gdal complaining that it cannot find this projection, when it clearly can in other circumstances.

2 Answers 2


I finally figured what's going on. It's not that PROJ cannot find the -projwin_srs ESRI:54052. If that would have been the case, the error would have been:

ERROR 1: PROJ: proj_create_from_database: crs not foundERROR 1: Failed to process SRS definition: ESRI:54052Input file size is 159246, 58034

The issue is that the WCS server claims the data is in EPSG:152160, which is a custom alias for the same projection. Nevertheless it was the EPSG:152160 that PROJ couldn't find, rightfully so.

The confusion mostly comes from the fact that gdal_translate/PROJ is not explicit that the issue is with the WCS response projection and not with the -projwin_srs projection.

The output file is good, and it only needs to be assigned the correct ESRI:54052 projection.

  • 1
    For other readers, EPSG:152160 is from DescribeCoverage maps.isric.org/mapserv?map=/map/….
    – user30184
    Dec 3, 2021 at 18:44
  • @user30184 would you say the confusing error message is a gdal, or PROJ issue? I would like to raise an issue, but I'm not sure where
    – Andrei
    Dec 3, 2021 at 18:48
  • The message comes from Proj, therefore the prefix PROJ:. You can get it also with projinfo projinfo EPSG:152160 input string: parsing of user string failed: crs not found. The confusion is that the GDAL side does not tell what crs it tried to resolve use, it is really not prepared for misconfigured WCS servers. It reads DescribeCoverage in good faith.
    – user30184
    Dec 3, 2021 at 19:00
  • so PROJ probably raises an ERROR 1: Failed to process SRS definition: EPSG:152160, but gdal_translate doesn't pass this error to the user, because it assumes that DescribeCoverage can't be wrong. Sounds like a gdal issue to me. It's either a wrong assumption, a not documented assumption, or a bad error handling. Thanks!
    – Andrei
    Dec 3, 2021 at 19:11
  • PROJ probably raises error just as it prints it input string: parsing of user string failed: crs not found with no mention about what the unknown string was. WCS is not an exception to other OGC standards and clients are supposed to get all information that they need from GetCapabilities and DescribeCoverage/DescribeFeatureType etc. The GDAL WCS driver could be more explicit with the error but fortunately WCS servers are usually configured right and tested by the service providers.
    – user30184
    Dec 4, 2021 at 19:04

The short CRS codes EPSG:152160 and EPSG:52054 do not exist in the Proj database by default and therefore the programme cannot deal with them. These are custom codes (or "fake"), they do not feature in the EPSG registry. This is a consequence of the restrictions imposed by MapServer to the CRS authority: it must forcibly be "EPSG".

Read up more on this in this earlier question, you will find there instructions on how to add a custom CRS to the Proj database.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.