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
    @alexgleith Thanks, I'll get back to you soon :-)
    ycespb
    @ycespb
    Hey @lossyrob , does the STAC-BROWSER use/display the assets with role "overview" and "thumbnail" if both are present in an item or is only the "thumbnail" displayed ? In many cases, our thumbnails are 100px only, and we have in many cases quicklooks a bit larger than 600px (e;g. 700x400px)... Better to use the quicklooks and include them as "thumbnail" assets ? Any recommendation ?
    Rob Emanuele
    @lossyrob
    Only the “thumbnail” asset is displayed (on the thumbnail tab for the item). Is the overview also a png/jpeg that can be displayed in that tab? The browser could be tweaked to look for an “overview” role first and fall back to the “thumbnail” asset, if this is a common use case
    Rob Emanuele
    @lossyrob
    I’m not sure ‘overview’ is a common role (folks can correct me if I’m wrong). So maybe it’d be better to allow overridding of the thumbail asset key (defaulting to thumbnail) via an environment variable so that you can modify it on startup
    ycespb
    @ycespb
    @rob, the terminology used since OGC 10-157r4 for these two is THUMBNAIL and
    QUICKLOOK. (see https://docs.opengeospatial.org/is/10-157r4/10-157r4.html#28). Maybe these terms could be adopted as common "roles" in the spec ? Being able to overwrite the "thumbnail" asset key on startup would be OK as well... Would be nice if they would appear nicely in stacindex.org as well and not only in our instance of STAC-BROWSER...
    Phil Varner
    @philvarner
    is the quicklook the same dimensions as the original, or is it just some size between the thumbnail and the original?
    Matthew Hanson
    @matthewhanson
    I’ve been creating overviews to be the same resolution as the original data, but byte-scaled and turned to COG (because with a lot of scientific data it just doesn’t make sense to turn every band into a COG with internal overviews that won’t be used), so the “overview” serves that purpose.
    It sounds like quicklooks are more like large thumbnails, and I’d say the role would still be “thumbnail” for them
    It wouldn’t be a bad idea to come up with recommendations for thumbnail sizes though
    Phil Varner
    @philvarner
    yeah, agree with recommendations being a bad idea. I was wanting to know if the quicklook had to be the same size.
    from a practical use perspective, we has 3 sizes in our UI -- a 340px "thumbnail" that gets browser-resized to 180ish, an "overview" that
    is 1200px, and "full-res" that's the same dimensions as the original
    so thumbnail is "small", overview is "size of a laptop screen"
    I'm not lobbying for any specific names, just discussion what we found the most useful in practice
    Phil Varner
    @philvarner
    Are eo:bands definitions still allowed in Item Properties? The schema still allows them there, but it no longer allows them to be referenced by array index from the Asset. The spec text is "eo:bands: In previous versions eo:bands was allowed to be used on the asset-level referencing via array indices to the actual bands in Item properties. Starting with STAC 1.0.0-beta.1 you are now allowed to place the full eo:bands array with all Band Object information in Item assets as described in general in the STAC Item."
    "allowed" makes me think either way is valid, but the schema doesn't seem to allow either way
    Matthew Hanson
    @matthewhanson
    You can put them in Item properties, but they are not matched to any asset that way, as there’s no way to reference them. So it’s far more useful to put them in assets.
    You might put them in Item properties in order to include them in ‘summaries’ for the collection, or perhaps if you didn’t have initial assets and they were created by some other process or via ordering
    Phil Varner
    @philvarner
    "here are some bands that might exist for this Item on some Assets"
    Matthew Hanson
    @matthewhanson
    Yes
    Phil Varner
    @philvarner
    perfect. I'll update the spec to make that clear.
    thanks!
    ycespb
    @ycespb
    @philvarner , no, there is no requirement for a quicklook to have the same dimensions as the original. Its larger than thumbnail.
    Kurt Schwehr
    @schwehr
    @philvarner As another datapoint for what it's worth, in Earth Engine, we have historically had "thumb" be 64x64 and "sample" be 256x256. I'm not sure where we use the 64x64 images. Here is a current typical use of sample... https://developers.google.com/earth-engine/datasets/tags/goes-17
    ycespb
    @ycespb
    Hi, a quick question on v1.0.0 of the spec. In the past, there was a property "eo:platform" that was used inside a STAC collection (and STAC browser still displays this even when we indicate a 1.0.0 beta stac version). This no longer exists in the spec (EO extension), but there is a common_property called "platform". Should we use this in the collection directly under the root $ or should be put this below a $.properties ? None of the (2) collection examples in the spec/repo seem to do this (but use now summaries instead to include platform info). Same applies to "eo:instrument" now "instruments".
    Matthias Mohr
    @m-mohr
    @ycespb instruments has replaced eo:instrument in Items. You can also use it in Collections summaries. There's no other place where you could really use it (except for asset related things or you define your own extension).
    ycespb
    @ycespb
    @m-mohr , thanks. we will move it there then (do you know if STAC-BROWSER will still display it or does it still assume the old location ?). In the summaries, is the "platform" property then also an array in the same way as "instruments" ? In the "common_properties", "platform" is a single item and "instruments" an array.
    Matthias Mohr
    @m-mohr
    STAC Browser is pretty outdated regarding how and where things are displayed. I hope we get summaries support soon radiantearth/stac-browser#45
    Instruments is still a one-level array in collections - there's more details in the spec, see the detail description of the summaries at https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md#collection-fields
    A summary for a field can be specified in two ways:
    1. A set of all distinct values in an array: The set of values must contain at least one element and it is strongly recommended to list all values. If the field summarizes an array (e.g. instruments), the field's array elements of each Item must be merged to a single array with unique elements.
    ycespb
    @ycespb
    Thanks. Understood. For us it is important that platform and instrument info do show up in the STAC Browser (stacindex.org)...
    Matthias Mohr
    @m-mohr
    Long-term they will be, it's one of my highest priorities to get the summaries into STAC Browser, but short-term you may also contribute a PR.
    ycespb
    @ycespb
    Another question about the landing page (root catalog). If the /search resource is advertised via rel="search", which (media) "type" should be used to identify this as a STAC search endpoint ? We intend to add also a rel="search" link which will refer to an OSDD document which has its own type="application/opensearchdescription+xml", so would like to differentiate between the endpoints using the "type" property . https://stacspec.org/STAC-api.html shows the landing page response, and uses rel="search", type="application/json". Should it not be type="application/geo+json" instead as the href ="/search" will return a GeoJSON Feature Collection anyway ? Is the expected value for "type" somewhere mentioned in the specification (I only found it in the https://stacspec.org/STAC-api.html where it shows in the example response for "GET /") ?
    Phil Varner
    @philvarner

    @ycespb Astraea EOD uses application/json, but I noticed yesterday that @geospatial-jeff had an api that used "application/geo+json".

    It is currently not specified what the type should be, and I feel it should. Right now, it only says

    "If the /search endpoint is implemented, it is required to add a link with the rel type set to search to the links array in / that refers to the search endpoint in the href property."

    I'll create a PR to add to that:

    "It is recommended that the type for this link is application/geo+json (preferred) or application/json."

    3 replies
    Neeraj Rajasekar
    @neerubhai
    Hello everyone, I'm Neeraj, a new member here! I work at Esri and I'm passionate about building raster analysis tools and spatial data pipelines. Excited about exploring the world of COG/ STAC/ Cloud Native Geospatial and learning a lot from this community!
    I missed the CNG Outreach sessions but catching up on talks from YouTube. Thanks to all the speakers for putting together such great/ informative material!
    Rob Emanuele
    @lossyrob
    Hey Neeraj! Glad you're here. If you find anything while exploring, like questions about where things are at or thoughts on ways cloud native geospatial can fit into your workflow, let us know!
    1 reply
    Woody Wallace
    @woodywallace
    Re the conversation about overviews. Have catalog level overview assets been considered? For instance we have a use case where we have a catalog of 18" imagery tiled at doqq level, converted to cogs. Some counties have data, some don't. We'd like to provide a state level overview. So one way would be to create an mosaic for the whole folder (from the overviews in the COGS) and then reference it as an asset in the catalog stac. Or, can only items have assets?
    ycespb
    @ycespb
    @woodywallace would be the same as "collection-level" assets for which there is a dedicated extension at https://github.com/radiantearth/stac-spec/tree/master/extensions/collection-assets ?
    Chris Holmes
    @cholmes
    @woodywallace - Funny, I was thinking about this type of use case the other day. Like @ycespb points out - the collection assets extension would be appropriate for it. We recently added it, and it could migrate to core if it sees good uptake.
    ycespb
    @ycespb
    @cholmes I would support having collection level assets in the core. and not needing an extension for this.
    Chris Holmes
    @cholmes
    Yeah, me too. But we should take it through the process - survey who implements it and if many people do then we'll add it in core.
    Matthew Hanson
    @matthewhanson
    Welcome @neerubhai !
    Adam Sauer
    @EarthAdam_gitlab
    @lossyrob I'm getting weird coordinates (-8841012.439576626, 4450469.534876103) for my COG following one of the pystac tutorials (https://github.com/stac-utils/pystac/blob/ce3e80a669c42640ed7a50758b2abcf5b96ae5d6/docs/tutorials/how-to-create-stac-catalogs.ipynb). Is this normal?
    5 replies
    Adam Sauer
    @EarthAdam_gitlab
    @mojodna in setting up a STAC Browser I got it to build with a catalog I made, although nothing shows up in the dist/index.html. I tried prerendering it as well, although I just get errors saying dist is not empty and a few other things that I tried troubleshooting to no avail. Any idea what I'm doing wrong?
    9 replies
    Adam Sauer
    @EarthAdam_gitlab
    image.png
    Scott Simmons
    @ogcscotts
    anyone interested in attending the "OGC Community standards and STAC” session at the OGC Member Meeting today can register for the GoToWebinar here: https://register.gotowebinar.com/register/8799235835509581581
    Joe
    @turingtestfail
    Anyone implementing/planning a STAC crawler using AWS Glue? https://lijjumathew.com/aws-glue-with-an-example/
    Matthias Mohr
    @m-mohr
    It sounds like I should use it for STAC Index...
    Phil Varner
    @philvarner
    Matthias Mohr
    @m-mohr
    @philvarner There's no custom logic, it's the STAC Browser that decides it. @lossyrob
    Could it be the content media type? image/tiff vs. image/tiff; application=geotiff; profile=cloud-optimized?