QQ RE
sortby in place of sort stac-api extension: Do we expect this naming change to be stable? I do see sortby in some OGC docs, which I assume was the reason for the change, but I wanted to confirm that no further adjustments are expected for the extension name. (I apologize to the folks on Monday's call when I asked the same question).
:wave: i'm taking a stab at converting the label extension into usable Scala code. i have a question about some missing required fields where i'm not sure if fields aren't required as an oversight or if some strange objects are technically valid, specifically with label overviews objects. name property key and without the other fields?
label:overviews is an optional list of Label Overview objects. Label Overview objects have three optional fields. does this mean that [{}, {}, {}] is a valid label:overviews property? relatedly, what purpose could someone have in providing a Label Overview object without a property key, or with a 
@matthewhanson Question regarding common names in EO: https://github.com/radiantearth/stac-spec/tree/master/extensions/eo#common-band-names
There are ranges that cover two common names (e.g. 0.6 is both green and red). So which to use? I guess the second value is exclusive?
There are ranges that cover two common names (e.g. 0.6 is both green and red). So which to use? I guess the second value is exclusive?
yellow sort of cross between those two
I just put up an attempt at 0.9.0 version of Planet data - at https://storage.googleapis.com/pdd-stac/disasters-0.9.0/catalog.json Would be great if clients could check it out. Or if you want me to try your client to test let me know.
Will change it over to be the main one once stac browser supports 0.9.0, so I don't break planet.stac.cloud
@cholmes Some comments:
- In the items (example https://storage.googleapis.com/pdd-stac/disasters-0.9.0/hurricane-harvey/0831/Houston-East-20170831-103f-100d-0f4f-RGB.json) the stac_extensions field is not correct. It lists eo, sat and proj, but the item uses eo, view, proj and a proprietary one (link to schema if available).
- Adding roles for the mosaic would be helpful, I guess.
- You don't use eo:bands although required by the extension.
- stac_extensions in the collection ( https://storage.googleapis.com/pdd-stac/disasters-0.9.0/catalog.json ) is also wrong: It lists view, eo and proj, but uses only "version"
- I'm personally missing "summaries" ;-)
- stac_extensions - thanks for the catch. Was updating too many files at once by hand (some day I'll figure out pystac or something). We're actually get traction at Planet to implement a real STAC API and define an official Planet mapping, so I'll push for a schema at that point. But things are going to shift from mine.
- roles for mosaic - you mean at the asset level? I think I need to update for 'roles' for all of them, not just the mosaic. Or you mean provider role?
- On the stac_extensions - I wasn't sure if that was supposed to be the extensions that are used in the items in the collection, or just the extensions used directly in the collection file. I'll fix it (and will try to check we make that clear, but I just looked at one example and didn't fully read the spec).
- roles for mosaic: Yes, asset level, e.g. roles = data
- From reading the documentation the stac_extensions thing should be clear, it's pretty long actually. Of course, you won't understand it just from examples...
- summaries: Great! :-) Again, best is to read the docs and check the examples there. Just from examples you can't make good summaries IMHO. ;-) Here's our catalog, although it's generated automatically from Googles STAC 0.6.2 catalog and thus may not be the best example: https://earthengine.openeo.org/v1.0/collections Google is working on an updated version and other openEO implementers also still need to catch up in the next weeks.
(Need to do it for Planet data, and seems like a nice one to generalize)
If we can't meet earlier then I can try to join for the first 15 minutes or so...
@matthewhanson - if that does work could you move the invite up a bit?
Sorry for the attempted last minute switch - shelter at home with a 1.5 year old has been a challenge.
Ok, I'm on zoom: https://planet.zoom.us/j/8171436529 Meeting ID: 817 143 6529 If anyone wants to join and catch up.
James and Josh are on.
joining zoom
Can I get some feedback on this preliminary catalog
https://geobase-spot-staging.s3.amazonaws.com/catalog.json
https://geobase-spot-staging.s3.amazonaws.com/catalog.json
Also, version is not a core field, so better add "version" to stac_extensions.
Hey @matthewhanson - asked Frank about Planet using shape + gdal affine transform like in the grid extension, and he said that plus epsg code would work for us and be a general solution. I should check with ESRI to be 100% sure it works for them too, as they were the advocates for our offset_x and offset_y.
Now that I understand what the extension is actually for I feel like it could perhaps use tweaks in name / explanation. Based on the PR alone I had no idea it solved the same use case as Planet's offset / rows/cols fields. Should make it clear that it enables virtual catalogs / data cubes to fully populate without having to open the files.
Hi all: I hope everyone is keeping safe/well during this time. A bit of a pygeoapi / STAC update (since our November 2019 sprint in DC). I’m implementing STAC for realtime weather/numerical weather prediction data (i.e. GRIB2 data), and have a MVP.
During implementation, I ran into #198 again. Are there any guidances on how to name the object ids? Having a difficult time coming up with something meaningful
I’m of the general opinion that a Collection should have similar Asset keys across all Items in that Collection.
This allows users to look at a Collection and see which Asset keys they are interested in then use that Key when getting individual items.
So, if your items all have a primary data file for instance call it the same thing across all items.
This allows users to look at a Collection and see which Asset keys they are interested in then use that Key when getting individual items.
So, if your items all have a primary data file for instance call it the same thing across all items.