[gdal-dev] GDAL fails to read projection with: Unsupported conversion method: Polar_Stereographic

2021-07-28 Thread Rousseau Lambert,Louis-Philippe (ECCC) 

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 ?

2021-11-15 Thread Rousseau Lambert,Louis-Philippe (ECCC) 

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 ?

2023-01-30 Thread Rousseau Lambert,Louis-Philippe (ECCC) 

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)

2023-09-28 Thread Rousseau Lambert, Louis-Philippe (ECCC) via gdal-dev 
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