The js file tsserver.js doesn't exist on my system. Do you have that problem when installing the stac browser?
@m-mohr I have a look further up and see the following
To run it, I have updated the package.json as your instruction and run npm start -- --open. I got the followng error message. Did you encounter that before?
And then run
npm start -- --open again
question: if we (Earth Engine) in our internal representation of our datasets add extra fields to existing extensions (eo:, sar:, etc), will this break parsers or some conventions? Would you prefer us to, eg, put extra band fields like scale and offset into a completely separate extension? If not, how should we name them? eo:ee:scale?
Hey everyone - questions on collection relationship types. We have collections with a very large number of items and new items are being added continually so we don’t want to use the item rel to provide a link to every item in that collection. What we decided to do instead was use the child rel to provide an API link to /collections/{collectionId}/items so that users could page through all available items. There is a Landsat example in the collection spec examples that does this too. According to the spec though the child rel should only contain a collection or catalog link. So is populating the child rel with …/items a misuse of that rel? Also, one consideration is that the …/items link would probably not work with a Static catalog. Are there other ideas on providing a listing of items belonging to a collection without actually linking to each item in the collection JSON?
@afrank150 I suppose you mean just a .json file with a root object of type "FeatureCollection" which includes/embeds below "features" 0 or more Feature objects, thus the same format/content as an OGC API - Features (search) response document presumably without search metadata and paging links ?
@afrank150
Hi folks, I'm coming to STAC from a view of wanting to catalog environmental data in general. One key use case is CMIP data (Coupled Model Intercomparison Project(s)). These are climate simulations where the data is essentially a multi-dimensional hypercube. Are there any existing STAC catalog examples that I could learn from? Thanks
@agstephens welcome! We don't yet have any great examples that I know of, and have known that it's a challenge for STAC, but one we think is possible. @m-mohr has done the data cube extensions which is potentially useful. And I think @matthewhanson has been working with the pangeo community, which works with at least similar type of data.
Are we going to try to meet this week? Do a working session to settle on release? I could do tuesday (ideal) or wednesday/thursday.
Hi @agstephens , at a Pangeo meeting last August we started discussing what an ESM STAC extension would look like, but never finalized anything. Since then, a couple folks created a STAC-like spec for ESM, but is not STAC: https://github.com/NCAR/esm-collection-spec
My hope is that we can turn that spec into an extension. I’d be happy to talk more about it.
@cholmes Yes, Tuesday sounds good to me, I’ll send out an invite again for it.
My hope is that we can turn that spec into an extension. I’d be happy to talk more about it.
@cholmes Yes, Tuesday sounds good to me, I’ll send out an invite again for it.
Projection extension updated https://github.com/radiantearth/stac-spec/pull/485/files
@matthewhanson - I had a flight delay and then got a nasty migraine today, so I'm quite behind on prep work I need to do for a meeting I need to do tomorrow. So may not be able to make the working session in a meaningful way. But depending how much I'm able to do tomorrow early morning I may be able to stop by for ab it.
@matthewhanson and @cholmes, thanks for your responses. I will keep tracking progress regarding the idea of an ESM STAC extension. It would be very interesting for us managers of EO and ESM data sets - ideally we want a unified solution. Thanks for the link to the NCAR approach.