Right, thanks Even.
I was generally aware of the issue and had added SYS_PTRACE capability to my docker service. That made the HDF5 driver work with /vsicurl/ in the container, but not the NetCDF driver, which did confuse me.
Now, instead of running a container with --security_opt=seccomp:u
Works for me with GDAL 3.6, 3.7 and master on Ubuntu 20.04
$ gdalinfo
/vsicurl/https://nbstds.met.no/thredds/fileServer/NBS/S2B/2022/07/03/S2B_MSIL1C_20220703T112119_N0400_R037_T32VLN_20220703T121203.nc
Driver: netCDF/Network Common Data Format
[...]
/vsicurl/ functionality for the netCDF driv
P.S.: I notice a change from 3.6.3 to 3.6.4.
docker run ghcr.io/osgeo/gdal:ubuntu-full-3.6.3 gdalinfo --formats | grep -i netcdf
netCDF -raster,multidimensional raster,vector- (rw+vs): Network Common Data Format
docker run ghcr.io/osgeo/gdal:ubuntu-full-3.6.4 gdalinfo --formats | grep -i
Hi,
I am wondering if the behavior of the NetCDF driver changed in recent GDAL version(s)?
I do have the netCDF driver installed and also HDF5, which has been shaddowing the netCDF driver. So I used to do the following:
export GDAL_SKIP=HDF5
gdalinfo /vsicurl/https://nbstds.met.no/thredds
Hi Javier,
I've come across some other bugs that are specific to Conda running in
Pycharm only this morning. Up to and including getting different
projection strings back for the exact same file, depending on whether
the `GetProjectionRef` is called via Pycharm or the terminal (using the
exac
Are you running pycharm under the conda environment? If you lose any
setting while combining both it can be a problem.
Have you tried setting PROJ_DEBUG=3 ?
It will show some traces from PROJ, like the location of proj.db used. The
point is if you can see the std out.
On Wed, 11 Oct 2023, 15:18 J
