[gdal-dev] NetCDF driver getting wrong values if compared to HDF5

[Ivan Lucena]

Hi Even,

I tried the open-option HONOUR_VALID_RANGE=NO and that seems to do the trick. That netCDF driver special case could check the flag_values metadata to see if the value is out of range but is a flagged value. But that is OK.

gdalinfo NETCDF:c_gls_NDVI_201907110000_GLOBE_PROBAV_V2.2.1.nc:NDVI
Corner Coordinates:
Upper Left  (-180.0044643,  80.0044643) (180d 0'16.07"W, 80d 0'16.07"N)​
Lower Left  (-180.0044643, -59.9955357) (180d 0'16.07"W, 59d59'43.93"S)​
Upper Right ( 179.9955357,  80.0044643) (179d59'43.93"E, 80d 0'16.07"N)​
Lower Right ( 179.9955357, -59.9955357) (179d59'43.93"E, 59d59'43.93"S)​
Center      (  -0.0044643,  10.0044643) (  0d 0'16.07"W, 10d 0'16.07"N)​
Band 1 Block=3102x1207 Type=Byte, ColorInterp=Undefined
  NoData Value=255​
  Offset: -0.0799999982118607,   Scale:0.00400000018998981​
  Metadata:​
    add_offset=-0.079999998​
    flag_meanings=Missing cloud snow sea background​
    flag_values={251,252,253,254,255}​
    grid_mapping=crs​
    long_name=Normalized Difference Vegetation Index 1KM​
    missing_value=255​
    NETCDF_DIM_time=18088​
    NETCDF_VARNAME=NDVI​
    scale_factor=0.0040000002​
    standard_name=normalized_difference_vegetation_index​
    units=​
    valid_range={0,250}​
    _FillValue=255​

About geo-referencing, this is from the Proba-V documentation :

"""
2.4. Data projection and geographical extents
All PROBA-V data products are projected in a standard WGS84 projection (also known as the Plate Carrée projection), similar as for the SPOT-VGT products. The 1 km Plate-Carrée projection is defined as 1/112o, with the latitude and longitude coordinates defined at the pixel centre. This implies that the pixel boundaries extend ± 1/224o for both latitude and longitude at the pixel corners. For example, if we consider the pixel corresponding to [lon, lat]=[-180o, 75o], the upper left corner of this pixel represents [lon, lat]=[-180o - 1/224o, 75o + 1/224o].
""" [PROBAV_Products_User_Manual.pdf]

Thank you,

Ivan

________________________________
From: Even Rouault <even.rouault at spatialys.com>
Sent: Friday, August 2, 2019 11:54 AM
To: Ivan Lucena <ivan.lucena at outlook.com>
Cc: gdal-dev at lists.osgeo.org <gdal-dev at lists.osgeo.org>
Subject: Re: [gdal-dev] NetCDF driver getting wrong values if compared to HDF5

On vendredi 2 août 2019 14:44:02 CEST Ivan Lucena wrote:
> Even,
>
> The metadata of one file samples points to
> http://land.copernicus.eu/global/products/ndvi
>
> I wasn't able to recover my username/password so I not sure what is there.
>
> Another this page you can select the specific product I am using 1KM Decadal
> NDVI but without login in I can tell if it is going to download the .nc
> file:
>
> https://land.copernicus.vgt.vito.be/PDF/portal/Application.html#Browse;Root=
> 513186;Collection=1000085;DoSearch=true;Time=NORMAL,NORMAL,1,APRIL,1998,2,AU
> GUST,2019
>
> Can you give it a try?
>

OK, this is due to the fact that the netCDF driver is doing a special
processing with the valid_range metadata item. It will set pixel values
outside of the range defined by valid_range to the nodata value.
This can be disabled by the HONOUR_VALID_RANGE=NO open option.
Generally, as expected, the netCDF driver will have more particular behaviour
when dealing with netCDF files than the HDF5 driver (the HDF5 driver has been
enhanced over years to take into account a few netCDF specific metadata items,
but not that one)

> Note, netCDF return this "Lower Right ( 179.9955357, -59.9955357)
> (179d59'43.93"E, 59d59'43.93"S)" while the documentation mention exact "
> Polygon
> -60 180 80 180 80 -180 -60 -180 -60 180". It looks like a half pixel
> difference, do you see a problem with that?

No, if you look at the actual range with ncdump for longitude, you'll get

lon = -180, -179.991071428571, [...]
    179.982142857634, 179.991071429063 ;

and GDAL normalizes the netCDF pixel-center convention to its usual pixel-
corner convention.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190805/24b4b237/attachment-0001.html>