SpatioTemporal Asset Catalog/Lobby

Matthew Hanson

@matthewhanson

We’ll start somewhere between 9 and 9:30 EST, join when you can! Will post here in the morning

2 replies

Josh Fix

@joshfix

i’m checking in for the day and checking out for the night. i had major headaches with some IDE issues for the majority of the day, but once resolved, was able to get the STAC GeoTools store working for assets on S3. it can render any image in a stac collection by passing in the item ID. i will be working on expading to support any http endpoint and enabling COG support tomorrow.

Chris Holmes

@cholmes

Awesome work @joshfix!

Matthias Mohr

@m-mohr

@matthewhanson Waiting to be let into the API room ;-)

Matthew Hanson

@matthewhanson

oh API room

I was in the main lobby

Matthias Mohr

@m-mohr

Also fine with main lobby, but you wrote API yesterday ;-)

Then let's meet in the main lobby.

Matthew Hanson

@matthewhanson

That was before we ditched all those rooms.
@m-mohr will be in main lobby for a bit going through stac-api-spec issues:
https://planet.zoom.us/j/93187144321

Matthias Mohr

@m-mohr

We've written a full comparison for the STAC validators so that people can find the right validator for their use case: https://github.com/m-mohr/stac-node-validator/blob/master/COMPARISON.md - It's WIP, but should be mostly correct. ;-)

@cholmes That's probably a useful doc for the data sprint.

Chris Holmes

@cholmes

yes - definitely a very useful doc for the data sprint.

Emmanuel Mathot

@emmanuelmathot

I just pushed the first public release of DotNetStac: https://github.com/Terradue/DotNetStac [0.2.0-beta]

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

just https://cmr.earthdata.nasa.gov/cmr-stac

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

Where communities thrive

People

Repo info

Activity