Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Orestis Herodotou
    @digitaltopo
    @matthewhanson for the CMR root catalog, would this be enough to make it a valid stac catalog?
    {
      "stac_version": "1.0.0-beta.1",
      "id": "cmr-stac",
      "title":"NASA Common Metadata Repository Root STAC Catalog",
      "description": "This is the landing page for CMR-STAC. Each provider link below contains a STAC endpoint.",
      "links": [
        { "rel": "self", "href": "https://cmr.earthdata.nasa.gov/cmr-stac/catalog.json" },
        { "rel": "root", "href": "https://cmr.earthdata.nasa.gov/cmr-stac/catalog.json" },
        {
          "id": "USGS_EROS",
          "title": "USGS_EROS",
          "description": "Root catalog for USGS_EROS",
          "stac_version": "1.0.0-beta.1",
          "rel": "provider",
          "type": "application/json",
          "links": [
            {
              "rel": "self",
              "href": "https://cmr.earthdata.nasa.gov/cmr-stac/USGS_EROS",
              "title": "Root endpoint for this provider",
              "type": "application/json"
            },
            {
              "rel": "root",
              "href": "https://cmr.earthdata.nasa.gov/cmr-stac/",
              "title": "CMR-STAC Root",
              "type": "application/json"
            },
            {
              "rel": "collections",
              "href": "https://cmr.earthdata.nasa.gov/cmr-stac/USGS_EROS/collections",
              "title": "Collections for this provider",
              "type": "application/json"
            },
            {
              "rel": "search",
              "href": "https://cmr.earthdata.nasa.gov/cmr-stac/USGS_EROS/search",
              "title": "STAC Search endpoint for this provider",
              "type": "application/json"
            }
          ]
        },
        ...other catalogs...
      ]
    }
    Matthias Mohr
    @m-mohr
    No, the links must also all be valid (rel, href, ...)
    Orestis Herodotou
    @digitaltopo
    or would the child catalogs links at this root level need to be "rel":"child" instead of provider
    Matthias Mohr
    @m-mohr
    It looks weird how the whole catalogs are in the links array. Should just link to the self link provided for reach catalog
    yes
    Matthew Hanson
    @matthewhanson
    I think we can just link to the single root catalog for each provider
    Matthias Mohr
    @m-mohr
    for the example:
    { "rel": "child", "href": "https://cmr.earthdata.nasa.gov/cmr-stac/USGS_EROS", title: "USGS_EROS", "type": "application/json" },
    yes
    Orestis Herodotou
    @digitaltopo
    True, although for the index, we're going to represent the whole thing as a stac catalog
    Matthias Mohr
    @m-mohr
    But that's not an issue at all, I think
    Orestis Herodotou
    @digitaltopo
    Yeah, I see what you mean by cutting out the extra properties per each child catalog at this level, i guess in general does that matter? for example, if they were left there, would this be a valid static catalog?
    Matthew Hanson
    @matthewhanson
    So I think like this:
    {
      "stac_version": "1.0.0-beta.2",
      "id": "cmr-stac",
      "title":"NASA Common Metadata Repository Root STAC Catalog",
      "description": "This is the landing page for CMR-STAC. Each provider link below contains a STAC endpoint.",
      "links": [
        { "rel": "self", "href": "https://cmr.earthdata.nasa.gov/cmr-stac/catalog.json" },
        { "rel": "root", "href": "https://cmr.earthdata.nasa.gov/cmr-stac/catalog.json" },
        {
          "title": "USGS_EROS",
          "rel": "child",
          "type": "application/json",
          "href": "https://cmr.earthdata.nasa.gov/cmr-stac/USGS_EROS"
        },
        ...other catalogs...
      ]
    }
    Orestis Herodotou
    @digitaltopo
    yep
    Does type even need to be there?
    Matthias Mohr
    @m-mohr
    looks good. Type is likely application/json by default, so is a bit redundant, but doesn't make anything worse if it's there
    Orestis Herodotou
    @digitaltopo
    :+1:
    Matthew Hanson
    @matthewhanson
    Ok…actually links are wrong for self and root, shouldn’t end in catalog.json
    Orestis Herodotou
    @digitaltopo
    wrong according to the spec or wrong in reality? (i know the actual url right now is https://cmr.earthdata.nasa.gov/cmr-stac)
    I'm trying to imagine if that page was a valid stac catalog itself
    Matthew Hanson
    @matthewhanson
    Just incorrect in reality….the spec doesn’t specify it has to be named catalog.json, that would be a best practice for a static catalog
    Orestis Herodotou
    @digitaltopo
    Yeah cool
    Orestis Herodotou
    @digitaltopo
    ex) main root for cmr:
      "stac_version": "1.0.0-beta.1",
      "id": "cmr-stac",
      "title": "NASA Common Metadata Repository Root STAC Catalog",
      "description": "This is the landing page for CMR-STAC. Each provider link below contains a STAC endpoint.",
      "links": [
        {
          "rel": "self",
          "href": "catalog.json"
        },
        {
          "rel": "root",
          "href": "catalog.json"
        },
        {
          "title": "LARC_ASDC",
          "rel": "child",
          "href": "https://cmr.earthdata.nasa.gov/cmr-stac/LARC_ASDC"
        },...]}
    Matthias Mohr
    @m-mohr
    @matthewhanson Is it by intention that CMR STAC doesn't send CORS headers?
    Matthew Hanson
    @matthewhanson
    Not sure, I’ll find out.
    Could be just that it hadn’t come up
    Matthias Mohr
    @m-mohr
    Great, it works for Earth Search (see here), just not for CMR (see here)
    Tom Auer
    @tomauer
    Hey @m-mohr, following up from Twitter about using eo:bands to describe tif in more detail. I read the spec for eo:bands and it is remote sensing oriented. I was hoping there was a date field, but considering there's not, do you think it would be useful and put the date in the Band Object name field?
    Matthew Hanson
    @matthewhanson
    @tomauer Just caught up on the twitter thread. I think eo:bands is not thing to use here, to define each band being a week.
    The STAC Item will contain the begin and end time for the year though, is specifying the datetime range for each band in the file needed? Or is a user going to already know that going in?
    I guess what I’m asking is what advantage is gained by embedding the datetimes for the weeks within the Asset metadata?
    Tom Auer
    @tomauer
    I'm not entirely sure...especially from a STAC perspective, I just thought it might be useful for users to know they're getting a 52 band cube up front, which isn't described elsewhere.
    And be able to programmatically provide the specific dates somewhere...although they are stored cryptically in the tif too
    Rob Emanuele
    @lossyrob
    Would this info be better supplied via the data cube extension?
    Tom Auer
    @tomauer
    yes, that looks helpful
    Tom Auer
    @tomauer
    Thoughts on this?
    "properties": {
        "datetime": null,
        "collection": "ebirdst",
        "cube:dimensions": {
          "time": {
            "type": "temporal",
            "description": "Each band represent a distinct week centered on the date decsribed in the values here.",
            "extent": ["2018-01-04T00:00:00Z", "2018-12-28T00:00:00Z"],
            "values": ["2018-01-04T12:00:00Z", "2018-01-11T12:00:00Z", "2018-01-18T12:00:00Z", "2018-01-25T12:00:00Z", "2018-02-01T12:00:00Z", "2018-02-08T12:00:00Z", "2018-02-15T12:00:00Z", "2018-02-22T12:00:00Z", "2018-03-01T12:00:00Z", "2018-03-08T12:00:00Z", "2018-03-15T12:00:00Z", "2018-03-22T12:00:00Z", "2018-03-29T12:00:00Z", "2018-04-05T12:00:00Z", "2018-04-12T12:00:00Z", "2018-04-19T12:00:00Z", "2018-04-26T12:00:00Z", "2018-05-03T12:00:00Z", "2018-05-10T12:00:00Z", "2018-05-17T12:00:00Z", "2018-05-24T12:00:00Z", "2018-05-31T12:00:00Z", "2018-06-07T12:00:00Z", "2018-06-14T12:00:00Z", "2018-06-21T12:00:00Z", "2018-06-28T12:00:00Z", "2018-07-06T12:00:00Z", "2018-07-13T12:00:00Z", "2018-07-20T12:00:00Z", "2018-07-27T12:00:00Z", "2018-08-03T12:00:00Z", "2018-08-10T12:00:00Z", "2018-08-17T12:00:00Z", "2018-08-24T12:00:00Z", "2018-08-31T12:00:00Z", "2018-09-07T12:00:00Z", "2018-09-14T12:00:00Z", "2018-09-21T12:00:00Z", "2018-09-28T12:00:00Z", "2018-10-05T12:00:00Z", "2018-10-12T12:00:00Z", "2018-10-19T12:00:00Z", "2018-10-26T12:00:00Z", "2018-11-02T12:00:00Z", "2018-11-09T12:00:00Z", "2018-11-16T12:00:00Z", "2018-11-23T12:00:00Z", "2018-11-30T12:00:00Z", "2018-12-07T12:00:00Z", "2018-12-14T12:00:00Z", "2018-12-21T12:00:00Z", "2018-12-28T12:00:00Z"],
            "step": "P7DT9H13M51S"
          }
        }
      }
    Matthias Mohr
    @m-mohr
    Oh yes, that makes more sense. You could omit extent, it's clear from the values. Are there more dimensions to specify?
    It likely has spatial dimensions, right?
    Matthew Hanson
    @matthewhanson
    @m-mohr How can you link the cube:dimensions to assets? I know you had originally developed this extension for collections only
    Matthias Mohr
    @m-mohr
    Like eo:bands. Datacube is defined for Collections and Items. We allowed all item properties in assets, right?
    Matthew Hanson
    @matthewhanson
    ah ok, so use ‘cube:dimensions` in the data asset
    Matthias Mohr
    @m-mohr
    Yes
    Matthias Mohr
    @m-mohr
    We should work on making the schemas aware of that, too
    Tom Auer
    @tomauer
    Updated with other dimensions and moved to asset data property.
    "assets":{
          "data":{
             "href":"results/tif/bbwduc-ERD2018-EBIRD_SCIENCE-20191105-dc3957b5_hr_2018_abundance_median.tif",
             "title":"Black-bellied Whistling-Duck 2018 Relative Abundance Data Cube",
             "type":"image/tiff; application=geotiff; profile=cloud-optimized",
             "cube:dimensions":{
                "x":{
                   "type":"spatial",
                   "axis":"x",
                   "extent":[
                      -11295569.3520532,
                      -4149279.68684902
                   ],
                   "reference_system":6842
                },
                "y":{
                   "type":"spatial",
                   "axis":"y",
                   "extent":[
                      -4098378.87654,
                      5181138.84866212
                   ],
                   "reference_system":6842
                },
                "time":{
                   "type":"temporal",
                   "description":"Each band represent a distinct week centered on the date decsribed in the values here.",
                   "values":[
                      "2018-01-04T12:00:00Z",
                      "2018-01-11T12:00:00Z",
                      "2018-01-18T12:00:00Z",
                      "2018-01-25T12:00:00Z",
                      "2018-02-01T12:00:00Z",
                      "2018-02-08T12:00:00Z",
                      "2018-02-15T12:00:00Z",
                      "2018-02-22T12:00:00Z",
                      "2018-03-01T12:00:00Z",
                      "2018-03-08T12:00:00Z",
                      "2018-03-15T12:00:00Z",
                      "2018-03-22T12:00:00Z",
                      "2018-03-29T12:00:00Z",
                      "2018-04-05T12:00:00Z",
                      "2018-04-12T12:00:00Z",
                      "2018-04-19T12:00:00Z",
                      "2018-04-26T12:00:00Z",
                      "2018-05-03T12:00:00Z",
                      "2018-05-10T12:00:00Z",
                      "2018-05-17T12:00:00Z",
                      "2018-05-24T12:00:00Z",
                      "2018-05-31T12:00:00Z",
                      "2018-06-07T12:00:00Z",
                      "2018-06-14T12:00:00Z",
                      "2018-06-21T12:00:00Z",
                      "2018-06-28T12:00:00Z",
                      "2018-07-06T12:00:00Z",
                      "2018-07-13T12:00:00Z",
                      "2018-07-20T12:00:00Z",
                      "2018-07-27T12:00:00Z",
                      "2018-08-03T12:00:00Z",
                      "2018-08-10T12:00:00Z",
                      "2018-08-17T12:00:00Z",
                      "2018-08-24T12:00:00Z",
                      "2018-08-31T12:00:00Z",
                      "2018-09-07T12:00:00Z",
                      "2018-09-14T12:00:00Z",
                      "2018-09-21T12:00:00Z",
                      "2018-09-28T12:00:00Z",
                      "2018-10-05T12:00:00Z",
                      "2018-10-12T12:00:00Z",
                      "2018-10-19T12:00:00Z",
                      "2018-10-26T12:00:00Z",
                      "2018-11-02T12:00:00Z",
                      "2018-11-09T12:00:00Z",
                      "2018-11-16T12:00:00Z",
                      "2018-11-23T12:00:00Z",
                      "2018-11-30T12:00:00Z",
                      "2018-12-07T12:00:00Z",
                      "2018-12-14T12:00:00Z",
                      "2018-12-21T12:00:00Z",
                      "2018-12-28T12:00:00Z"
                   ],
                   "step":"P7DT9H13M51S"
                },
                "relative_abundance":{
                   "type":"spatial",
                   "axis":"z",
                   "extent":[
                      0.000141068841912784,
                      1004.65972900391
                   ],
                   "unit":"birds"
                }
             }
          }
       }
    Matthias Mohr
    @m-mohr
    @tomauer That looks very good. "0.000141068841912784 birds" sounds funny on first sight ;-)
    Tom Auer
    @tomauer
    Great, thanks for your help. Dumping them all on AWS now.
    Tom Auer
    @tomauer
    And yes, bird number is a little funny. I wish there was a more concise unit definition of "relative abundance"
    Matthias Mohr
    @m-mohr
    STAC Index now offers a free STAC Browser for every API/Static Catalog submitted! Still very experimental and shows errors for several catalogs, but it's a start :-) Here's CBERS for example: http://stac-index.lutana.de/#/browse/Z8ImEcYd9zZyVMFF cc @lossyrob
    Matthias Mohr
    @m-mohr
    Issue for most catalogs are missing CORS headers, it seems.
    Matthias Mohr
    @m-mohr
    Should we add a best practice that static catalogs and APIs should be deployed with CORS enabled? @matthewhanson @lossyrob
    It seems that at least half of the catalogs currently available in STAC Index doesn't send CORS headers and thus I can't use it with STAC browser or any browser-based tooling.