[gdal-dev] GDAL fails to read projection with: Unsupported conversion method: Polar_Stereographic
Hi, I'm trying to read a projection in proj4 string from a NetCDF and gdal / proj fails to recognize the /*conversion method: Polar_Stereographic*/. The issue appears with any files in: https://dd.weather.gc.ca/model_riops/netcdf/forecast/polar_stereographic/2d/06/003/ example gdalinfo request: /$ gdalinfo -proj4 input.nc// //Driver: netCDF/Network Common Data Format// //...// //*ERROR 1: PROJ: proj_as_proj_string: Unsupported conversion method: Polar_Stereographic*//* *//*PROJ.4 string is:*//* *//*''*// //Origin = (-2500.000,8047500.000)// //Pixel Size = (5000.000,-5000.000)// //...// // SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AXIS["Latitude",NORTH],AXIS["Longitude",EAST],AUTHORITY["EPSG","4326"]]// // X_BAND=1// // X_DATASET=NETCDF:"dd_riops.nc":longitude// // Y_BAND=1// // Y_DATASET=NETCDF:"dd_riops.nc":latitude// //Corner Coordinates:// //Upper Left ( -2500.000, 8047500.000)// //Lower Left ( -2500.000, -2500.000)// //Upper Right ( 8847500.000, 8047500.000)// //Lower Right ( 8847500.000, -2500.000)// //Center ( 4422500.000, 4022500.000)// //.../ The gdal version I'm getting the error with: GDAL 3.1.3, and PROJ version: Rel. 7.2.0. I know this command previsously worked fine, using gdal GDAL 2.4.4 and proj Rel. 4.8.0 and I was able to get the PROJ4 string: '+proj=stere +lat_0=90 +lat_ts=59.3768695209 +lon_0=-100 +k=0.93301243 +x_0=4245000 +y_0=5295000 +a=6371229 +b=6371229 +units=m +no_defs ' Also, if I try to reproject the file in EPSG:4326 with a gdalwarp (GDAL 3.1.3) command, it fails, because it does not read the source srs, but if I specify it using the -s_srs flag it works fine, example: |gdalwarp -of NetCDF -s_srs "+proj=stere +lat_0=90 +lat_ts=59.3768695209 +lon_0=-100 +x_0=4245000 +y_0=5295000 +R=6371229 +units=m +no_defs" -t_srs EPSG:4326 input.nc output.nc| Is this a bug in gdal / proj, or a parameter in the projection definition that is not supported anymore ? Thanks LP ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Polar stereographic projection invalid definition ?
Hi all, I have an issue with a polar stereographic projection definition. Context: I tried to open a NetCDF files in QGIS and with GDAL and it failed with: * Gdal:/ERROR 1: PROJ: proj_as_proj_string: Unsupported conversion method: Polar_Stereographic/ * Qgis:/WARNING Could not reproject layer extent: Could not transform bounding box to taret CRS / The projection fails with the previous error for both gdal and proj versions: * GDAL 3.1.3, 3.3.0 * PROJ 7.2.0, 8.01 Test files (really any files in the folder will have the same behavior): * https://dd.weather.gc.ca/model_giops/netcdf/polar_stereographic/2d/00/003/CMC_giops_votemper_depth_0.5_ps5km60N_3h-mean_*{MMDDHH}*_P003.nc I tried opening the files with an older gdal/proj version and it worked fine: * GDAL: |2.4.4, released 2020/01/08| * PROJ: Rel. 4.8.0, 6 March 2012 Here is the projection definition I got: /+proj=stere +lat_0=90 +lat_ts=59.3768695209 +lon_0=-100 +k=0.93301243 +x_0=4245000 +y_0=5295000 +a=6371229 +b=6371229 +units=m +no_defs/ When I tried adding the projection manually in Qgis (3.20), I got the following error message: /This proj projection definition is not valid:// //proj_create: lat_ts != lat_0 and k != 1 not supported for Polar Stereographic./ Should the projection definition be updated in the NetCDF files if this really is not a supported projection definition anymore, or is this a bug in gdal? If this looks like a bug to you, let me know, I will open an issue on the gdal repo. Thanks! LP ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Metadata keys in upper or lower case ?
Hi everyone ! I would like to know if there is a rule or a best practice for a raster file's metadata key to be written in upper or lower case ? I read https://gdal.org/user/raster_data_model.html#metadata and saw that "/The names are required to be well behaved tokens (no spaces, or odd characters//)./" but I didn't read anything about upper vs lower cases. While I see examples of both (upper and lower case) in different valid files, I would like to know if a documented recommendation exists ? Thanks LP ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GRIB2 file extent not matchi GRIB2 metadata (grib_dump)
Hi, I am facing an issue with GRIB2 data, and the extent reported by a gdal_info command. Here is a sample data to test: https://drive.google.com/file/d/1URvQs2qHXgRkq3YfC7ZR8VGYK3SKXB59/view?usp=drive_link Here is what I am testing with: * Ubuntu 20.04.6 LTS * GDAL 3.5.2, released 2022/09/02 * PROJ Rel. 8.2.0, November 1st, 2021 So, using grib_dump, I see the longitude of the file should be from 0 to 360 degress: grib_dump out.grib2 | grep shapeOfTheEarth -A 12 shapeOfTheEarth = 6; Ni = 2400; Nj = 1201; iScansNegatively = 0; jScansPositively = 1; jPointsAreConsecutive = 0; alternativeRowScanning = 0; latitudeOfFirstGridPointInDegrees = -90; longitudeOfFirstGridPointInDegrees = 0; latitudeOfLastGridPointInDegrees = 90; longitudeOfLastGridPointInDegrees = 360; iDirectionIncrementInDegrees = 0.15; jDirectionIncrementInDegrees = 0.15; But using gdal_info I see the extent as: gdal_info -proj4 out.grib2 | grep PROJ -A 9 PROJ.4 string is: '+proj=longlat +R=6371229 +no_defs' Origin = (-0.075031263026261,90.0750003) Pixel Size = (0.150062526052522,-0.150) Corner Coordinates: Upper Left ( -0.0750313, 90.075) ( 0d 4'30.11"W, 90d 4'30.00"N) Lower Left ( -0.0750313, -90.075) ( 0d 4'30.11"W, 90d 4'30.00"S) Upper Right ( 360.075, 90.075) (360d 4'30.11"E, 90d 4'30.00"N) Lower Right ( 360.075, -90.075) (360d 4'30.11"E, 90d 4'30.00"S) Center ( 180.000, 0.000) (180d 0' 0.00"E, 0d 0' 0.01"N) I would expect the gdal_info extent to be also from 0 to 360 degrees (2400 pixels * 0.15 = 360). From reading various source, I see the issue is potentially that the GRIB2 files define the extent using the center of the pixel while gdal assumes it is the top left corner. My question: Is there a way to change this behavior in gdal, or this expected, or a bug ? Thanks LP ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev