Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Jerome Gasperi
    @jjrom
    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
    Tips #3 - to browse the current stac catalog on the map screen, click on the layer button (center left on the map) then click on the information "i" button on the corresponding catalog layer
    Feedback appreciate !
    Matthias Mohr
    @m-mohr

    You can change the stac catalog url from homepage (it embeds the stacindex.org catalogs index)

    Hah, nice! How does that work? Do you scrape the frontend HTML code or do you request it directly from the API?

    Astrea EOD gives invalid catalog in Rocket. Do you know why that is? @jjrom
    Jerome Gasperi
    @jjrom
    @m-mohr I request directly from the API
    Jerome Gasperi
    @jjrom
    Ok found the issue for Astrea EOD - in https://stacindex.org/api/catalogs, look at the url for astrea catalog is prefixed with a space character. This broke my reader :) I just update the client so it handles that.
    @m-mohr The format of bbox is unclear from the specification. The astrea implementation waits for a comma separated delimiter string (i.e. lon1,lat1,lon2,lat2) while the Element84 implementation waits for an array i.e. ([lon1,lat1,lon2,lat2])
    From the specification it is unclear what is the right format...so i choose the one with brackets
    Jerome Gasperi
    @jjrom
    So requests from rocket to astrea catalog are invalids.
    We should clarify that in the API specification
    In the OGC API Features examples, the bbox without brackets is the right way. I will modify rocket accordingly. Does it make sense ?
    Matthias Mohr
    @m-mohr
    Do we have a STAC meeting in 5mins (or an hour and 5mins, depending on DST...)?
    James Banting
    @jbants
    Right now
    Matthias Mohr
    @m-mohr
    Okay, as usual I'm then missing the call in the week we have changed from summer to winter time... but anyway, nothing new from my side...
    Matthias Mohr
    @m-mohr
    @jjrom I guess I have to improve also on my side to remove spaces.
    I remember that we had discussions around the bbox issue. Not sure what the solution is/was. Maybe it's just an issue on GH?
    Chris Holmes
    @cholmes
    I don't see an issue, will add it. I think if WFS is without an array we should align to that.
    Matthew Hanson
    @matthewhanson
    We’ll be changing off of DST starting next Sunday @m-mohr , so should bring it back to the same time difference I think?
    Matthias Mohr
    @m-mohr
    Yes, next meeting is as usual :)
    Ben Cheng
    @Ben-Cheng
    Hi all. I am creating a tool to upload some historic aerial imageries with the STAC format. There are a lot of fields that are specific to historic imagery like film, film_sequence_number, whether the imagery is black & white or RGB, physical_film_condition, etc. There are also some specific to aerial imageries like altitude, nominal_focal_length, photocentre_latitude, photocentre_longitude, etc. What is the best way to put these data in the Properties Object?
    Chris Holmes
    @cholmes
    @Ben-Cheng - that's awesome! So the simplest thing you can do is just add those as custom fields, and ideally put them in a schema, with your own prefix. But given your description it'd be great if you wanted to put them into 2 extensions (aerial & historic imagery), that you could contribute as a STAC extension - https://github.com/radiantearth/stac-spec/tree/master/extensions
    This would enable others to align on the same field names. We have talked a few times about aerial, and that would be a great one to have, but no one has gotten to write it up (and none of the core STAC team knows aerial well enough to do it ourselves). And historic images would be great too.
    If you want to try to make pull requests and contribute directly to the spec that'd be awesome. But I'd love to see both of those, so if you just made a couple issues that wrote up all the fields and what they are used for I'd be happy to help draft the actual extensions.
    Blayne Chard
    @blacha

    @cholmes Thanks for the feedback!

    Quick piece of background, we are in the process of creating a backup archive of about 110TB of historical aerial imagery and we are looking to store STAC metadata with it.

    So I think for now we are looking to start using STAC internally until we can use it in anger for a bit to make sure it meets our needs then we could look at contributing it back as a STAC extension, Even if we have to go and remap all our fields we only have about 1M files so shouldn't take too long!

    We will clean up some of our internal docs on what fields we have and where we are planning on storing them.

    Another question: namespaces, Land Information New Zealand (LINZ) does a lot more than just historical imagery, we are thinking that our linz: namespace might get quite polluted do you have any thoughts about subname spaces

    Some possibilities we are thinking of linz_aerial: linz:aerial or even sub sub namespaces linz:imagery:aerial

    Chris Holmes
    @cholmes
    Sounds great on evolving it internally before contributing back to STAC. But would be great if you do a blog or something online about it, so that if others are getting into it you help align.
    I had not thought about sub names. But I think linz_aerial: or linz_imagery_aerial: would make the most sense to me - keep the ':' to separate the prefix from the main thing. Though prefixes are just a convention.
    You also could just use aerial: directly for the ones you think will have wider applicability. Then you wouldn't have to change them if it evolved to a STAC extension. You just have some risk if someone else contributes an extension with same prefix but different semantics (but can mitigate that risk by just paying attention to the community and reaching out to align when someone does).
    Chris Holmes
    @cholmes
    Just put a few PR's up on stac-api-spec - trying to make a push for 1.0.0-beta.1 on it. Reviews appreciated https://github.com/radiantearth/stac-api-spec/pulls
    Also would appreciate feedback on radiantearth/stac-api-spec#27 as it seems like we should get something in place to get api verisons
    Pasquale Di Donato
    @p1d1d1_twitter
    Hi all, have a quick question.
    I’d like to use “created” and “updated” at collection level. Is that allowed? Where is the right place to put them? If I set them under “summaries” the collection is not valid according to the stac_validator
    Ah... collection. "This fields - together with created and updated - also seem relevant for STAC Collections and may be adopted there, too" so item only right now
    Pasquale Di Donato
    @p1d1d1_twitter
    That is an Item, isn’t it?
    Yeah, so you can add them, but don't add "timestamps" to "stac_extensions" and the validator won't complain and it won't check them
    Pasquale Di Donato
    @p1d1d1_twitter
    The question is that I don’t know at which level to put them. If I put under “summaries” I get a validation error.
    I’m on v0.9.0 and don’t use the time stamp extension
    Kurt Schwehr
    @schwehr
    Have you tried adding those to properties?
    Pasquale Di Donato
    @p1d1d1_twitter
    There is no “properties” field in the collection fields
    Kurt Schwehr
    @schwehr
    I think you can just add them to the top level for collections and they will be ignored
    Pasquale Di Donato
    @p1d1d1_twitter
    This actually my current implementation, but not sure if it’s the right way. I get no error, so I assume the validation just skips them as you said
    Matthias Mohr
    @m-mohr

    Have you tried adding those to properties?

    @p1d1d1_twitter You get an error because summaries are always arrays or object with min/max. Just put them in those containers and it validates

    so:
    "summaries": {
      "created": ["2020-01-01T00:00:00Z"]
    }
    Matthias Mohr
    @m-mohr
    But if you have items underneath the Collections that would describe what is actually in the item, not the collection itself.
    I guess you should just put updated and created top-level. That's then your custom extension, but there's no other way in STAC yet.
    Chris Holmes
    @cholmes
    @p1d1d1_twitter - is the updated / created at a collection level a reflection of the created/updated of the items below? If yes then summaries is definitely where it'd make sense. But if you want to communicate about when the collection itself was created / updated independent of the items in it then it could be a top level custom extension like @m-mohr says.
    Pasquale Di Donato
    @p1d1d1_twitter
    @cholmes I’d like to communicate about the when of the collection itself. What exactly do you mean with custom extension? Should I then define this attributes in a schema and do I need to prefix them?
    Chris Holmes
    @cholmes
    @p1d1d1_twitter - sounds good. Maybe 'custom extension' is not quite the right word. A new extension, since this one seems pretty generally applicable. I'm inclined to say that prefix isn't needed, since we have clear definitions in Items for those fields.
    Actually, it looks like https://github.com/radiantearth/stac-spec/tree/master/extensions/timestamps would be a logical place. So you could just make a PR there that explains applyin created/updated to the collection level.
    Matthias Mohr
    @m-mohr
    Yeah, I think we should just allow the timestamps to be added top-level.