Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Rob Emanuele
    @lossyrob
    @sharkinsspatial Also for the multiple extension typing issue: this is how I worked around that; considering extensions as separate types that modify the stac object instead of inheriting from the core object types.
    Interested in your thoughts on what sort of suite you mentioned should look like.
    Matthias Mohr
    @m-mohr
    What's the multiple extensions typing issue?
    Rob Emanuele
    @lossyrob
    @m-mohr for extensions like eo, it seems like an obvious solution to model things as an inherited class, e.g. EOItem from Item. That's how PySTAC originally approached it. However, when you end up with multiple extensions (e.g. eo and view), that model breaks
    Matthias Mohr
    @m-mohr
    Oh I see, because you don't have multi inheritance. Thanks.
    Rob Emanuele
    @lossyrob
    Python does have multi-inheritance, but it becomes a combinatorially explosive problem when you need to account for all extensions/requires dynamic extension at runtime that is hard to account for. So the solution that we put in place is to ditch extension inheritance for extension composition.
    Rob Emanuele
    @lossyrob
    I'm looking to create a CLI that leans on PySTAC to allow for STAC manipulation and validation. Is anyone else working on a CLI?
    Vincent Sarago
    @vincentsarago
    :wave: I’m quite busy today but I’m happy to help anyone on COG/dynamic tiling questions
    27 replies
    Chris Holmes
    @cholmes
    Ugh, sorry about the break out zoom rooms not working...
    Matthias Mohr
    @m-mohr
    Did so
    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?