issue_comments: 271864879
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/1197#issuecomment-271864879 | https://api.github.com/repos/pydata/xarray/issues/1197 | 271864879 | MDEyOklzc3VlQ29tbWVudDI3MTg2NDg3OQ== | 25030860 | 2017-01-11T13:12:32Z | 2017-01-11T13:12:32Z | NONE | Hello, thanks for the immediate reply - and to seize the opportunity: thanks for this really great library, which I think will be the enabler for me to - finally - use netCDF4 for my measurement facility like I wished for years now.
However, I have to disagree in your point regarding the not fitting dimensions in the DataArray definition. np.zeros() will for sure return an n-dimensional array when called with a length-n list as argument, which I did with n=3 and the list [1,2,3].
I.e. calling Besides, the working alternatives with tuples or the OrderedDict use the very same dummy array for initializing in the example above. Further I estimate the 0.8.2-error-message completely consistent: it (silently) acknowledges that there are three dimensions in both the zeros-array and the coords by reporting a problem about not fitting lengths of the third one of each, 'z'. Though by adding a one-dimensional dims-definition, you turn the following error messages away from the original problem, now indeed introducing an inconsistency in dimensions between dims and data. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
199816142 |