vsicurl and netcdf inconsistency

[piyushrpt]

Expected behavior and actual behavior.

Reporting issue - conda-forge/gdal-feedstock#376 by @dbekaert
gdalinfo and other utilities that manipulate data on a netcdf via vsicurl reports/ uses wrong driver

This is related to #1328

This was addressed in conda-forge/gdal-feedstock#330
And latest build logs show that netcdf_mem is available and userfaultfd is enabled:
https://dev.azure.com/conda-forge/84710dde-1620-425b-80d0-4cf5baca359d/_apis/build/builds/137713/logs/26

Steps to reproduce the problem.

Using earthdata login setup via .netrc.
gdalmanage identify clearly identifies the file as netcdf whereas gdalinfo uses HDF5 driver without trying to use the netcdf driver.

1. gdalmanage reports netcdf correctly

> GDAL_HTTP_COOKIEFILE=asf.txt GDAL_HTTP_COOKIEJAR=asf.txt  gdalmanage identify -r /vsicurl/https://grfn.asf.alaska.edu/door/download/S1-GUNW-D-R-160-tops-20190710_20190628-162436-20935N_18926N-PP-6a53-v2_0_2.nc

/vsicurl/https://grfn.asf.alaska.edu/door/download/S1-GUNW-D-R-160-tops-20190710_20190628-162436-20935N_18926N-PP-6a53-v2_0_2.nc: netCDF

2. gdalinfo reports hdf5. With, CPL_DEBUG=ON looks like output in Inconsistent results against NETCDF-4 data #1328

GDAL_HTTP_COOKIEFILE=asf.txt GDAL_HTTP_COOKIEJAR=asf.txt gdalinfo  /vsicurl/https://grfn.asf.alaska.edu/door/download/S1-GUNW-D-R-160-tops-20190710_20190628-162436-20935N_18926N-PP-6a53-v2_0_2.nc
Driver: HDF5/Hierarchical Data Format Release 5
Files: /vsicurl/https://grfn.asf.alaska.edu/door/download/S1-GUNW-D-R-160-tops-20190710_20190628-162436-20935N_18926N-PP-6a53-v2_0_2.nc
Size is 512, 512

Operating system

Ubuntu 18.04 64 bit

> uname -r
5.3.0-7642-generic

GDAL version and provenance

3.0.4 via conda-forge

[piyushrpt]

Thanks @rouault for the quick fix.

[dbekaert]

@rouault i understand correctly that this has been back ported to version 2.4 and 3?
I can reach out to the conda-forge channel developers to incorporate this.

[rouault]

that this has been back ported to version 2.4 and 3?

yes