issue_comments: 302941653

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/pull/1260#issuecomment-302941653 https://api.github.com/repos/pydata/xarray/issues/1260 302941653 MDEyOklzc3VlQ29tbWVudDMwMjk0MTY1Mw== 10050469 2017-05-21T14:54:19Z 2017-05-21T16:05:14Z MEMBER

Thanks @gidden for the comments! Will look into it.

Your questions about the add_latlon makes me think that a kwarg at read time isn't the right approach. Here are the scenarios where you don't want to have the lat/lon computed per defaut: - when your data's crs is already WGS84, in that case x and y are lons and lats already - when your file isn't georeferenced properly - when your use case doesn't need them (salem for example will make better use of crs than xarray) - when your file is large: computing lons and lats on a huge 2D grid is going to be prohibitively expensive.

This latter use case is important, because it might be useful for users to first subset their data and then compute the lat lons. For this use case we could go for two options in place of the kwarg: 1. add a top level utility function get_latlon_from_crs which would work on any dataset with a proper crs (and could be extended) 2. compute lons and lats lazily (only when asked for) 3. do nothing and let the users do their own cuisine (consistent with xarray's general purpose)

I don't know how to do 2 because it implies using dask to compute two related variables at the same time. Furthermore, 2 requires dask while 1 could be extended towards other datasets which have a crs.

Right now I tend towards 3 (because I use salem), although I guess that many users will benefit from 1...

@gidden @shoyer @benbovy : thoughts? 

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