issue_comments: 379815753

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/2042#issuecomment-379815753 https://api.github.com/repos/pydata/xarray/issues/2042 379815753 MDEyOklzc3VlQ29tbWVudDM3OTgxNTc1Mw== 601025 2018-04-09T16:39:28Z 2018-04-09T16:39:28Z NONE

On Apr 9 2018 9:22 AM, Ryan Abernathey wrote:

I'm already starting to think that these kind of domain specific tools should exist in dedicated projects, not in the main xarray codebase.

👍

I am perfectly fine with that stance, but I also think it is also reasonable to ask/expect that if you provide a reader for some format that you also provide writers for them -- or at least document that you will not and why. Almost all of my current work is in geotiff format.
I have no choice, and many other people working in the geospatial domain will be hamstrung without it. Sitting down the pipeline from me is 1/2 million archived images (there are actually closer to 2 million images, but only 1/2 to 1 is associated with out current projects, and comprise several petabytes of data).

I really need to know what xarray can and is planning to do with tiff's so that I can not only use them but also document stuff for a dozen or more of my coworkers (heck the next time we run the Python Bootcamp I would probably offer to teach this). If you plan not to support it then fine. I will not spend any more time with xarrays and focus on dask.arrays or anything else that will work.

My question to you now is if supporting basic tiff I/O is in scope. If so I can deal with all the rest of the rasterio/geospatial stuff outside of xarray.

I will start fleshing out the stuff that Matthew Rocklin and Schlump have provided.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   312203596