Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Jerome Gasperi
    @jjrom
    From the client point of view i need a way to distinguish between collection and catalog without having to resolve all links
    ycespb
    @ycespb
    @jjrom OK... Clear except the rel="child" which can be either ? Do you disambiguate by comparing the list of rel="child" with the list you got via rel="data" and everything else you consider "catalog" ?
    Jerome Gasperi
    @jjrom
    @ycespb Yes, i check all rel=child href and discard all that are already collections
    Jerome Gasperi
    @jjrom
    @ycespb I clearly miss a way to distinguish catalog and collection. Maybe an additional entry in link (like "subtype=collection") ?
    ycespb
    @ycespb
    @jjrom I'm in fact wondering why there are these two different concepts in the first place (OAFeat did not need two concepts). Why not have just a nested hierarchy of collections ? What makes something semantically a catalog versus a collection ? Isn't a "collection" by definition a "subcatalog" ? Is the issues that OAFeat expects a flat list of collections while STAC would like this to be a nested structure (also allowing different views on the same items - BTW: breaking the rule that an item can only belong to one "collection" ) ? isn't this the only difference ?
    Jerome Gasperi
    @jjrom
    @ycespb I have the same questions - i have the feeling that what makes a catalog or a collection is best practice and the unbreakable rule one item must belong to one and only one collection. As a consequence, the catalog notion is interesting because it can aggregate items from different collections. This is a use case for disaster charter for instance : a catalog could be "Earthquake in Haiti" which contains items from different satellites (i.e. different collections). To be more consistent everything should be a "collection" and what is called a "catalog" would be a view of a part of all items of all collections. This view would be based on a query - for instance "catalog of France" would aggregate all items from all collections that intersects France; "catalogs of Volcanoes" would be all items from all collections that contain a volcano; etc.. This is how the resto catalogs are generated as you can see in https://tamn.snapplanet.io/stac
    ycespb
    @ycespb
    @jjrom Considering the Catalog as a "view" (within or across collections) is also my interpretation.
    Chris Holmes
    @cholmes
    @elpaso - staccato by @joshfix supports transactions. Implementation at https://stac.boundlessgeo.io/ But it looks like it may not have them in the API document.
    Angelos Tzotsos
    @kalxas
    good morning
    Chris Holmes
    @cholmes
    @ycespb + @jjrom - I think you have it mostly right. A collection is a catalog, with additional metadata. And features belong to a catalog, that describes its metadata. Catalogs mostly just let you group as you'd like, in a lighterweight way.
    The place where they are very useful is in the 'browse' and 'crawl' contexts. People coming to your stac catalog and just clicking down to relevant interests. Or search engines spidering the whole catalog.
    It's much harder to navigate down when you hit an 'items' endpoint, that just lets you search or page through.
    But they're designed to be a flexible concept that can be used for a variety of groupings. They c an group at the top, before you go into collections. Or within a collection they can help you browse down.
    Right now the intersection between catalogs and OAFeat is confusing for sure though. I'm working on a proposal for a 'browse' endpoint that would try to provide clarity. Or it could be a better best practices document.
    ycespb
    @ycespb
    @cholmes - is it forbidden to have href with query parameters inside links with rel="child" (in a Catalog object) ? Is it planned to update the UML model to show where the rel="items" fits and whether both rel="item" and rel="items" both have different meanings ? In OAFeat only rel="items" exists. In the UML model only rel="item" appears.
    Chris Holmes
    @cholmes
    No, not forbidden to have href with query parameters inside the rel=child. Indeed I like the approach I think you're getting at - the items/ location has the canonical STAC Item, and the browse catalogs define their leaf nodes by just linking.
    The alternate approach I like is that the browse hierarchy is your canonical, and then in your items responses each one has a rel="canonical" pointing at the browse hierarchy.
    That is a good idea on updating the UML model. Will try to do it when I get to creating a proposal / best practices.
    Though actually, the UML model is really just the core STAC content model. items/ is actually an API thing.
    We did write up https://github.com/radiantearth/stac-spec/blob/master/item-spec/itemcollection-spec.md - to describe the content structure the api needs. But I do think that should go in the api
    (we decided yesterday for going to STAC 1.0 we are going to break out stac api into a separate repo and have different versioning, and likely a bit slower to 1.0)
    But yes, it all needs more clarity, and making sure the UML reflects it is a good point.
    ycespb
    @ycespb
    @cholmes and this "browse hierarchy" seems typically not to appear or is not expected to appear in the OpenAPI description as you do get very many different paths to items below /stac (I was looking at the landsat catalog example with the path/row hierarchy...)?
    Jerome Gasperi
    @jjrom
    @cholmes It would be very useful to determine at the /stac endpoint if a "rel=child" is a "regular" catalog or a "collection" catalog without having to resolve the link. Would you think an additional property in the link (like "subtype=collection" or whatever) be appropriate ?
    Chris Holmes
    @cholmes
    @ycespb - yeah, stac api implementors haven't taken the idea much, which is why I need to try to make it clearer. I think defining the core separately may help some.
    @jjrom that does seem useful. I can envision situations where it might be hard for someone to construct that ahead of time, so maybe start it as an optional thing. But seems sensible to make at least put in the spec a way to do that for implementors who want to.
    @jjrom - you want to make a PR on the spec? Can discuss it there. It's probably just a line or two in the catalog spec (or maybe the collection spec?)
    ycespb
    @ycespb
    @jjrom, why not using the existing "type" attribute with the JSON media type and appending "profile="..." with the profile URI something identifying a STAC Catalog object or SAT collection object ?
    Jerome Gasperi
    @jjrom
    @ycespb Yes that's a good idea !
    Chris Holmes
    @cholmes
    sounds reasonable
    Jerome Gasperi
    @jjrom
    @cholmes @ycespb I'm not familiar with mime-type profile - what do you suggest for the catalog/collection URI ?
    Janne Heikkilä
    @jampukka
    @aaime how are you going to advertise the queryables?
    check for a "queryables" link
    Janne Heikkilä
    @jampukka
    okay, I'll do it in the same way for now
    Andrea Aime
    @aaime
    It's not one of the solutions discussed here, but one that @rouault could implement against quickly and already use multiple servers for (the interactive instrument one and the geosolutions one)
    ycespb
    @ycespb
    @jjrom this is an example:
    {
    "rel": "service-desc",
    "href": "http://databio.spacebel.be/eo-catalog/description",
    "type": "application/json;profile=\"http://explain.z3950.org/dtd/2.0/\"",
    "title": "the Explain Document"
    },
    Even Rouault
    @rouault
    Does anyone know if a bbox parameter whose value resolves to a single point should be considered as a valid one ? Like bbox=2,49,2,49. The spec doesn't say anything about that
    Jerome Gasperi
    @jjrom
    It's a hell of a profile :) Can we use shortcuts like ";profile=stac-collection" ?
    Janne Heikkilä
    @jampukka
    is there an enum for the possible "type" values in a queryable
    Andrea Aime
    @aaime
    @jampukka I made one up based on the testbed 15 one, but think it's something up to discussion
    ycespb
    @ycespb
    @jjrom , The profile value should be an absolute URI (not a URL). I would expect something like https://radiantearth/stac/collection ? or https://...#collection.
    Andrea Aime
    @aaime
    @rouault checking the bbox thing
    Jerome Gasperi
    @jjrom
    @ycespb Ok that's sound much better - i prepare a PR
    Janne Heikkilä
    @jampukka
    @aaime in your OpenAPI document for queryable "name" is required but the actual property is "id"
    Alessandro Pasotti
    @elpaso
    About TRANSACTIONS and PATCH, I don't see an option to change the geometry, is that supposed to be done with PUT only?