issue_comments

Thanks @spencerkclark, I had almost the exact same code already written but couldn't figure out the return value resample.apply needs from func to work. I added the tests to test_dataarray and test_dataset, since there doesn't appear to be a separate file for resample (as there is for groupby).

I added tests for groupby. I haven't used resampling so I'm struggling a bit to make a sensible dataset/array for a similar test of the resample method.

@fmaussion Seems okay to me. The rasterio version check is a bit iffy but I can't think of a way to do it better.

I do agree with @snowman2 though, having the coordinate generation separately exposed would be nice (and easier to write unit tests for). Something like ```python def xy_pixel_coordinates(nx, ny, transform=None) transform = Affine.identity if not transform else transform

# xarray coordinates are pixel centered
x, _ = (np.arange(nx)+0.5, np.zeros(nx)+0.5) * transform
_, y = (np.zeros(ny)+0.5, np.arange(ny)+0.5) * transform
return x,y

``` would probably suffice, though I don't know which module this would fall under. I'd imagine it might be useful for backends besides rasterio, though.

Just looking at the rasterio quickstart, it seems that it'd be easy to generate the coordinates using the Affine instance (though that is only available in Rasterio > 1.0a, with 0.36.0 you just have the tuple containing the multipliers). I think that might solve the problem though, since I would expect the sign of resand the transform to be synchronized to the same convention on the rasterio side, which might be breaking with the current code.

@jhamman Any comments on the current implementation? I'm not sure how to handle possible collisions with the tag parsing and existing xarray attributes / coordinates with the same name.

Also, while writing the test for this, I found out that rasterio < 1.0a doesn't support saving the tags to the file, so I added a version check there.

@shoyer I had to think a bit on your suggestion to figure out a way to make the name parameter work for the recursive cases, but now here's something to that effect. Also made me wonder how useful a test suite for testing test failures would be...

@fmaussion Thanks! I get the feeling there's probably something odd with rasterio here. I played around a bit and found that rasterio doesn't seem to care about the signs in the transform if the given upper left is (0,0) . Giving any of from_origin(0, 0, i, j) for i, j = +-1 as the transform gives a warning about using the default geotransform and doesn't save it to the file.

@fmaussion I've tested with both rasterio 0.36.0 and the current master branch (1.0a11), both seem to have the same behaviour.

@fmaussion Do you have an example of a rasterio object that would fail serialization?

@fmaussion Ah, didn't think of that. That should probably be a separate test though. You're right about the name change, I thought of it already but forgot to change them.

I think I found a way to make the metadata parsing a bit more general and extendable. I implemented a more general parser for the ENVI case as a proof of concept.

Now if a recognized driver is detected, instead of parsing tags(band) for each band, it queries the metadata domain for the driver using riods.tags(ns=riods.driver) and then munges any known arrays into a numpy format. Later the resulting dictionary is slotted into either coordinates or attributes based on the values type. This should make it pretty easy to implement parsers for different file formats without caring about the partial parsing done by GDAL for the other tags() calls.

Had some more time to look at this. It seems rasterio just passes the the info returned by GDAL, since looking at the files using gdalinfo reveals exactly the same data (with only wavelengths parsed for each band, etc). Apparently gdalinfo can (since GDAL 1.11) also list the available metadata domains (namespaces) in the file, or output all the metadata given the domain 'all'. These don't seem yet to be implemented in rasterio.

@jhamman, I did some looking around. The rasterio documentation on tags does not reveal much and points to the only slightly less unhelpful GDAL data model documentation. There seem to be both namespaces containing file format specific data, and general namespaces which contain data parsed from the format specific namespaces. The format namespaces/domains are mentioned in the GDAL raster format documentation, but don't really tell much of the type of data stored.

For ENVI files, there seems to already be three different kinds of return values depending on the exact call:

• tags() returns a dict full of strings created from the wavelength info in the header file: {'Band_1':'450 nm', 'Band_2':'452', ..., 'wavelength_units':'nm'}

• tags(b) returns a dict containing the info for the band b in a slightly different format: {'wavelength':450.00, 'wavelength_units':'nm'}

• tags(ns='ENVI') returns a dict of string values, containing all the fields in the header file in their original form: python {'Description':'file.dat', 'wavelength':'{450, 452, ...}', 'fwhm':'{3.0, 3.0, ...}', etc.}

• Other namespaces I tried seemed to return only empty dicts (for the ENVI file).

It's a bit puzzling why only the wavelength information (and not even the corresponding FWHM info) is parsed to the default namespace, given that it's not listed as having any well defined semantics in the GDAL docs.