Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Bernard Wright
    @space_bernard_twitter
    We're not associating it with an image yet. Its geojson'd field outlines, crop type and yield. Its a training dataset for others to link to relevant imagery.
    @cholmes @jisantuc
    Matthias Mohr
    @m-mohr
    @jbants @jonhealy1 I saw that you released STAC Validator 1.0.0 - Could you update https://github.com/m-mohr/stac-node-validator/blob/master/COMPARISON.md for the sprint, please? :-)
    Matthias Mohr
    @m-mohr
    Anyone has any insight on how to work with STAC and CARD4L? Their website says they are working on something, but no specifics.
    pieschker
    @pieschker
    @m-mohr I'm assuming CARD4L is supportive but not implementing anything yet.
    Matthew Hanson
    @matthewhanson
    We recently have done a CARD4L self assessment for the Sentinel-2 COG work, which is going into review now.
    Now that we’ve done that, I’d like to do an extension for it, if anyone else is interested, shooting to have something I can present on at ARD 20 for it.
    ycespb
    @ycespb
    Hi, I have a question related to staclint.com. When we validate our landing/root page (a STAC Catalog 1.0.0-beta2), it complains that "'extent' is a required property of []". Is my understanding not correct that the Landing Page (i.e. a STAC catalog) is not necessarily a STAC Collection and therefore may not have extent and providers which are properties of a STAC Collection, but not properties of a STAC Catalog ? I also checked the UML representation (draw.io / PDF) which seems to confirm that "extent" and "providers" are only properties of STAC Collections and not of STAC Catalogs. All Collections are Catalogs, but not all Catalogs are Collections in my understanding... Maybe staclint.com is only meant to validate STAC Collections and not STAC Catalogs ? Does somebody has experience with this tool ?
    Chris Holmes
    @cholmes
    @jbants can probably help. I agree that starting with a catalog should not require an extent.
    Tim Martin
    @TimJMartin
    Hi - new member here. I work at Ordnance Survey (GB's National Mapping Agency) and have started investigating us potentially using COGs and STACs for our raster and imagery data. We have about a dozen different products that are currently in different formats (TIF+World Files, GeoTiffs), they all have different refresh cycles, we have archives going back to 2001, and some are Open Data and some are Premium paid datasets. Having read some of the STAC spec and looked at a few examples I have a few questions on how best to store the data in S3 and a few other questions. Where would be best to ask those questions, here or over on the Github issue page? Many thanks Tim
    Matthias Mohr
    @m-mohr
    Welcome @TimJMartin! If it's going to be very long, it might be better to use GH issues, but otherwise I think you can just ask here.
    Tim Martin
    @TimJMartin
    @m-mohr ok cool. I will post a question on GH as it might help other beginners
    Alex Leith
    @alexgleith
    Hey @m-mohr please let me know if I can put you in touch with CARD4L people :-)
    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 ?