GenericMappingTools / GenericMappingTools/gmt
GMT_Write_Data for netCDF grids changes the grid
- Dominant language
- C
- Stars
- 979
- Forks
- 414
- Avg merge
- 17h 26m
- Merged PRs (30d)
- 54
Description
**Description of the problem**
The netCDF grid writing library in GMT deals with chunking and optional or auto scaling/offsetting the grid to take up as little space as possible. This works well for most cases and all modules since the modules were written as stand-alone command-line tools and when one finished the process died. However, when one is using the API to write a grid and then continue to use the grid after writing, the values may have changed due to the fact that the data may have been scaled and offset to fit some specific storage unit like short int. Thus, a module calling another module passing a virtual file may find its grid no longer making sense.
**Solutions:**
The only way to completely avoid this problem is to undo the translation after the writing has completed. This will add more CPU cycles but will treat the grid as "read-only". Otherwise, we can never guarantee that a grid can continue to be used after writing. This is especially bad if the input grid is a reference from the outside. So I think we simply have to do this.
The only relief would be if one masses in a bit-mode flag like **GMT_GRID_FINISHED** or something, so that someone who is writing a specific set of steps and know that the process is done after teh writing done spend time undoing a scaling, since it won't be used again. We can never be sure of that in the API since anyone can write a tool that calls **surface** with -Gresult.nc=ns+s0.1 and then call **grdimage**, and be surprised at the result.
So @joa-quim and @seisman, I will undo any translation done in gmt_nc.c unless a flag (I may think of another name) is passed, and GMT will not pass that flag unless it is a grid that cannot be returned anywhere.
Contributor guide
Assessment
This issue has not been assessed yet.