issue_comments: 705594621
This data as json
html_url | issue_url | id | node_id | user | created_at | updated_at | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
https://github.com/pydata/xarray/issues/4490#issuecomment-705594621 | https://api.github.com/repos/pydata/xarray/issues/4490 | 705594621 | MDEyOklzc3VlQ29tbWVudDcwNTU5NDYyMQ== | 226037 | 2020-10-08T14:06:35Z | 2020-10-08T14:06:35Z | MEMBER | @shoyer I favour option 2. as a stable solution, possibly with all arguments moved to keyword-only ones:
* users don't need to import and additional class
* users get the argument completion on I'm for using the words decode/decoding but I'm against the use of CF. What backend will do is map the on-disk representation of the data (typically optimised for space) to the in-memory representation preferred by xarray (typically optimised of easy of use). This mapping is especially tricky for time-like variables. CF is one possible way to specify the map, but it is not the only one. Both the GRIB format and all the spatial formats supported by GDAL/rasterio can encode rich data and decoding has (typically) nothing to do with the CF conventions. My preferred meaning for the Typically when a user asks the backend not to decode they intend to insepct the content of the data file to understand why something is not mapping in the expected way. As an example: in the case of GRIB time-like values are represented as integers like |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
715374721 |