Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Chris Holmes
    @cholmes
    Right now the spec itself is pretty mature, so if you're looking to contribute more broadly to the STAC ecosystem you can see https://github.com/stac-utils/stac-ecosystem for ideas, or work on one of the projects implementing STAC.
    lainiewright
    @lainiewright
    10 replies
    Fabian Schindler
    @constantinius
    Is this the channel where the Python stactools and its extensions are discussed? If so, I'd like to draw attention to this PR to add Level-1C support for the sentinel2 extension.
    2 replies
    Fabian Schindler
    @constantinius
    sachin kn
    @sachinlionel
    which database is recommended for stac-api?
    1 reply
    Phil Varner
    @philvarner
    There's an alternate proposal out for CQL JSON, and the OGC API team is seeking feedback opengeospatial/ogcapi-features#601
    Phil Varner
    @philvarner
    Had hoped to get STAC API beta.4 out this week, but I've been blocked on getting approval for the Filter Extension updates radiantearth/stac-api-spec#202 and Collections conformance class radiantearth/stac-api-spec#210 -- please review this if you have time!
    Marc Pfister
    @drwelby
    Any work yet on storing information about classified rasters in STAC? Primarily representing maps of values to class names.
    3 replies
    Matthew Hanson
    @matthewhanson
    Published pystac-client 0.3.0-beta.1, updated docs: https://pystac-client.readthedocs.io/en/latest/
    Yves Moisan
    @ymoisan
    In my inbox this morning : The just approved OGC API - EDR (Environmental Data Retrieval) "is not just for accessing ‘environmental’ data but can also support more general spatio-temporal data." Sounds like a STAC API to me.
    1 reply
    Daniel Silk
    @dwsilk
    Hi all - we've got a question about how to summarise Item and Item Asset created/updated datetimes at the Collection level. It's in Discussions on the STAC Spec repo: https://github.com/radiantearth/stac-spec/discussions/1156 (would it be better to just ask here instead?)
    Emmanuel Mathot
    @emmanuelmathot
    Hello, I have opened a discussion about branching model for stac repos: stac-extensions/stac-extensions.github.io#29
    1 reply
    goriliukasbuxton
    @goriliukasbuxton
    on the Element84 L1C catalog 'https://earth-search.aws.element84.com/v0/collections/sentinel-s2-l1c' gives errors
    4 replies

    `
    stac_items = satsearch.Search(
    URL,
    resolution=10.0,
    intersects=dict(type="Point", coordinates=[lon, lat]),
    collections=["sentinel-s2-l1c"],
    datetime="2020-04-01/2020-05-01"
    ).items()

    stack = stackstac.stack(stac_items)
    print(stack)
    `
    ValueError: Cannot automatically compute the resolution, since asset 'overview' on item 0 'S2B_13SDV_20200401_0_L1C' doesn't provide enough metadata to determine its native resolution.
    We'd need at least one of (in order of preference):

    • The proj:transform and proj:epsg fields set on the asset, or on the item
    • The proj:shape and one of proj:bbox or bbox fields set on the asset, or on the item

    Please specify the resolution= argument to set the output resolution manually. (Remember that resolution must be in the units of your CRS (http://epsg.io/32613)---not necessarily meters.

    Matthew Hanson
    @matthewhanson
    Hey everyone! I’m giving a talk on the State of STAC Thursday at FOSS4G: https://callforpapers.2021.foss4g.org/foss4g2021/talk/DNKY3E/
    I’d like to highlight as many active STAC projects as possible, but could use some help. If you have a publicly available STAC project/library/catalog and want me to include a slide on it, you can help by giving me a couple bullets and either an animated gif (preferable) or a screenshot
    Chris Holmes
    @cholmes
    Great talk @matthewhanson! And thanks to everyone who replied about their usage on twitter, super awesome to see all the use of STAC.
    Matthew Hanson
    @matthewhanson
    Great last minute presentation by @cholmes as well, he joined me and presented on the STAC ecosystem portion...and we put together a bunch of last minute slides, there was a lot to go through:
    https://docs.google.com/presentation/d/1H35EAUSeZzHwQxTkiuBVRU6MPpF05pUPmYj52e2Y_6k/edit?usp=sharing
    6 replies
    Daniel Rasmussen
    @daRasmussen
    Hello/ @all
    Marc Pfister
    @drwelby
    Anyone have examples of roles use for data mask assets in production? Would "roles": ["data-mask", "cloud", "cloud-shadow"] be the right idea?
    Chris Holmes
    @cholmes
    @drwelby - yeah, that seems right. Ours is still in progress, so happy to align with you. See https://www.planet.com/data/stac/open-skysat-data/20201211_223832_ssc4_u0001/20201211_223832_ssc4_u0001.json for early example.
    analytic_sr_udm2:ortho_analytic_udm2: {
    href: "https://storage.googleapis.com/open-cogs/planet-stac/20201211_223832_ssc4_u0001/20201211_223832_ssc4_u0001_udm2.tif",
    type: "image/tiff; application=geotiff; profile=cloud-optimized",
    roles: [
    "metadata",
    "snow-ice",
    "cloud",
    "cloud-shadow"
    ]
    2 replies
    I actually probably should put 'data-mask' in there too. It's for our UDM2 - https://developers.planet.com/docs/data/udm-2/ But I forgot that UDM2 includes UDM1, which has more the traditional data mask type things in it.
    Chris Holmes
    @cholmes
    The metadata is also probably up for debate and would be good to get consensus on. I feel like I saw some early example that did it that way, and it makes some sense to me that any file that is more 'about' the data, even if it's about each pixel, deserves a 'metadata' field. But I could see the opposite argument, reserving 'metadata' for that text file that describes it. Though in a stac-first system you wouldn't necessarily have a separate .MTL type file.
    Matthias Mohr
    @m-mohr
    The CARD4L extensions follows exactly the same path, also having "metadata" included:
    https://github.com/stac-extensions/card4l
    1 reply
    Scott Ellis
    @gsf-sellis
    The item spec says that STAC ids are only unique within a collection. But the best practices page says "...existing providers can easily use their same ID when they translate their data into STAC - they just need to be sure it is globally unique, so may need a prefix." Do STAC ids need to be globally unique or only within a collection?
    2 replies
    Phil Varner
    @philvarner
    STAC API 1.0.0-beta.4 release process is starting! Looking for a PR review for the merge radiantearth/stac-api-spec#216
    2 replies
    Chris Holmes
    @cholmes
    @m-mohr @matthewhanson @lossyrob ^
    Robin Wilson
    @robintw
    image.png

    Hi, I'm wondering if someone can help with some issues I'm having with the function to load a stac into a ODC using stac_load. I'm trying to follow the notebook that Matthew Hanson (@matthewhanson) presented at FOSS4G last week (https://github.com/Element84/geo-notebooks/blob/main/notebooks/odc-planetary-computer.ipynb), but with my own data.

    In answer to one of my questions after the talk, Matthew said that one of the benefits of stac_load over stackstac is that it will mosaic together images with the same timestamp but different spatial extents. My data is a set of SRTM images, that I want to be mosaiced into one large xarray.

    I've queried my STAC items, and saved the output to QGIS and it shows lots of items, making up a grid of data (see image - which appeared earlier than this message, sorry)

    However, when I load the items using stac_load and plot the data array, only the first image has been loaded:
    image.png
    Does anyone have any idea what's going on? The resulting xarray is the correct size, which suggests that it's loading the metadata properly - but it doesn't seem to have actually loaded the images correctly.
    (Apologies if this isn't the right place to post this - but I thought as it came directly from the STAC talk last week, then this might be a good place to ask)
    2 replies
    Phil Varner
    @philvarner
    Chris Holmes
    @cholmes
    congrats! Great work Phil!
    Asger Skovbo Petersen
    @AsgerPetersen

    Hi everyone,

    The Danish Agency for Data Supply has a large open data collection of oblique aerial images (think Microsoft BirdsEye) with complete interior/exterior orientations. It is approx 5 mio images with complete country coverage for three different years. Currently these images are served using a proprietary protocol backing this proprietary web client https://skraafoto.kortforsyningen.dk/oblivisionjsoff/index.aspx?project=Denmark&lon=10.2027929&lat=56.1277927.

    The vision is that we would like to serve data and metadata in a way that makes it possible to set up processing pipelines using these data for texturing 3D models, structure from motion etc. This should also make it possible to write a generic oblique aerial web client much like the one linked to above.

    We are currently researching how these images and their metadata could be served in a more accessible way. We have tried to learn as much as possible about STAC through github, blog posts, foss4g talks etc, but still have some questions and doubts. Would this be the right place to ask such questions?

    7 replies
    Asger Skovbo Petersen
    @AsgerPetersen
    This section https://github.com/radiantearth/stac-api-spec/tree/1615434c8ca47f399274d82726b13209f0bf50cf/ogcapi-features#endpoints states that "Implementing OAFeat enables a wider range of clients to access the API's STAC Item objects, as it is a more widely implemented protocol than STAC" but some of the most important attributes of an Item (like assets, collection etc) are NOT understood by the client (like QGIS) because they are not standard GeoJson properties. So, if we for instance would like to have an action in QGIS which opens the image or its thumbnail we can't use QGIS' native OAFeat client. Is there a smart way to make these attributes available to a generic OAFeat client?
    7 replies
    Asger Skovbo Petersen
    @AsgerPetersen
    image.png
    5 replies
    Asger Skovbo Petersen
    @AsgerPetersen
    image.png
    Sorry, I am a gitter newbie. The first image is an example Item. The second image is what QGIS exposes for that item when read through OAFeat.
    The OGR OAFeat driver behaves similarly.
    Asger Skovbo Petersen
    @AsgerPetersen
    @philvarner the spec section on "foreign members" https://datatracker.ietf.org/doc/html/rfc7946#section-6.1 draws attention to issues with reduced interoperability for implementations relying too heavily on foreign members. To me as a STAC newbie it feels a little like STAC API implements OAFeat in theory knowing that generic OAFeat clients are probably not going to be able to use it. I really wish that STAC API could leave a door open for returning "old fashioned" geojson when the OAFeat client does not know how to handle the extended STAC geojson. Otherwise as I understand it, we need two seperate but almost completely identical APIs if we want to have both a STAC API and a OAFeat API with broad client support.
    30 replies
    Robin Wilson
    @robintw
    Hi - I just wanted to say thank you to everyone involved in STAC. I've been persuading an organisation I work with to adopt STAC, and I've spent the last week doing a 'proof-of-concept' of the whole STAC ecosystem (STAC, COGs, XArray, Dask etc) using a load of open-source tools like stac-fastapi, stac-browser, stac-terminal, pystac, odc etc. Although I've had a few issues, overall the documentation and information about the tools has been wonderful, and a really nice ecosystem has developed around the tools. Thank you everyone!
    3 replies
    Marc Pfister
    @drwelby
    Hi all - I'm trying to get the Classification extension rolling. I've moved over the initial fields in file:values to https://github.com/stac-extensions/classification/tree/draft and have other questions and thoughts interspersed in italics. If you have data that already uses file:values or has classed values that could use this extension, please let me know. Comments are welcome and encouraged, and if there's something specific I've missed please make an issue so I have a space to discuss it.
    1 reply
    Phil Varner
    @philvarner
    I could use some reviews on these STAC API PRs -- they're blocking doing larger reorganization work https://github.com/radiantearth/stac-api-spec/pulls
    2 replies
    Grigory
    @pomadchin

    Hey all, we implemented Spark + STAC API support in terms of the RaterFrames library

    TLDR;

    • query the STAC API through the Spark API and represent retrieved STAC Items as a spark.DataFrame
    • Read Assets of the retrieved items as Rasters
    • Apply local / focal / etc operations to them

    Google colab to play with it in the browser!

    Jypyter Notebook (not colab, just a short version on github)

    Some pics to make this long post more attractive (I left only one since they are making this post not attractive):

    image

    2 replies
    Ralf Wohlfahrt
    @McSurf84
    Hey all,
    does anybody has experience with any kind of implementation for STAC with Go? I´m looking for something like PySTAC :-)
    Robin Wilson
    @robintw
    I'm having a really weird error when trying to list collections on a STAC API, when using pystac-client. I created an issue on the pystac-client repo, but I don't really know whether the issue belongs there or on the pystac repo - or even whether it is a problem with stac-fastapi (which I'm using to serve the STAC API). Any advice would be great - the issue is at stac-utils/pystac-client#113
    Matthias Mohr
    @m-mohr
    Please submit your learning resources (written tutorials, YouTube videos, etc.) to the new "Learning resources" section on STAC Index: https://stacindex.org/learn
    Robin Wilson
    @robintw
    What are the best-practices around storing and serving large images using STAC/COGs? For example, if I have a cloud-free composite covering a large country, should that be stored as one Item with one COG asset, or should it be split up into lots of smaller image tiles and stored as lots of items? I can see benefits to both approaches - either you're using the COG machinery to allow you to read only the bits of the image that you need, or you're using the STAC catalog/items to select just the bits of the image you need. Any thoughts?
    5 replies
    Emmanuel Mathot
    @emmanuelmathot
    Hello. Anyone deployed stac-fastapi on k8s or even better using helm charts? @lossyrob
    9 replies