issue_comments: 457246424
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/1475#issuecomment-457246424 | https://api.github.com/repos/pydata/xarray/issues/1475 | 457246424 | MDEyOklzc3VlQ29tbWVudDQ1NzI0NjQyNA== | 1197350 | 2019-01-24T15:50:24Z | 2019-01-24T15:50:24Z | MEMBER | I'm just pinging this issue again to keep it fresh. I am becoming more and more convinced that we need to allow for cell bounds in xarray's data model. Contrary to my comments above, I no longer think this is a problem to be solved with xgcm or some outside package. CF conventions, which we partially support in other parts of xarray, have a clearly defined concept of cell geometry. When present, such coordinates could decoded and used for indexing and plotting. Currently we distinguish between "dimension coordinates," which are converted to indexes, and "non-dimension coordinates." What if we added a new type of coordinate called "cell coordinates"? We could accomodate either (N+1) sized coordinates for quad-mesh geometries of (N,M) sized coordinates for unstructured meshes. What is a concrete first step we could take towards this goal? Try to work out a design document? |
{
"total_count": 6,
"+1": 6,
"-1": 0,
"laugh": 0,
"hooray": 0,
"confused": 0,
"heart": 0,
"rocket": 0,
"eyes": 0
} |
242181620 |