Consider writing HTTPS asset hrefs instead of s3://

[alexgleith]

It doesn't really make a difference, except it's simpler to load/access assets that have a HTTPS href.

Any thoughts @jessjaco?

[jessjaco]

If I were a naive user I think I would prefer https. I tried to determine why the e.g. USGS stac catalogs use s3 though. It looks like it's a best practice for requester-pays buckets: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md#requester-pays.

I did notice the s3:// urls don't seem to work with my favorite QGIS stac plugin, though this might be fixed.

[alexgleith]

It looks like it's a best practice for requester-pays buckets

Yeah, pretty much.

That was Matt Hansen from Element-84's idea. If the files are public access, just make them HTTP URIs. Only issue there is if you have some S3 optimisation process, there's no hint that it's on S3 unless you interrogate the URI.

The official USGS Landsat Looks STAC API uses HTTP URIs, which are not machine readable (I've complained about this), but have the S3 URI as an alternate. Element-84's version of the Landsat STAC metadata uses just the S3 URI, which is a lot better. (I have a little function to re-write the HTTP to S3 for when I use the Landsatlook STAC API).

In short, yeah,https:// is probably better if they're actually public, and s3:// if there's constraints.