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
    @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.
    ycespb
    @ycespb
    @m-mohr : the pointer should be Recommendation 9 Point D - /rec/core/fc-md-descriptions in the spec at http://docs.opengeospatial.org/is/17-069r3/17-069r3.html. Point D mentions JSON schemas as example structural definitions to be included in this way.
    Bernard Wright
    @space_bernard_twitter
    Hi folks, Bernard from Geo Gecko here. Can someone help me figure out how does STAC apply to ground collected data which will later be used for imagery machine learning? Is there standards that we should be adhering to? Appreciate it
    ycespb
    @ycespb
    @m-mohr Example 4 in the same document 17-069r3 uses this approach (describedby) with a GML application schema which applies to all items in the collection.
    Chris Holmes
    @cholmes
    Welcome @space_bernard_twitter! The most closely related STAC stuff is the label extension: https://github.com/radiantearth/stac-spec/tree/master/extensions/label
    But I'm not sure it exactly fits, as it sounds like you're not yet associating it with an image? The label extension I believe needs to have an image and the label that applies to it.
    Actually it looks like only the geojson is required, see https://github.com/radiantearth/stac-spec/tree/master/extensions/label#assets @jisantuc @notthatbreezy probably have more insight than I do if ground collected data without an image is in scope.
    James Santucci
    @jisantuc
    "links to any source imagery" sounds like not having a source is Fine :tm:, though it sounds a little odd -- what do you mean "ground collected"? do you mean there is no corresponding imagery for some reason? @space_bernard_twitter
    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".