Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Matthias Mohr
    @m-mohr
    for all posted above
    Chris Holmes
    @cholmes
    Ah, thanks! I see it now.
    I think I'm going to just use the main room for the intro session. As it's just me and Matt on right now.
    If anyone wants to an overview of the spec or to ask more intro questions join me at https://planet.zoom.us/j/93187144321 (I'm just using the main zoom room, since apparently I can't start more than one zoom meeting at once from my account)
    Chris Holmes
    @cholmes
    The 27 reply thread above now has its own room: https://gitter.im/SpatioTemporal-Asset-Catalog/dynamic-tiling
    and other topics around making on the fly tile services from STAC catalogs.
    Kurt Schwehr
    @schwehr
    Working on catching up to all the discussions
    Grigory
    @pomadchin
    What is the result of radiantearth/stac-spec#741 ? it has a 1.0.0-beta.3 milestone; so what are the thoughts about having items that belong to multiple collections?
    Matthias Mohr
    @m-mohr
    @pomadchin I don't think there's a solution yet. The issue with multiple "parent" collections is that items can inherit some data from Collections (Item Assets) and then it's not clear how to resolve conflicts and multi-inheritance in general is always more complex than you usually like it to be.
    Matthew Hanson
    @matthewhanson
    Conversation in the Python room on uniqueness of Item IDs across a Catalog
    Matthew Hanson
    @matthewhanson
    @m-mohr and I are going to be doing some issue triage on the stag-api-spec repo tomorrow morning somewhere between 9-11AM in the API room, if anyone else wants to join. @cholmes @joshfix @pomadchin @jisantuc
    6 replies
    Chris Holmes
    @cholmes
    what time zone?
    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