Implement asset-role for STAC results

[mike-gangl]

My use case is given a CMR granule in stac format, i want to download the data files locally for processing. Given a collection with multiple data files, we are returned STAC results like the following: https://cmr.earthdata.nasa.gov/search/concepts/G2813285105-LPCLOUD.stac

the keys to the assets are as follows:

"metadata": {
"href": "[https://cmr.earthdata.nasa.gov:443/search/concepts/G2813285105-LPCLOUD.xml](https://cmr.earthdata.nasa.gov/search/concepts/G2813285105-LPCLOUD.xml)",
"type": "application/xml"
},
"browse": {
"title": "Download EMIT_L1B_RAD_001_20231206T160939_2334011_006.png",
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-public/EMITL1BRAD.001/EMIT_L1B_RAD_001_20231206T160939_2334011_006/EMIT_L1B_RAD_001_20231206T160939_2334011_006.png",
"type": "image/png"
},
"opendap": {
"title": "OPeNDAP request URL",
"href": "https://opendap.earthdata.nasa.gov/collections/C2408009906-LPCLOUD/granules/EMIT_L1B_RAD_001_20231206T160939_2334011_006"
},
"data": {
"title": "Download EMIT_L1B_RAD_001_20231206T160939_2334011_006.nc",
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/EMITL1BRAD.001/EMIT_L1B_RAD_001_20231206T160939_2334011_006/EMIT_L1B_RAD_001_20231206T160939_2334011_006.nc"
},
"data1": {
"title": "Download EMIT_L1B_OBS_001_20231206T160939_2334011_006.nc",
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/EMITL1BRAD.001/EMIT_L1B_RAD_001_20231206T160939_2334011_006/EMIT_L1B_OBS_001_20231206T160939_2334011_006.nc"
}

This requires us to look for the keys data and data1 (and possibly more). This is non-ideal when stac supports the asset-role which is made directly for this use case. The keys to the file can be whatever, but they would have the asset roles included that can then be interrogated for download. Also, things like "thumbnail" can be made as preview images is clients like the STAC-Browser. Most of this information is already available in the umm-g collections, though a more exhaustive mapping might be needed.

https://cmr.earthdata.nasa.gov/search/concepts/G2813285105-LPCLOUD.umm_json

umm-g --> Asset role:
"Type": "GET DATA" --> data
"Type": "GET RELATED VISUALIZATION" --> thumbnail
"Type": "EXTENDED METADATA" --> metadata
"Type": "VIEW RELATED INFORMATION" --> overview

[jaybarra]

@mike-gangl would you be able to replicate this search using the existing STAC endpoint for that granule? That uses type aware keys in the assets and does differentiate.

[mike-gangl]

Thanks for the reply. That endpoint seems to do the correct thing the link you provided didn't resolve, but this one does..

I think our issue is that we are hitting the CMR search because it offers more powerful search syntax- unless the stac endpoint does all that now. But the different response formats is troubling to us as we expect our users to identify a STAC catlog for us to read, and that might come from the CMR search or the STAC search.

[doug-newman-nasa]

Re-surfacing this. CMR-STAC results and results returned from CMR in the STAC format should be identical in all aspects except links related to the server in question.