Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Tran Minh Tri
    @minhtritran_gitlab
    @m-mohr I will try, thanks.
    Tran Minh Tri
    @minhtritran_gitlab
    @m-mohr When I execute the command npm install, I have the following error
    image.png
    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
    image.png
    Matthias Mohr
    @m-mohr
    @minhtritran_gitlab Is that a clean install? Maybe try to remove node_modules and package-lock.json and try to npm install again. If that doesn't work I have no clue. It worked fine for me.
    Tran Minh Tri
    @minhtritran_gitlab
    @m-mohr Thanks
    Tran Minh Tri
    @minhtritran_gitlab
    @m-mohr Thanks for your advice, the installation is OK now
    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?
    image.png
    Matthias Mohr
    @m-mohr

    Interesting, works for me, but open package.json and replace:

        "clean": "find dist -delete",

    with:

        "clean": "",

    This will disable cleaning the dist folder. Not sure what implications this has, but should work in most cases.

    And then run npm start -- --open again
    Tran Minh Tri
    @minhtritran_gitlab
    @m-mohr It works now. Thanks a lot for your help.
    Simon Ilyushchenko
    @simonff
    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?
    Matthias Mohr
    @m-mohr
    @simonff I don't know any software that really parses the field names for extension prefixes. So I think you should be fine with using eo: sar: etc, but you could also just continue using gee: as before. In the end, it is internal anyway, right?
    Matthias Mohr
    @m-mohr
    @matthewhanson We do the call today, right?
    Matthias Mohr
    @m-mohr
    I opened multiple new PRs today that need reviews: https://github.com/radiantearth/stac-spec/pulls
    Matthew Hanson
    @matthewhanson
    @m-mohr yes, we’ll do call today
    Matthew Hanson
    @matthewhanson
    Matthew Hanson
    @matthewhanson
    @m-mohr made update: radiantearth/stac-spec#670
    Alexander Frank
    @afrank150
    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?
    ycespb
    @ycespb
    Should be rel=items according to ogc api features core to refer to multiple items with a single /items URL according to me.
    Alexander Frank
    @afrank150
    Thanks for pointing that out @ycespb ! That will work well for the Dynamic catalog. For the static catalog we may just need to tell our users to follow that path and perform a list operation.
    Matthias Mohr
    @m-mohr
    I guess we can discuss that in todays working session... There's indeed adescrepancy between static and dynamic.
    ycespb
    @ycespb
    @m-mohr , @afrank150 I assume rel="items" also makes sense for static catalog. It should point to a GeoJSON FeatureCollection type of file while rel="item" points to a GeoJSON Feature type of file. Both can be static.
    Alexander Frank
    @afrank150
    @ycespb for that to work that FeatureCollection would need to be its own file in the static catalog, like a manifest.
    ycespb
    @ycespb
    @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 ?
    Matthew Hanson
    @matthewhanson
    Hey @philvarner, if you have a chance could you update this PR? radiantearth/stac-spec#655
    Matthew Hanson
    @matthewhanson
    @philvarner - also, if you want to update the Projection extension...update with latest dev and also bring back the removal of eo:epsg from the EO extension. Would be great to get this is for 0.9.0
    Alexander Frank
    @afrank150
    @ycespb yes, that is what I was thinking for consistency across dynamic and static catalogs. That items file could get massive though, and supporting that is probably less tenable for us than linking to every item in the collection json
    Matthias Mohr
    @m-mohr
    We didn't had the chance to talk through it during the call, but I guess opening an issue in the GH repo would make sense.
    @afrank150
    Alexander Frank
    @afrank150
    Ok will do @m-mohr
    Alexander Frank
    @afrank150
    Phil Varner
    @philvarner
    @matthewhanson i'll update both of them
    Ag Stephens
    @agstephens
    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
    Chris Holmes
    @cholmes
    @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.
    Matthew Hanson
    @matthewhanson
    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.
    Phil Varner
    @philvarner
    Phil Varner
    @philvarner
    with projection, i named the fields to start with "asset_crs", to make it clear that its referring to the crs that the asset data is in (in general, though you can have assets that are not in that crs)
    Matthias Mohr
    @m-mohr
    @philvarner Did you take my last comment in #655 into account?
    Phil Varner
    @philvarner
    let me check
    Phil Varner
    @philvarner
    just pushed changes that update those uses of role to roles
    Matthias Mohr
    @m-mohr
    Great, approved and merged.
    Chris Holmes
    @cholmes
    @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.
    Ag Stephens
    @agstephens
    @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.