sat-api implementation status and lessons learned about stac-spec

[m-mohr]

Regarding links:

• I think the structure originates from the REST/Hypermedia principles and is somehow standardized in the HTTP specification (e.g. RFC 2068, chapter 19.6.2.4). It's also how it is used in XML/HTML (<link rel="" href="" />). What you suggest sounds much like HAL. Whatever is chosen, it should be consistent across the whole spec.
• I had the same confusion about the meta data references: links or assets? @hgs-msmith once suggested me in the chat to add them to the assets.

Regarding endpoints:

• I agree that the endpoints are somehow inconsistently named and I must say that I really don't like the WFS-like naming of /search/stac. It just doesn't feel right in resource-oriented REST interfaces. I'd also expect it at /collections and /items (or similar names). If you'd follow REST you'd have to remove /stac completely. Content negotiation with aan Accept header would be the correct way to get a STAC response, I think.

Regarding ranges:

• Having cloud_cover=0/20 for >=0 and <=20, I'd logically expect

  • >=0 being cloud_cover=0/
  • <=20 being cloud_cover=/20
  • ==0 being cloud_cover=0 (alternatively 0/0 would mean the same)

  Anything else missing? Probably not consistent with ISO8601 though, but is part of Dublin Core: http://www.ukoln.ac.uk/metadata/dcmi/date-dccd-odrf/2005-08-13/

[cholmes]

Awesome work Matt. Thanks for getting real world implementation and helping evolve the spec. Psyched for the next iterations.

Regarding links:

• For links, yeah, consistency across links and assets makes sense. Wish we'd thought of that at the last revision. And yes, I agree with @hgs-msmith that metadata should go in assets. I see assets are the things that a user would likely want to download, and links describing relationships with other online entities. I can see how the line is blurry, and I could see if there's a great html metadata that you don't download then using a like rel=describedBy could make good sense. But I feel like most imagery still has metadata as xml or text files.

Regarding endpoints:

• I don't love the STAC in the resource either. But I do think we should make something that is compatible with WFS. I'm not sure if /search/stac is the best way - that was a request from the WFS people, but they don't have a clear search endpoint.

Though I'm not sure I understand https://sat-api.developmentseed.org/collections?collection=landsat-8 - seems like it should be https://sat-api.developmentseed.org/collections/landsat-8 And then https://sat-api.developmentseed.org/collections/landsat-8/items which enables basic single collection search. The idea with the /search endpoint is that it allows cross collection search. Those resources make sense to me a /search endpoint to do more complex searches, and individual collections under collections/{collection-name}/

Regarding CRS

• Would be good to get the CRS field changed asap, I found myself not using it, and doing epsg. Maybe make an issue or PR on that specifically?

Regarding ranges:

• I'm +1 on specifying these more, have no real opinions though.

[m-mohr]

WFS might get a search endpoint at least: opengeospatial/ogcapi-features#79

[m-mohr]

What's the state of this issue?