Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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?
    Another thing might be to put the thumbnail in assets with the corresponding role instead of using links.
    Rob Emanuele
    @lossyrob
    Preview shows up if there are COG assets, specifically with any of these types
    const COG_TYPES = [
      "image/vnd.stac.geotiff; cloud-optimized=true",
      "image/x.geotiff", // generated by sat-api
      "image/tiff; application=geotiff; profile=cloud-optimized"
    ];
    Phil Varner
    @philvarner
    thanks @lossyrob and @m-mohr
    Phil Varner
    @philvarner
    I'm trying to figure out what license I should use for MODIS -- all of the documentation I've seen just has that it's vaguely "public", which by by the STAC common metadata description of license means that it would be "proprietary" -- any thoughts?
    Rob Emanuele
    @lossyrob
    based on the AWS open data language and other federal gov’t datasets, I’m assuming it’s public domain - perhaps using CC-PDDC would be appropriate
    Phil Varner
    @philvarner
    I interpret that to mean that I (or my company) are the Dedicator / Certifier, and that I'm associating the CC-PDDC license to the dataset (which is our "astraea-modis" bucket). Makes sense. Thanks Rob.
    John Tasker
    @JohnBTasker

    Slowly progressing with work to generate STAC files for our collection. In the process so far, two key questions have emerged from my team. We would greatly appreciate thoughts and opinions on the following:

    1. Standalone Collections - summaries attributes
      When creating standalone collections, what is the recommendation for representing footprint geometry (I'm assuming proj:geometry)? I notice that when validating in STACLint it recommends that values for each attribute in summaries should be surrounded by []. In the scenario of a standalone collection, should this applied to all attributes in summaries or only for the attributes where multiple values are present?

    2. MultiPolygon Support
      Is there any flexibility in the item spec / extensions for MultiPolygon (rather than Polygon) GeoJSON geometries? I'm currently generating STAC collections and items for orthorectified historic aerial photography data, and there are a limited number of instances where a project is split across two distinct polygons due to a missing flightline (or pilot error). All properties are identical, the data asset (e.g. mosaic) just has a gap in the middle.

    Matthias Mohr
    @m-mohr
    1. Summaries are always arrays or a Stats Object
    1. It's officialy not allowed, but I'd guess that most clients can handle it just fine as usually they just use GeoJSON libraries anyway... I'd just open an issue on GH and then see what others think about allowing more GeoJson types.
    Matthias Mohr
    @m-mohr
    Thanks Gitter for making my "2." a "1."
    Yves Moisan
    @ymoisan
    Hi folks. Are there plans for a (remote) STAC sprint this Fall ?
    Chris Holmes
    @cholmes
    @ymoisan - we just wrapped up a sprint last week actually. So likely not another one super soon. Though perhaps a very small one to push for STAC API 1.0.0-beta.
    Joe
    @turingtestfail
    I have just completed a first pass at a CQL-JSON parser module for GeoTools and submitted the PR. It converts CQL-JSON into GeoTools Filters (which can then be converted into SQL and other useful stuff). Looking for feedback and pointers, particularly examples of CQL-JSON functions. The code can be found here: https://github.com/turingtestfail/geotools/tree/cql-json-module-start/modules/unsupported/cql-json
    Kevin Booth
    @kbgg
    What’s the reason for the weird regex validation for the license field in collections? It fails validation when I have the license set to "CC BY-NC-ND 4.0"
    Rob Emanuele
    @lossyrob
    It fails because it’s not the actual SPDX identifier - those don’t have spaces, only dashes. So CC-BY-NC-ND-4.0 should pass.
    2 replies
    Matthew Hanson
    @matthewhanson
    Matthew Hanson
    @matthewhanson
    Next Monday 10:30AM doing an API working session for anyone who wants to join. Going to triage issues, work on PRs annd try and work toward doing a 1.0.0-beta.1 release of the api spec. Let me know if you want to joijn and will add you to invite.
    2 replies
    Matthias Mohr
    @m-mohr
    Oh yeah, missed that due to an overlapping openEO meeting. Will likely join the API working session.
    Kurt Schwehr
    @schwehr
    What spdx license should a US Government no copyright dataset be? e.g. GOES
    Phil Varner
    @philvarner
    I just had the same question about MODIS, and ended up using CC-PDDC
    Matthew Hanson
    @matthewhanson
    This is actually an ongoing discussion within NASA, and there hasn’t been a ton of clarification. It’s why in stac-cmr we give the license as “not-provided”. From what I recall the issue was that some folks didn’t like the general NASA license because it didn’t specifically call out EOSDIS data, so their solution has been to not provide a license.
    I’m going to push on this some more, I think it’s a serious problem.
    Kurt Schwehr
    @schwehr
    Thanks! I'm sure it will take a fair bit of effort to sort these all out. It's the land of exceptions and special cases