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
    @lossyrob I have a couple of PRs waiting for you in the STAC Browser repo :-)
    Rob Emanuele
    @lossyrob
    :+1: :tada:
    Matthias Mohr
    @m-mohr
    @lossyrob And by the way, with some hacking it was possible to embed STAC browser into another Vue App. Nothing a normal user would do though, so separate components would still be nice at some point.
    Rob Emanuele
    @lossyrob
    nice, glad that worked for you
    agree about the components being the target
    Tom Auer
    @tomauer
    @m-mohr Thanks for help with the STAC browser. I'm fixing the path issue with the tifs.
    What were the other validation issues? I'm seeing a warning sign next to the URLs.
    3 replies
    I just saw the mouse-over on the warning sign
    Tom Auer
    @tomauer
    Is there a way to force the STAC browser to re-read the catalog files? I'm updating them and fixed a path issue, but the tiles are still trying to pull from the old, broken path.
    Tom Auer
    @tomauer
    Seems to have eventually done it...which leads me to another question.
    Matthias Mohr
    @m-mohr
    Yeah, STAC Browser likely can't visualize all the COGs yet, it assumes several things for normal EO imagery and it seems it can't really read your files. Would this PR help to visualize your data?
    radiantearth/stac-spec#879
    Marc Pfister
    @drwelby
    What's the current thinking about having collection summaries include more schema-like values for a property's value?
    Matthias Mohr
    @m-mohr
    @drwelby We want to avoid a new "JSON Schema" for STAC, so that it's getting overly complex. So by default we only give basic infos about the actual values, but if people want to add other properties to the Stats Object, they are free to do so. That was the thinking in STAC sprint 4 (we introduced and discussed it there)
    Having that said, I don't think many clients can make sense of the additional values and may either just spit them out or ignore them, so I guess in most cases it's only really useful for your internal "use cases". Why do you think a schema could be useful?
    Matthias Mohr
    @m-mohr
    And lastly, actual JSON Schema for values could be provided using the stac_extensions array. But that's only a vague idea I just had...
    Marc Pfister
    @drwelby
    ok, so Implementors are free to add other derived statistical values to the object can be interpreted loosely?
    Matthias Mohr
    @m-mohr
    Yes
    Marc Pfister
    @drwelby
    hmmm, stac_extensions could maybe work too, will need to try that out.
    Matthias Mohr
    @m-mohr
    The idea is to define your own "extension" (which can "extend" other extensions) and pass the URL of the schema. In the schema you can then define the values more specifically, but like in OOP inheritance, the values must be "more specific". So you can't allow null for a field that in the official schema can only be a string, because then the official schema would fail in validation.
    But that's defined then on the item level, not on the collection level...
    Marc Pfister
    @drwelby
    This is for hinting to clients so it should be at the collection level.
    Chris Holmes
    @cholmes
    I like the idea of providing the schema at the item level in STAC extensions. I do think you'd have all of the items reference the same schema. And if the collection consists of items that all contain that schema I don't see why you couldn't reference that schema at the collection level.
    Like it makes sense to me to have a collection level asset that is the JSON schema the items in it follow. We don't want to replicate JSON Schema in summaries. But I see no reason to not allow people to define a JSON Schema for the items in a collection.
    Marc Pfister
    @drwelby
    A schema as a collection asset would work too. Knowing where to find it is the next question, though maybe item.schema.json does the trick.
    Matthias Mohr
    @m-mohr
    Maybe we could even allow stac_extensions and stac_version in summaries. I mean it just makes sense to know which version, extensions etc a Collection consists of.
    Marc Pfister
    @drwelby
    The other hitch for me is that I would like to also summarize assets, so a client can know ahead of time about the assets that are stored by the collection's items.
    Chris Holmes
    @cholmes
    I think for that we have an extension https://github.com/radiantearth/stac-spec/tree/master/extensions/item-assets that could work
    Marc Pfister
    @drwelby
    Oh perfect! I feel like I saw that but then got it crossed up with the collection-assets.
    RobinF
    @rfergason
    @matthewhanson Hey. I would like to be added to the monthly STAC call invite. Is that call still open to anyone? Thanks!
    Matthew Hanson
    @matthewhanson
    Yes, it is! @rfergason , please just let me know your email address
    RobinF
    @rfergason
    Thanks @matthewhanson ! My email address is rfergason@usgs.gov.
    RobinF
    @rfergason
    Got in invite. Thank you!
    Chris Holmes
    @cholmes
    Hey, I'm just leaving now to drop the kid off at a new daycare. Probably won't be able to join a call for a half hour from now at the earliest. Feel free to meet without me, or push back a half hour (may still be a bit late). Sorry for late notice on this.
    Marc Pfister
    @drwelby
    @m-mohr what I'm trying to describe is also the output of a process, is there any overlap here with the openeo work?
    James Santucci
    @jisantuc
    is anyone free for a second review on radiantearth/stac-spec#875 ?
    Rob Emanuele
    @lossyrob
    done!
    James Santucci
    @jisantuc
    :+1: thanks!
    Matthias Mohr
    @m-mohr
    @drwelby Maybe, but likely not yet for Collections as we use them only for Input Data so far and Output is always an Item. But we have process descriptions in JSON Schema. Anyway, we should talk at some point (currently not at work until end of the week). Maybe at the data sprint? Are you participating?
    Marc Pfister
    @drwelby
    When is the data sprint? I'll try to make it.
    Tony Gill
    @gillt_gitlab

    Hi folks,

    I appreciate you are all busy with the current workshops. So there is no rush on my part for a response. Many months ago (it could have been a year ago, what a year!) I posted a question regarding using STAC to access offline images. In our case these are rasters that reside in a tape archive, and must be 'activated' (to borrow Planet terminology) before they're available for download.

    I am after some feedback on the following scheme for users to be able to order offline data. The vision we have is shown at the video on this page: https://medium.com/@mojodna/a-stac-browser-348a60674061. If we get this right, then:

    • a user will use a STAC browser to navigate a catalogue until they get to a StacItem
    • the browser renders the Assets for the StacItem as hyperlinks
    • the user can select an 'order' link to request the asset be activated
    • in response, the browser renders the StacItem again, but with some updated properties on the status of the order and a link that the user can select to check the progress
    • the user-browser interaction loops until the browser display's the StacItem's 'download' link, which the user selects to access the image.

    There is more detail about our scheme below for the interested reader. If you read it, then I'd be very grateful:

    • for people's thoughts on this scheme; example: is there a simpler approach? are we using the notion of an asset correctly?
    • to know if we need to propose a STAC extension (like an 'order' extension) to implement this scheme? Or does the existing STAC 1.0.0-beta support it

    Now to the detail. In our scheme, a StacItem has an 'order' asset, the URL to which is a request to our server to 'activate' the asset. The server responds with a 202 (processing) and a StacItem in the body. The StacItem's properties has an order:status field with the status of the order ('offline', 'processing', or 'online'). The returned StacItem's assets has a URL so the status can be queried again.

    The following example workflow may make the scheme clearer. Below is a snippet of a StacItem returned from a search result. Note:

    • The 'order' asset; it contains a link to our order endpoint so the file can be ordered
    • The 'order:status' attribute in the properties; it is currently offline
    {
      "id": "cemsre_t54jvn_20161118_abam4.img",
      "assets": {
        "metadata": {
          "href": "https://data-access.jrsrp.org.au/productmetadata"
        }
        "order": {
          "href": "https://stac.jrsrp.org.au/order?filenames=cemsre_t54jvn_20161108_abam4.img&state=NSW"
        }
      },
      ...
    
      "properties": {
        "collection": "nsw-Sentinel2-reflectance_10m",
         ...
        "order:status": "offline"
      },
    }

    A request is placed to order the file using the order-asset link. The response is a 202 (processing) and the StacItem is returned. Note:

    • the order:status attribute in the returned StacItem has changed to 'processing'
    "id": "cemsre_t54jvn_20161118_abam4.img",
    "assets": {
        "metadata": {
          "href": "https://data-access.jrsrp.org.au/productmetadata"
        }
        "order": {
          "href": "https://stac.jrsrp.org.au/order?filenames=cemsre_t54jvn_20161108_abam4.img&state=NSW"
        }
    
      ...
    
      "properties": {
        "collection": "nsw-Sentinel2-reflectance_10m",
        ...
        "order:status": "processing",
      }

    The client may use the order-asset link again to query the order's progress. When the file becomes available for download, the response will be code 200 with the body containing the StacItem as follows. Note:

    • there is now a 'download' asset
    • and the order:status is 'online'
    ...
    ...
    "id": "cemsre_t54jvn_20161118_abam4.img",
    "assets": {    
        "metadata": {
          "href": "https://data-access.jrsrp.org.au/productmetadata"
        }
        "download": {
          "href": "http://qld.auscover.org.au/public/data/spatial_other/jrsrp/jrsrp-data-access/order_506/cemsre_t54jup_20180224_abam4.img"
        }
    
      ...
      ...
    
      "properties": {
        "collection": "nsw-Sentinel2-reflectance_10m",
        ...
        "order:status": "online",
      }
    Matthias Mohr
    @m-mohr
    @gillt_gitlab I'd suggest copying this into a GitHub issue so that all your good thoughts don't get lost and ate visible more permanently.
    ycespb
    @ycespb
    @drwelby @cholmes , Hi, about "A schema as a collection asset would work too" (sorry for my late reply). What about using the same approach as used in a OGC API - Features Core Collection, i.e. adding a link with rel="describedby", type="application/schema+json", and href referring to the actual JSON schema for the items in the collection ?
    Matthias Mohr
    @m-mohr
    @ycespb Good call. That is also a possibility, although STAC Items usually have multiple Schemas (1 Item + 1 for each extension). But I guess nothing prevents us to use multiple links? If that's standardized in OAFeat Collection, we should go that route, too and could likely also add it to the spec. Do you have a pointer to where this is specified in OAFeat? I found some references of describedBy, bot nothing in particular that mentions it can be used for item schemas. From the docs, I'd expect that describedBy + type in a Collection refers to a Collection Schema, not an Item schema.
    Marc Pfister
    @drwelby
    Any ideas on a good way to describe the asset naming convention in item-assets? While there's no href, it would be helpful to know that the a file is named '{{properties.id}}-pan.tif'
    Chris Holmes
    @cholmes
    @gillt_gitlab - lots of really great stuff here. I have thoughts on this for sure. And I know Planet and Maxar share a need for a similar 'order' workflow. But I'm slammed with organizing the sprint. If you could put it in a github issue at https://github.com/radiantearth/stac-spec/issues like @m-mohr suggests that'll ensure I come back to it and comment on it, and it'll save the conversation for other interested parties. But looks like a great start.
    @ycespb @m-mohr - Agreed, reusing the Features API relations would be good, if we can sort out the best way to do it.
    Matthias Mohr
    @m-mohr
    @drwelby There's nothing like that yet. The closest you can get is likely the tiled asset extension, which has URI templates for their stuff.
    Tony Gill
    @gillt_gitlab
    Thank you @m-mohr and @cholmes. I have created issue 891. https://github.com/radiantearth/stac-spec/issues/891#issue-690674989.