Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Jerome Gasperi
    @jjrom
    @ycespb Hi Yves, the client is waiting for the collections (i.e. the rel=data) in the landing page (e.g. https://tamn.snapplanet.io/?_pretty=1). Then it checks for STAC catalogs in the '/stac' endpoint (e.g. https://tamn.snapplanet.io/stac?_pretty=1). By the way you see that in the /stac endpoint there is no "rel=data" endpoint. Instead each collection (and catalog that is not collection) is provided as a "rel=child" endpoints
    So i'm in favor of removing the /stac endpoint and have everything on the landing page
    i.e. conformance, service-desc, service-doc, search, data, child and item
    ycespb
    @ycespb
    @jjrom Thanks. So we can safely remove this rel="data" from the catalog object (it is a left over from our initial tests).
    Jerome Gasperi
    @jjrom
    Yes absolutely - you just need the rel=data in the landing page
    ycespb
    @ycespb
    @jjrom What about "items". Is it clear yo you that the href used in the link with rel="items" cannot contain query parameters ? This would be very convenient to define subcatalogues for a specific facet without inventing new URLs for each...
    @jjrom You are using a "matched" property with the subcatalogs to indicate the number of items inside. Is this specific to your implementation or did you find this in one of the extensions ?
    Jerome Gasperi
    @jjrom
    @ycespb Yes the "rel=items" should not contain query parameters. However i'm in favor to add an optional additional property "queryParams" or whatever to describe which parameters can be used for search. Something similar to the <parameters:Parameter from OpenSearchDescription (e.g. https://tamn.snapplanet.io/services/osdd)
    @ycespb The "matched" property is specific to my implementation. I just keep the same naming convention as the one choosen in "search:metadata" extension (which is now named "context" from what i see on the PR radiantearth/stac-spec#633)
    Jerome Gasperi
    @jjrom
    @ycespb I mean an optional additional property "queryParams" in the link object
    ycespb
    @ycespb
    @jjrom Ok; Thanks - I'll look at your example.. What about the href used to point to a subcatalog in links with rel="child". What is the reason to not allow (implementation-specific) query parameters inside this href ? This should be opaque to a client shouldn't it ? also because subcatalog URL are not supposed to be extended with /items/... if they are not "collections" ? This extension of the path seems only being used for "collections" (because of the OAFeat spec).. Maybe this is because many examples show "static" catalogs ?
    Jerome Gasperi
    @jjrom
    @ycespb Yes I think it's linked to the "static" catalog compatibility. From a client there should be no difference to distinguish between a static and a dynamic catalog from href. On the implementation side i prefer to keep the href without query parameters and hopefully rely on an additional property of the link object to describe what kind of search parameters can be used. One advantage over params in href is that you can have an exhaustive description of the params (i.e. type, bounds, pattern, etc.). For "rel=child", i have exactly this issue not to be able to pass a query parmeters. As you see in my example, my catalogs can have a lot of items. Since i cannot return all items, i only return the 20 most recents. So ability to paginate would be great
    ycespb
    @ycespb
    @jjrom Yes. This asymmetrical approach, not being able to do paging or searching on "collections" but only on "items" is not so nice. Would be better to be fully aligned.
    ycespb
    @ycespb
    @jjrom Can you remind me how you distinguish in your Client between a Catalog and a Collection in your client ? Are collections only the ones that appear in the rel="data" list or do decide this in another way (presence of extent / version / providers property) ? Accordign to the UML model https://github.com/radiantearth/stac-spec/blob/master/STAC-UML.pdf collections can contain all properties that catalog contain and some more ...
    Alessandro Pasotti
    @elpaso
    Does anyone know what encoding should be used for blobs in transactions? base64?
    Jerome Gasperi
    @jjrom
    @ycespb I use the following assumptions from my understanding on the OAPIF and STAC specifications - "rel=data" = collections; "rel=child" = catalog (including single collection); "rel=items" = GeoJSON FeatureCollection; "rel=item" = GeoJSON Feature
    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