Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    James Santucci
    @jisantuc
    i also am curious about what time zone
    Matthias Mohr
    @m-mohr
    East cost - or let's say it's 13:00-15:00 UTC
    James Santucci
    @jisantuc
    if it can magically be exactly 9:30 EST, that would be best for me
    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
    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"
          }
        }
      }