Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Matthew Hanson
    @matthewhanson
    @tomauer Just caught up on the twitter thread. I think eo:bands is not thing to use here, to define each band being a week.
    The STAC Item will contain the begin and end time for the year though, is specifying the datetime range for each band in the file needed? Or is a user going to already know that going in?
    I guess what I’m asking is what advantage is gained by embedding the datetimes for the weeks within the Asset metadata?
    Tom Auer
    @tomauer
    I'm not entirely sure...especially from a STAC perspective, I just thought it might be useful for users to know they're getting a 52 band cube up front, which isn't described elsewhere.
    And be able to programmatically provide the specific dates somewhere...although they are stored cryptically in the tif too
    Rob Emanuele
    @lossyrob
    Would this info be better supplied via the data cube extension?
    Tom Auer
    @tomauer
    yes, that looks helpful
    Tom Auer
    @tomauer
    Thoughts on this?
    "properties": {
        "datetime": null,
        "collection": "ebirdst",
        "cube:dimensions": {
          "time": {
            "type": "temporal",
            "description": "Each band represent a distinct week centered on the date decsribed in the values here.",
            "extent": ["2018-01-04T00:00:00Z", "2018-12-28T00:00:00Z"],
            "values": ["2018-01-04T12:00:00Z", "2018-01-11T12:00:00Z", "2018-01-18T12:00:00Z", "2018-01-25T12:00:00Z", "2018-02-01T12:00:00Z", "2018-02-08T12:00:00Z", "2018-02-15T12:00:00Z", "2018-02-22T12:00:00Z", "2018-03-01T12:00:00Z", "2018-03-08T12:00:00Z", "2018-03-15T12:00:00Z", "2018-03-22T12:00:00Z", "2018-03-29T12:00:00Z", "2018-04-05T12:00:00Z", "2018-04-12T12:00:00Z", "2018-04-19T12:00:00Z", "2018-04-26T12:00:00Z", "2018-05-03T12:00:00Z", "2018-05-10T12:00:00Z", "2018-05-17T12:00:00Z", "2018-05-24T12:00:00Z", "2018-05-31T12:00:00Z", "2018-06-07T12:00:00Z", "2018-06-14T12:00:00Z", "2018-06-21T12:00:00Z", "2018-06-28T12:00:00Z", "2018-07-06T12:00:00Z", "2018-07-13T12:00:00Z", "2018-07-20T12:00:00Z", "2018-07-27T12:00:00Z", "2018-08-03T12:00:00Z", "2018-08-10T12:00:00Z", "2018-08-17T12:00:00Z", "2018-08-24T12:00:00Z", "2018-08-31T12:00:00Z", "2018-09-07T12:00:00Z", "2018-09-14T12:00:00Z", "2018-09-21T12:00:00Z", "2018-09-28T12:00:00Z", "2018-10-05T12:00:00Z", "2018-10-12T12:00:00Z", "2018-10-19T12:00:00Z", "2018-10-26T12:00:00Z", "2018-11-02T12:00:00Z", "2018-11-09T12:00:00Z", "2018-11-16T12:00:00Z", "2018-11-23T12:00:00Z", "2018-11-30T12:00:00Z", "2018-12-07T12:00:00Z", "2018-12-14T12:00:00Z", "2018-12-21T12:00:00Z", "2018-12-28T12:00:00Z"],
            "step": "P7DT9H13M51S"
          }
        }
      }
    Matthias Mohr
    @m-mohr
    Oh yes, that makes more sense. You could omit extent, it's clear from the values. Are there more dimensions to specify?
    It likely has spatial dimensions, right?
    Matthew Hanson
    @matthewhanson
    @m-mohr How can you link the cube:dimensions to assets? I know you had originally developed this extension for collections only
    Matthias Mohr
    @m-mohr
    Like eo:bands. Datacube is defined for Collections and Items. We allowed all item properties in assets, right?
    Matthew Hanson
    @matthewhanson
    ah ok, so use ‘cube:dimensions` in the data asset
    Matthias Mohr
    @m-mohr
    Yes
    Matthias Mohr
    @m-mohr
    We should work on making the schemas aware of that, too
    Tom Auer
    @tomauer
    Updated with other dimensions and moved to asset data property.
    "assets":{
          "data":{
             "href":"results/tif/bbwduc-ERD2018-EBIRD_SCIENCE-20191105-dc3957b5_hr_2018_abundance_median.tif",
             "title":"Black-bellied Whistling-Duck 2018 Relative Abundance Data Cube",
             "type":"image/tiff; application=geotiff; profile=cloud-optimized",
             "cube:dimensions":{
                "x":{
                   "type":"spatial",
                   "axis":"x",
                   "extent":[
                      -11295569.3520532,
                      -4149279.68684902
                   ],
                   "reference_system":6842
                },
                "y":{
                   "type":"spatial",
                   "axis":"y",
                   "extent":[
                      -4098378.87654,
                      5181138.84866212
                   ],
                   "reference_system":6842
                },
                "time":{
                   "type":"temporal",
                   "description":"Each band represent a distinct week centered on the date decsribed in the values here.",
                   "values":[
                      "2018-01-04T12:00:00Z",
                      "2018-01-11T12:00:00Z",
                      "2018-01-18T12:00:00Z",
                      "2018-01-25T12:00:00Z",
                      "2018-02-01T12:00:00Z",
                      "2018-02-08T12:00:00Z",
                      "2018-02-15T12:00:00Z",
                      "2018-02-22T12:00:00Z",
                      "2018-03-01T12:00:00Z",
                      "2018-03-08T12:00:00Z",
                      "2018-03-15T12:00:00Z",
                      "2018-03-22T12:00:00Z",
                      "2018-03-29T12:00:00Z",
                      "2018-04-05T12:00:00Z",
                      "2018-04-12T12:00:00Z",
                      "2018-04-19T12:00:00Z",
                      "2018-04-26T12:00:00Z",
                      "2018-05-03T12:00:00Z",
                      "2018-05-10T12:00:00Z",
                      "2018-05-17T12:00:00Z",
                      "2018-05-24T12:00:00Z",
                      "2018-05-31T12:00:00Z",
                      "2018-06-07T12:00:00Z",
                      "2018-06-14T12:00:00Z",
                      "2018-06-21T12:00:00Z",
                      "2018-06-28T12:00:00Z",
                      "2018-07-06T12:00:00Z",
                      "2018-07-13T12:00:00Z",
                      "2018-07-20T12:00:00Z",
                      "2018-07-27T12:00:00Z",
                      "2018-08-03T12:00:00Z",
                      "2018-08-10T12:00:00Z",
                      "2018-08-17T12:00:00Z",
                      "2018-08-24T12:00:00Z",
                      "2018-08-31T12:00:00Z",
                      "2018-09-07T12:00:00Z",
                      "2018-09-14T12:00:00Z",
                      "2018-09-21T12:00:00Z",
                      "2018-09-28T12:00:00Z",
                      "2018-10-05T12:00:00Z",
                      "2018-10-12T12:00:00Z",
                      "2018-10-19T12:00:00Z",
                      "2018-10-26T12:00:00Z",
                      "2018-11-02T12:00:00Z",
                      "2018-11-09T12:00:00Z",
                      "2018-11-16T12:00:00Z",
                      "2018-11-23T12:00:00Z",
                      "2018-11-30T12:00:00Z",
                      "2018-12-07T12:00:00Z",
                      "2018-12-14T12:00:00Z",
                      "2018-12-21T12:00:00Z",
                      "2018-12-28T12:00:00Z"
                   ],
                   "step":"P7DT9H13M51S"
                },
                "relative_abundance":{
                   "type":"spatial",
                   "axis":"z",
                   "extent":[
                      0.000141068841912784,
                      1004.65972900391
                   ],
                   "unit":"birds"
                }
             }
          }
       }
    Matthias Mohr
    @m-mohr
    @tomauer That looks very good. "0.000141068841912784 birds" sounds funny on first sight ;-)
    Tom Auer
    @tomauer
    Great, thanks for your help. Dumping them all on AWS now.
    Tom Auer
    @tomauer
    And yes, bird number is a little funny. I wish there was a more concise unit definition of "relative abundance"
    Matthias Mohr
    @m-mohr
    STAC Index now offers a free STAC Browser for every API/Static Catalog submitted! Still very experimental and shows errors for several catalogs, but it's a start :-) Here's CBERS for example: http://stac-index.lutana.de/#/browse/Z8ImEcYd9zZyVMFF cc @lossyrob
    Matthias Mohr
    @m-mohr
    Issue for most catalogs are missing CORS headers, it seems.
    Matthias Mohr
    @m-mohr
    Should we add a best practice that static catalogs and APIs should be deployed with CORS enabled? @matthewhanson @lossyrob
    It seems that at least half of the catalogs currently available in STAC Index doesn't send CORS headers and thus I can't use it with STAC browser or any browser-based tooling.
    Chris Holmes
    @cholmes
    Oh yes. A really bolded one, at the top, etc. I can't complete I forgot that.
    1 reply
    Matthias Mohr
    @m-mohr
    Matthias Mohr
    @m-mohr
    @lossyrob I have a couple of PRs waiting for you in the STAC Browser repo :-)
    Rob Emanuele
    @lossyrob
    :+1: :tada:
    Matthias Mohr
    @m-mohr
    @lossyrob And by the way, with some hacking it was possible to embed STAC browser into another Vue App. Nothing a normal user would do though, so separate components would still be nice at some point.
    Rob Emanuele
    @lossyrob
    nice, glad that worked for you
    agree about the components being the target
    Tom Auer
    @tomauer
    @m-mohr Thanks for help with the STAC browser. I'm fixing the path issue with the tifs.
    What were the other validation issues? I'm seeing a warning sign next to the URLs.
    3 replies
    I just saw the mouse-over on the warning sign
    Tom Auer
    @tomauer
    Is there a way to force the STAC browser to re-read the catalog files? I'm updating them and fixed a path issue, but the tiles are still trying to pull from the old, broken path.
    Tom Auer
    @tomauer
    Seems to have eventually done it...which leads me to another question.
    Matthias Mohr
    @m-mohr
    Yeah, STAC Browser likely can't visualize all the COGs yet, it assumes several things for normal EO imagery and it seems it can't really read your files. Would this PR help to visualize your data?
    radiantearth/stac-spec#879
    Marc Pfister
    @drwelby
    What's the current thinking about having collection summaries include more schema-like values for a property's value?
    Matthias Mohr
    @m-mohr
    @drwelby We want to avoid a new "JSON Schema" for STAC, so that it's getting overly complex. So by default we only give basic infos about the actual values, but if people want to add other properties to the Stats Object, they are free to do so. That was the thinking in STAC sprint 4 (we introduced and discussed it there)
    Having that said, I don't think many clients can make sense of the additional values and may either just spit them out or ignore them, so I guess in most cases it's only really useful for your internal "use cases". Why do you think a schema could be useful?
    Matthias Mohr
    @m-mohr
    And lastly, actual JSON Schema for values could be provided using the stac_extensions array. But that's only a vague idea I just had...
    Marc Pfister
    @drwelby
    ok, so Implementors are free to add other derived statistical values to the object can be interpreted loosely?
    Matthias Mohr
    @m-mohr
    Yes
    Marc Pfister
    @drwelby
    hmmm, stac_extensions could maybe work too, will need to try that out.
    Matthias Mohr
    @m-mohr
    The idea is to define your own "extension" (which can "extend" other extensions) and pass the URL of the schema. In the schema you can then define the values more specifically, but like in OOP inheritance, the values must be "more specific". So you can't allow null for a field that in the official schema can only be a string, because then the official schema would fail in validation.
    But that's defined then on the item level, not on the collection level...
    Marc Pfister
    @drwelby
    This is for hinting to clients so it should be at the collection level.
    Chris Holmes
    @cholmes
    I like the idea of providing the schema at the item level in STAC extensions. I do think you'd have all of the items reference the same schema. And if the collection consists of items that all contain that schema I don't see why you couldn't reference that schema at the collection level.
    Like it makes sense to me to have a collection level asset that is the JSON schema the items in it follow. We don't want to replicate JSON Schema in summaries. But I see no reason to not allow people to define a JSON Schema for the items in a collection.
    Marc Pfister
    @drwelby
    A schema as a collection asset would work too. Knowing where to find it is the next question, though maybe item.schema.json does the trick.
    Matthias Mohr
    @m-mohr
    Maybe we could even allow stac_extensions and stac_version in summaries. I mean it just makes sense to know which version, extensions etc a Collection consists of.