}
```
Thanks to rioxarray and xarray’s coordinates, this has all the `proj` information necessary for tools like stackstac, so kind of a round-trip from DataArray → {STAC + COG} → DataArray is possible:
(I noticed that I’m off by one on the size there).
* * *
Hopefully that example makes the use-case clear. Looking forward to any thoughts from people who have dealt with this before. Thanks!
---
### Author:  [@kirill.kzb](https://discourse.pangeo.io/u/kirill.kzb)
#### Post date: [November 22, 2021, 11:16pm UTC](https://discourse.pangeo.io/t/generating-cogs-and-stac-items-from-dataarrays/1913/2 "2021-11-22T23:16:04Z")
Naming conventions are hard to design, especially for generic case. On one hand you want readability and compactness on the other hand you want to include enough information to have unique paths and possibly filenames too, you also want that information to be “glance-able by a human” (hence compactness is a plus).
I think for library/tool design you are better off starting with some sort of “path construction DSL”, then come up with reasonable default for that. This DSL could be as simple as Python format string with a bunch of properties made available to it, things like band name and various kinds of date/time representations and who knows what else, like keys from STAC properties.
Regarding specific examples in your post, I must say I’m not a fan ☹, sorry.
1. I doubt a lot of people have a good idea what UTM coordinate `-y=4800000.0-x=454860.0` corresponds to, also without knowing which UTM zone that is it’s not even possible to tell.
2. Other problem with raw coordinates is that they can be negative, and in this case you end up with two kinds of meaning for `-` character: a separator and a negative sign. This also ruins column alignment as negative coordinates have extra character to them, you might want to balance that with a `+` for positive values, but `+` is problematic for URLs so is not a good idea to include that. And then there are lon/lat which require a lot of precision. I’d say coordinates in a file path are just not practical.
3. Band is a primary property, so maybe replace `band={band}` with just `{band}`
4. Using correct amount of precision for timestamps would be good, but might be hard without out-of-band information provided by an operator.
I personally prefer notation where file name is just `{band}.tif` and all other identifying information is in the directory path. The path is then either `{time}/{space}` or `{space}/{time}` with various levels of nesting for both `{time}` and `{space}` components. Problem with that notation however is that file paths are not unique so you can’t easily just download a bunch into a folder for debugging without renaming as you go.
Regarding “off by one” error: `stackstac` defaults to using top-left corner for your `x/y` coordinates, but `rio-xarray` probably expects pixel centers. So you might end up with off by half a pixel transform written to TIFF, then when `stackstac` loads it back it does “pixel grid snapping” and so wants to offset everything by half a pixel. I wish `stackstac` had `xy_coords="center"` as a default instead. I haven’t actually ran any of that it’s just a guess…
---
### Author:  [@kirill.kzb](https://discourse.pangeo.io/u/kirill.kzb)
#### Post date: [November 23, 2021, 12:55am UTC](https://discourse.pangeo.io/t/generating-cogs-and-stac-items-from-dataarrays/1913/3 "2021-11-23T00:55:31Z")
Also see this issue in stackstac
>
>
> Hi all!
> Either the shift in pixels that I have observed is actually unexpected… and needs to somehow be adjusted in the \`to\_coords\` function or I'm simply missing something or misunderstanding the concept behind geotransforms and it's only unexpected for me at the moment. Hope someone can help me out either way 🙂
>
> In the following screenshots, the colored image is always the original raster, while the greyscale image is always the one created with these lines of code:
> \`\`\`
> scene\_stack = stackstac.stack(items=stac\_obj, xy\_coords=xy\_coords, dtype='float32', rescale=False)
> scene\_stack.rio.to\_raster('./scene\_stack.tif')
> \`\`\`
> Transform and projection of the raster: \`'proj:transform': \[10, 0, 399960, 0, -10, 52000020\]\` & \`'proj:epsg': 32632\` (UTM 32N)
>
> 1. \`xy\_coords=False\`
> !\[xycoords\_false\](https://user-images.githubusercontent.com/56583917/130591389-14c6af0e-5584-4e6c-b650-8d8a1b58ad78.png)
>
> 2. \`xy\_coords='center'\` | pixel shift: 0, 1 (expected: 0.5, -0.5)
> !\[xycoords\_center\](https://user-images.githubusercontent.com/56583917/130591410-7bf632cb-c978-4742-9ad8-03404e1e9530.png)
>
> 3. \`xy\_coords='topleft'\` | pixel shift: -0.5, 0.5 (expected: 0, 0)
> !\[xycoords\_topleft\](https://user-images.githubusercontent.com/56583917/130591422-121d3ea7-37b4-43cc-a8ea-b07fc1fdebd4.png)
>
> As expected, no shift is observed in (1). Now with (2) and (3), I'm confused. My original raster is a COG following the usual raster conventions, e.g. being top left aligned. Therefore I'd assume that using the default as in (3) results in no pixel shift at all. I'd also assume that the pixels are shifted by 0.5 and -0.5 in x and y respectively when using 'center' as in (2).
>
> Looking forward to hearing some other thoughts on this!
>
> Cheers, Marco
---
### Author:  [@TomAugspurger](https://discourse.pangeo.io/u/TomAugspurger)
#### Post date: [November 24, 2021, 9:37pm UTC](https://discourse.pangeo.io/t/generating-cogs-and-stac-items-from-dataarrays/1913/4 "2021-11-24T21:37:19Z")
Thanks for the feedback!
> On one hand you want readability and compactness on the other hand you want to include enough information to have unique paths and possibly filenames too, you also want that information to be “glance-able by a human”
This is a really important point. One additional thing to consider: now that we have STAC, maybe the balance should swing more towards uniqueness? In my mind, this pile of COGs would be easiest to explore / debug if you had STAC items for them. An initial prototype of this just used `dask.base.tokenize` on each chunk, which generated a unique string but was completely unreadable by humans. So the combination of `time/band, y, x` was a way to try to get uniqueness in a more human-friendly way.
My workflow was assuming blob storage, so I didn’t put much thought into nested directories vs. a flat namespace.
---
### Author:  [@kirill.kzb](https://discourse.pangeo.io/u/kirill.kzb)
#### Post date: [November 24, 2021, 11:01pm UTC](https://discourse.pangeo.io/t/generating-cogs-and-stac-items-from-dataarrays/1913/5 "2021-11-24T23:01:03Z")
> [@TomAugspurger](#):
>
> This is a really important point. One additional thing to consider: now that we have STAC, maybe the balance should swing more towards uniqueness? In my mind, this pile of COGs would be easiest to explore / debug if you had STAC items for them. An initial prototype of this just used `dask.base.tokenize` on each chunk, which generated a unique string but was completely unreadable by humans. So the combination of `time/band, y, x` was a way to try to get uniqueness in a more human-friendly way.
What is “human-friendly” depends on a workflow I suppose. One extreme is to just use UUID or hash and nothing else, this makes it super clear that filename is not to be interpreted directly. Other extreme is to include almost everything in the filename in a somewhat readable form, this only works for specific collections, see Landsat or Sentinel paths for examples of that. Mid point would be something like `{band}-{place}-{time}-{hash}` or `{band}-{time}-{place}-{hash}`, depending on what you value more “grouping by time” or “grouping by place”.
`{time}` is sort of easy, just need to figure out right level of precision, and support ranges and not just points in time. But `{place}` is much harder to do generically, it really only works for tiled data, and even then you need a naming scheme for those tiles. I’d say `{place}` will have to come from the user, maybe an attribute you can set on an xarray? And if it’s not provided by the user just omit it altogether and rely on `{hash}` for uniqueness. I guess you could encode a bounding box of the image into a filename but this will be even less readable and longer than a hash and harder to tab-complete too. If some sort of `{hash}` is too “unhuman”, one can substitute with some random words, like what docker does for container names.
I guess one could use one of those fancy things like [H3](https://eng.uber.com/h3/) to encode `{place}` in a generic way, but that’s getting complicated quick. I’d say better option is to allow user to override those things via attributes or encoding properties of the xarray.
> [@TomAugspurger](#):
>
> My workflow was assuming blob storage, so I didn’t put much thought into nested directories vs. a flat namespace.
In my experience there is still benefit in avoiding “directories” with too many files even when storage medium is some sort of blob store. For example reading COG from a blob store with thousands of “sibling” blobs can be done quickly in software if you configure GDAL right, but sometimes you want to open it in QGIS and there is no obvious way to tell QGIS not to bother looking for side-car files, so QGIS will struggle at open time even though image is COG.