proj:transform and proj:shape in assets #11
Comments
|
Yeah, I recall something in the Anyway, agreed that we should have some way to handle this case. |
|
Sounds good @TomAugspurger I updated the original post to change "target_band" to "target_asset". Quickly glancing at build_vrt, is it currently hardcoded to In the Sentinel Catalog the assets look like: stac_items[0]['assets'].keys()
dict_keys(['thumbnail', 'overview', 'info', 'metadata', 'visual', 'B01', 'B02', 'B03', 'B04', 'B05', 'B06', 'B07', 'B08', 'B8A', 'B09', 'B11', 'B12', 'AOT', 'WVP', 'SCL'])Cheers |
|
Thanks. Just a general comment that right now The NAIP dataset stores the four bands in a single COG. The AWS Sentinel data looks to have multiple assets (COGs) per STAC item. So we'll need some way of indicating which assets will be put into the VRT. Right now we have something like build_vrt(naip_data, asset_key="image")which returns a VRT that has multiple bands since the COGs have multiple bands. Would a user ever do something like build_vrt(sentinel_data, asset_key=["B01", "B02"])which would return a similar VRT (multiple bands) that have been stacked together? |
Looking at Now, my imagined use case for If you have API suggestions it'd be great to hear them. I think my initial preference is to preserve a single cc @scottyhq, if you have thoughts on the API design as well. Anything we should consider from xarray? |
|
My 2cents would be to use Not sure if this is the correct place to put these ideas, but I wanted to mention a few other functionalities that I think would be useful to think about including:
|
|
Hi @rmg55 and @TomAugspurger . Very excited about the potential for stac-vrt for both mosaicing and stacking! These ideas are all great. A lot of this discussion has come up over in intake/intake-stac#65, and I'm thinking I'll open a draft PR over there to more easily comment on API ideas. I've found working with several available catalogs has been key given how relevant info can be stored in different places via extensions, there is some churn in itemcollections returned by stac-search results (stac-utils/pystac#256 (comment)) versus static catalogs, and not everything is implemented yet in pystac (e.g. stac-utils/pystac#132)
In brief, my recommendation would be to keep the keyword arguments in build_vrt() as close as possible to gdal's buildvrt. for example As for 'asset' or 'asset_key'... 'asset_key' can be anything for better or worse ('B04', 'visual', 'random-name'). One of my favorite features of intake-stac is the mapping between eo:bands common names to assets though. For example it's really nice as a user to say |
|
Thanks @scottyhq great points (especially the
If working in the same tile (and temporally stacking assets), then yes, we should have a consistent CRS. However, if mosaicing, I don't think this is the case . For instance here is an example with the Sentinel STAC where we would probably want to reproject into a geographic projection (e.g. epsg:4326). Perhaps I am missing something her though? import satsearch
URL='https://earth-search.aws.element84.com/v0'
results = satsearch.Search.search(url=URL,
collections=['sentinel-s2-l2a-cogs'],
bbox=[-110.791,39.783,-50.677,41.870],
datetime='2021-02-27/2021-02-27')
stac_catalog = results.items().geojson()
for assets in stac_items:
print('Projection:',
'epsg:'+str(assets['properties']['proj:epsg']),
'UTM Zone:',
assets['properties']['sentinel:utm_zone'],
'Lat. Band:',
assets['properties']['sentinel:latitude_band'],
'Grid Square:',
assets['properties']['sentinel:grid_square']) |
|
These are some great features, some random thoughts:
|
|
Noting here that I'm creating Items where PySTAC allows you to pull a property from an asset if available, and if not checks the properties of the Item. e.g. in asset_key: str = ...
item: pystac.Item = ...
bbox: Optional[List[float]] = item.ext.projection.get_bbox(item.assets[asset_key])
|
|
I don't think resolution : average makes sense, either @scottyhq - not for multispectral satellite data, anyway. Landsat 8 - 30s, 15s and 100s for example. Reprojection - not necessarily geographic @rmg55 - you could have say Australian or European or South American projected coordinate systems for larger scale areas you may want to use - so possibly an option? |
It looks like some catalogs have the transform and shape in the assets (I think that is the correct term) rather than the properties. Probably due to the bands/assets have different resolutions. For instance:
output
Perhaps adding a "target_asset" keyword to build_vrt, then update the logic on shapes/transform to somthing like:
Happy to work up a PR if this seems like a good route.
The text was updated successfully, but these errors were encountered: