Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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
    Phil Varner
    @philvarner
    I can't find Sean H's handle, so could someone point me to whichever project it is that's implementing OGC API Part 3 CQL?
    Kurt Schwehr
    @schwehr
    Another not very exciting pr... radiantearth/stac-browser#51
    John Tasker
    @JohnBTasker

    @cholmes @m-mohr During development of the Collection Spec, was there ever consideration of a Collection also being consumable as a GeoJSON (e.g. having geometry, feature and properties fields)?

    I'm working through a scenario at the moment with a number of stand-alone collections that would greatly benefit from having their footprint/extent represented in a simple and consumable manner. The data is mainly linear captures with film / digital aerial photography, where a bounding box is a very poor representation of project extent. In a large number of instances we also don't have any mosaic assets that show the project's full extent. While we've tried to represent the data in the summaries object under proj:geometry, this resulting file is certainly not as usable to rapidly query or visualise as a GeoJSON.

    While I can't find any mention in the STAC spec and OGC API - Features spec, I notice that in PySTAC there is support for a Properties object in the collections class. Is this from earlier iterations of the spec, or for collection level properties to be represented?

    As always, your support and insights are greatly appreciated. I know our use cases can be a bit left of field sometimes.

    Sean Harkins
    @sharkinsspatial
    @philvarner The parser implementation for OGC Features API is pycql https://github.com/geopython/pycql
    1 reply
    @bitner worked on an initial SQL Alchemy compiler during the sprint here https://github.com/bitner/pycql/tree/sqlalchemy-integration
    Kurt Schwehr
    @schwehr
    @JohnBTasker I was wishing the same
    Matthias Mohr
    @m-mohr

    @JohnBTasker Yes, but we had the desire to align with OGC API - Features and they don't use GeoJSON for Collections.
    If you use data and collections in a sentence, there's likely something wrong. I think what you want to do is an Item, not a standalone collection. The addition of the collection assets was not meant to replace single items, but to allow to link to assets that are common across all items. Also, your standalone collections would not be searchable via STAC API /search. So I'd recommend to make an item, with (optional, but I'd recommend it) a corresponding collection.

    Properties in Collections is indeed from an earlier iteration of STAC. That will likely go away in implementations in the future. Collection level properties go in summaries (for standalone collections) or top-level, if the extension supports it.

    Chris Holmes
    @cholmes
    @JohnBTasker - we love left field use cases, especially right now, to make the spec more flexible. But I agree with Matthias - I think you'd be best served by using Items. You can have a set of relations between the items if you want to represents sets of assets separately. I'd be happy to look more at the data and try to recommend how to model it.
    John Tasker
    @JohnBTasker

    @cholmes The general data model that we have established has four object types:

    • Frame (STAC Item) => Atomic organisation of the data, includes metadata for position, time, and relationship Run, Film & Project
    • Run (STAC Collection) => Collection of frames sharing common metadata (captured same day, sensor, film), can have a LineString geometry (flightline) + Polygon geometry (footprint)
    • Project (STAC Collection) => Collection of runs sharing common metadata (e.g. provider, purpose), can have Polgyon/MultiPolygon geometry (footprint) [typical preference for search/discovery]
    • Film (STAC Collection) => Collection of frames and runs based on source physical medium; basis of data storage structure

    Only frames are directly related to data files, the remaining objects are semantic groupings of common search/discovery attributes. The main interest for proposing improved geometry details in collections is that more often than not for aerial datasets you will initially search for a project rather than individual data items, particularly over large areas. Once you've narrowed down the project(s), finding the specific data item / format is then the focus. A good example of this type of logic is the LINZ Data Service (https://data.linz.govt.nz/) where data is organised based on projects, with individual tiles subsequently downloadable.

    Kurt Schwehr
    @schwehr
    [can of worms...] Working on pystac got me thinking about how to model something like a journal paper itself. e.g. one of my own for context. http://vislab-ccom.unh.edu/~schwehr/papers/schwehr2007.pdf especially something like Figure 18 with a seismic line, multibeam bathymetry, and a core with magnetic data from samples. Each figure should be an entity and then it would be great if it could link to all the datasets that went into making the figure. I know journals are doing this for figure location behind paywalls. A couple of us started trying to do this with EndNote and Google Earth back in 2008. http://vislab-ccom.unh.edu/~schwehr/papers/gebco-200805.png.
    Chris Holmes
    @cholmes
    @JohnBTasker - sorry for the slow response. I definitely see why a real geometry would be good for the 'project' level. You got me thinking more about OGC API and GeoJSON. What you really want is 'collection search' - the ability to query your collections. STAC has not delved into this, and I believe it's the proper sphere of 'OGC CSW', which is working towards a version as part of OGC API, called 'records': https://github.com/opengeospatial/ogcapi-records
    Unfortunately that link doesn't really make things clear. But I'm hoping it evolves, you can see a bit more of my take on what it should be at opengeospatial/ogcapi-records#36
    Chris Holmes
    @cholmes
    You've got me thinking a bit more about it. And I think at core there needs to be an 'OGC Collection', which has all the fields that are useful for searching collections. And I think there should be the existing representation of it (with the spatial extents), and a GeoJSON representation. The latter would be the core unit of an OGC Records API - it be an OGC Features API (just like STAC), but returns records (geojson representations of a content model that corresponds to the Collection fields).
    Chris Holmes
    @cholmes
    With that lens I do think it could make sense to allow geometry fields in a Collection. They'd just be geojson compliant geometry fields within the Collection json, but it wouldn't be a geojson feature (like an item is), and thus would likely be difficult to index. And then the 'geojson version' would be available in rel=alternate type=application/geo+json link.
    Chris Holmes
    @cholmes
    So I know that's not a great answer, since those other pieces aren't built out yet. But it'd be great if you wanted to experiment with them, and then we can point at real world examples on standardizing. My hope is the record/collection stuff happens in OGC, and I can help push it along.
    Chris Holmes
    @cholmes
    Based on your description I would consider modeling 'Run's as Items. Like have the project be the collection for both runs and frames, and then use rel links to describe the relations between the two. But don't feel like you have to, the spec is designed to be flexible - I just like modeling things in items more.
    Kurt Schwehr
    @schwehr
    STAC could use an entry on wikipedia... https://en.wikipedia.org/wiki/STAC
    Matthias Mohr
    @m-mohr
    Couldn't we just allow the projection extension for Collections?
    +1 on Wikipedia ;)
    Jeremy Palmer
    @palmerj
    HI All. Why are all of the extensions have a maturity status of Proposal? https://github.com/radiantearth/stac-spec/blob/master/extensions/README.md#list-of-content-extensions I assume many must be stable or at least candidate now. Thanks!
    Matthias Mohr
    @m-mohr
    Hi, we had no time/chance yet to review the implementations and update the maturity levels. Also, several extensions recently had changes, which reverts them to "Proposal".
    Jeremy Palmer
    @palmerj
    Ok thanks
    What's the process to move to next maturity levels?
    Should we be seeing the Proposal status as high risk for production use?
    Tobias Kölling
    @d70-t
    Hi, I am very new to STAC, but I am planning to try it for a couple of datasets from a recent field campaign which mostly comprises landbased, airborne and shipborne data. I am currently working on data from an airborne imager and am wondering if there is a good best practice on how fine the geometry of a STAC Item should be resolved as due to small turbulences the sensor is constantly shaking and thus the footprint has a wobbly shape. Using only the bounding box would likely cover way too much of an area, but providing all the fine details would probably be far too much of nonsensical metadata.
    Jeremy Palmer
    @palmerj

    Should we be seeing the Proposal status as high risk for production use?

    Any advice?

    Matthias Mohr
    @m-mohr
    What is a high risk for you? The proposal stage means that things may change, which is equally true for the whole STAC spec as it's still in beta. We need to update the maturity levels once we reach rc, for sure. More info on the process: https://github.com/radiantearth/stac-spec/tree/master/extensions#extension-maturity
    For that, it would be very helpful to submit all implementations to the STAC dataset list (the spreadsheet from the last sprint) and/or stacindex.org so we have an overview regarding the extensions that have been implemented.
    James Santucci
    @jisantuc
    i'll also add that extensions were probably centralized too soon. if you have something useful for you to build with one of the extensions as it currently is, you should use the extension. if the extension doesn't meet your needs, you should feel free to vendor one with what you're building -- we're doing that with the layer extension in stac4s currently (https://github.com/azavea/stac4s/tree/master/docs) and as we explore it / show uses we'll pr it back to the main STAC spec repo eventually
    Rob Emanuele
    @lossyrob
    @d70-t in the past, when I’ve been creating STAC items for drone imagery with complicated footprints, I took a simplification of the true footprints. This was to balance having a good representation of where data was but not having too complicated and large of a polygon to store in the item JSON.
    Matthew Hanson
    @matthewhanson
    @d70-t Same as @lossyrob when I’ve generated footprints myself I simplify them. If you find it helpful, here’s a code snippet that generates a footprint by generating a nodata mask (of 0s and 1s), using rasterio to get the vectorized shapes from that, then simplifying that. This has worked pretty well with Sentinel-1 boundaries, since the included S1 boundaries can be off quite a bit, but I’ve not tested this beyond a handful of scenes.
    The scale parameter was me trying out generating the nodata mask from overviews instead of the full data file, as I thought it would speed it up (a scale factor of 2 effectively would be using the half size overview if there was one), but I found the results to not be great.