Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Chris Holmes
    @cholmes
    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?
    ycespb
    @ycespb
    @jjrom Maybe the "targetSchema" property defined here https://json-schema.org/latest/json-schema-hypermedia.html#rfc.section.6.5.4 is an alternative to the "profile" approach...
    Andrea Aime
    @aaime
    @rouault checked, other versions of the WFS protocol would behave the same I think... the issue is that we first test if the two envelopes intersect, and they do, and then do a full intersection test with JTS, polygon vs polygon, apparently the empty polygon coming out of the empty envelope is not topologically intersecting, according to JTS
    I guess I can try to expand the bbox a tiny bit, minimum delta that would make one of the ordinates different than the other in the floating point encoding
    Andrea Aime
    @aaime
    seems a bit of a gray area... @rouault are you doing the bbox like that to do a sort of "featureinfo"?
    Jerome Gasperi
    @jjrom
    @ycespb Hum...not sure from the example it looks quite cryptic. I would really have a simple stuff like what we have for COG i.e. "profile:cloud-optimized" in the mimeType. Would "profile:stac-collection" not valid ? It will not be an official mime-type but at least it's meaningful within the stac spec
    ycespb
    @ycespb
    @jjrom Not sure. Here are examples of profiles and their URI: https://tools.ietf.org/html/rfc7284.
    Even Rouault
    @rouault
    @aaime Yes, I generally like to try the "what is at my place" kind of test query. This is far from being critical. I remember having that kind of issue with ElasticSearch or MongoDB and changed the client to do a small rectangle
    Andrea Aime
    @aaime
    @rouault so are we good?
    Even Rouault
    @rouault
    on that bbox=point point of view ? I'd still like some clarification from the spec to know if servers are allowed to interpret this as an empty bbox or not
    I should probably create an issue regarding this
    Andrea Aime
    @aaime
    @rouault in general I mean, do you have what you need to run a demo?
    Even Rouault
    @rouault
    yes. let me know when the server has deployed your /api changes to check if i can work without my current workaround
    Andrea Aime
    @aaime
    right