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!
What's the process to move to next maturity levels?
Should we be seeing the Proposal status as high risk for production use?
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.
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.
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
@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.
@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
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.
Here's two examples of the provided S1 footprints (blue) and what is calculated from this code (red), a simple one and a more complex one
It's a balancing act, because in STAC we don't really want a large complex polygon. On the other hand, you don't want to have data regions falling outside your footprint because users won't get those when querying. And if the footprint includes nodata regions than a user might query and extract data from a region that turns out to not have any data.
Thanks @lossyrob and @matthewhanson for the advice that seems to be a sensible choice. Most probably I'll really go the route via rasterization -> vectorization -> simplification on my datasets as well.
So for the balancing act, I see that it is neither desireable to make the boundaries too large (users get too many unusable results) nor to make them too small (users get too few results). And generally having as few points as possible is good. If I do simplification, I'll either have to define some tolerance in terms of distance or I need to define a maximum amount of points which may be returned or both. Are there any established good number for that? I could imagine rules like (but maybe there are more options):
- max N points per polygon
- accurarcy of the geometry should be at least 1% of the size of the asset
- accuracy of the geometry should be at least x-times the resolution of the sensor
Each of those may have their problems and maybe there are no good general advice. But as a good choice not only depends on the dataset creators capabilities but also on the user of the dataset, I've the feeling that a general guideline could be helpful.
@d70-t I don’t think there’s any good general advice right now, in the snippet I used the Shapely simplification which specified tolerance in terms of min distance in native native units…so in this case it’s lat/lon degrees. A guideline of tolerance based on resolution would be very helpful, if you have any good advice after doing creating some footprints please report back. I think it would be good info to put into STAC best practices since there is an impact on API pperformance based on geometry size as well as on utility of the dataset (the more inaccurate the AOI the less useful intersection queries are).
It’s a good point about query inaccuracies based on unexact footprints. Is there a way to ensure the shapely simplification covers the original polygon, so that the (simplified polygon) union (original polygon) == (simplified polygon)? That way you can ensure only false positives, but avoid the false negative case, where the true footprint does cover a query area but is not returned in a query
I don’t know of a turnkey method to do that, but you could compare the geometry output with the original data mask, and then would need to tweak the geometry.
Although I think this does depend on use case requirements. Sometimes you might want to minimize false positives so you don’t get completely nodata regions, but on others you might want to minimize false negatives because you don’t want to miss out on any data.
Although I think this does depend on use case requirements. Sometimes you might want to minimize false positives so you don’t get completely nodata regions, but on others you might want to minimize false negatives because you don’t want to miss out on any data.
but if you union the simplified with the footprint, shouldn’t it just make some adjustments in the cut off areas so that there’s no cutoffs?
Red is the original footprint, Blue is calculated
.but it depends on the inaccuracies of the original footprint….maybe your original footprint is underrpresenting the area.
@schwehr hmm, I don’t think I have the scene IDs anymore, just the gifs.
In hindsight that would have been useful to use to name the gif
In hindsight that would have been useful to use to name the gif
Any anyone attend prior years?
Hi all! Let me introduce myself. It is Javier Márquez. I work at Geomni, a business unit of Verisk Analytics Inc. as software engineering lead, mainly in the area of online GIS products. The company has been working in the area of spatial information and standards for many years. Our variety of data, both raster and vector, is really noticeable. Now we're analysing latest specs, mainly the new OGC API and, of course, the STAC recommendations for searching and discovery. We really think that this could help us a lot to improve the interoperability of all stakeholders involved in our market. As immediate action items, we're just knowing deeply all the work done by STAC, current challenges and considering ways to collaborate in the future. All help and guidance in all of this would be truly appreciated.
It should be aligned with stac 1.0.0-rc2
You can change the stac catalog url from homepage (it embeds the stacindex.org catalogs index)
Or programmatically from url e.g. https://rocket.snapplanet.io/home?u=https:%2F%2Fearth-search.aws.element84.com%2Fv0
Tips #1 - a long click on the map performs a reverse location and display the country/state/region
Tips #2 - you can drag&drop KML/geojson/shapefile or STAC url directly on the map to add new layers / change the STAC catalog endpoint