initial pass at using pystac instead of sat-stac

[scottyhq]

this is a work in progress for switching the sat-stac dependency to pystac (https://github.com/stac-utils/pystac)

more discussion here #43

[scottyhq]

not sure why the binder badge workflow is failing, should add a badge like:

intake-stac/.github/workflows/binderbadge.yaml

Line 25 in 878bf1b

body: `[](https://mybinder.org/v2/gh/${context.repo.owner}/${context.repo.repo}/${BRANCH_NAME}) :point_left: Launch a binder notebook on this branch`

[![Binder](https://mybinder.org/badge_logo.svg)](https://mybinder.org/v2/gh/scottyhq/intake-stac/pystac) :point_left: Launch a binder notebook on this branch

👈 Launch a binder notebook on this branch

[scottyhq]

previous implementation assumes asset URLs are compatible with the path_as_pattern extraction of coordinate values from the URL. I don't think we should require that. The downside is that you end up with repeating coordinate values by default (e.g. band = [1,1,1] since xr.open_rasterio() defaults to opening each file with band = [1])

[jhamman]

Is there any way to intuit the band numbering or ordering. If so, we can always fill in the coordinate values after the fact.

[scottyhq]

@jhamman this is where I get confused. Ultimately we create an intake entry and then delegate opening to intake-xarray plugin (https://github.com/intake/intake-xarray/blob/master/intake_xarray/raster.py). if path_as_pattern is not specified, we return an xarray dataset with bands = [1,1,1...] etc. Consequently, here is what the user interface currently looks like:

list_of_bands = ['B1', 'B2']
stack = item.stack_bands(list_of_bands)
da = stack().to_dask()
da['band'] = list_of_bands 
da

question for @martindurant how to specify the coordinates of the returned xarray dataarray? Unless we can override driver methods in this library, if I understand correctly we'd need to add a kwarg here https://github.com/intake/intake-xarray/blob/1883e30a0faab6a07e7e522bf45bc96e80f62f2c/intake_xarray/raster.py#L60

[martindurant]

Yes, I think that's right.
intake-xarray has emerged as a sort of glue with various options, so it would be inkeeping with current evolution; but we might want to have a chat more generally about what intake-xarray is really trying to achieve. I mean, one might delegate all kwargs to xarray, or one might try to build out a set of helper methods and extra logic that only make sense at this slightly higher level. We currently do a bit of both.

[scottyhq]

@jhamman i'd appreciate some input on this. I view it as important to finish up before tackling other open issues. I'm currently running through notebook examples to get them to work. Would be nice to have them run and be rendered straight into the docs as is done https://corteva.github.io/rioxarray/stable/examples/examples.html . But that be a separate PR.

I also think it would be good to add a number of additional tests. Perhaps mirroring some example files in a tests data folder so that we're not relying on the existence and naming schemes of other repositories. Also seems best for a separate PR. this one is already lots of changes!

[jhamman]

Thanks for working on this! It's looking great. A few comments for discussion and pinged a few outside folks that may help make some of the finer design decisions.

[jhamman]

Is there any way to intuit the band numbering or ordering. If so, we can always fill in the coordinate values after the fact.

[TomAugspurger]

@scottyhq I made a PR to your branch scottyhq#5

[scottyhq]

thanks everyone for the feedback. i'm planning to go ahead and merge as-is. followups:

• figure out design around intake-xarray and xarray backend refactor (initial pass at using pystac instead of sat-stac #72 (comment))
• improve documentation
• add more tests
• figure out ways to integrate with https://github.com/stac-utils/stac-vrt

[TomAugspurger]

figure out ways to integrate with https://github.com/stac-utils/stac-vrt

I'm happy to take care of that one :)