Dear Authors,

There are some usability issues with your NetCDF files, and below are some expectations and hopefully helpful code to address theses issues. I also list some generic issues common to submissions that may or may not exist with your data and manuscript. Please address all relevant issues.

Manuscript content: ESSD expects no science, only data description. There should be robust uncertainty analysis. Errors are OK! There should be thorough validation against independent products. Your paper should describe everything that went into creating the data, and give end-users the ability to develop trust in the product and understand it's limitations, weaknesses, and issues, all of which are a part of your product. Please do not shy away from openly discussing them.

Manuscript style: Dates should all follow the ISO 8601 standard YYYY-MM-DD. Times should be provided in UTC. Local time can be provided in addition to UTC if you want. If you use the phrase "from <year0> to <year1>" readers do not know if <year1> is include or not. Please use "from <year0> through <year1>". Clearly distinguish input data from your product, the output and focus of the manuscript. Consider distinct sections for methods, validation, and error analysis. If you have a DOI, then the last sentence of the abstract should contain that DOI. If you use Zenodo, I suggest the DOI is the DOI for all versions, and you explicitly mention which version is used and presented in the manuscript, so that future updates are easy for users to find.

Code: ESSD expects all code related to your work to be available with the submission. This is primarily the code that generated your product, but also code to generate the figures in your manuscript (which will help users use your product correctly). We support open science. If you do not think the code is ready to release, then your paper or data is probably not ready to be reviewed. Open science is a subset of well-documented, user-friendly, or reproducible science.

Data: If your data is geospatial points or vector, it should probably be in an open geospatial format. This is typically GeoPackage. If your data is in CSV format, consider also adding a GeoPackage. Dates should all follow the ISO 8601 standard YYYY-MM-DD. Times should be UTC. Raster data should open via drag-and-drop in QGIS and support on-the-fly reprojection. Please test this. Raster data should also be internally compressed. NetCDF can be compressed with

#+BEGIN_SRC bash

nccopy -d1 in.nc out.nc # https://nco.sourceforge.net/

#+END_SRC

Or

#+BEGIN_SRC python

# Assuming ds is an xarray Dataset

comp = dict(zlib=True, complevel=5)

encoding = {var: comp for var in ds.data_vars} # only numeric, not string data_vars

ds.to_netcdf(filename, encoding=encoding)

#+END_SRC

NetCDF files should probably be CF and ACDD compliant, and this can be checked with

#+BEGIN_SRC bash

cchecker.py -t acdd:1.3 -t cf:1.8 file.nc # https://github.com/ioos/compliance-checker

#+END_SRC

If you have many NetCDF files split by time, you should be able to easily combine them with one or more of the following commands:

#+BEGIN_EXAMPLE

ds = xr.open_mfdataset("in_*.nc")         # Python xarray

cdo mergetime in_{1,2,3}.nc out_123.nc # Bash cdo

ncrcat in_{1,2,3}.nc out_123.nc        # Bash nco

#+END_EXAMPLE

Metadata needed by QGIS for projection support might be added with the following, depending on your dimension variable names:

#+BEGIN_SRC python

import rioxarray as rxr

ds = ds.rio.write_grid_mapping()

ds = ds.rio.write_crs('epsg:nnnn') # create ds['spatial_ref'] for your EPSG code

ds['spatial_ref'] = ds['spatial_ref'].astype(np.byte)

ds = ds.rio.set_spatial_dims('x','y') # or ('lon','lat') and only maybe needed

for v in ds.data_vars:

    ds[v].attrs['grid_mapping'] = 'spatial_ref'

ds.to_netcdf(outfilename, encoding=encoding)

# open in QGIS and check agianst known product if correct.

#+END_SRC

Think about your data types. If you have a percentage value (0 to 100) with precision 1 (or 5), it can be stored in an 8 bit integer and does not need 64 bit floating point storage. Elsewhere, Float32 may be more appropriate than Float64.

Please address any of these issues if they apply to your dataset and manuscript.

Regards,

  Ken Mankoff

  ESSD Chief Editor (Ice)