search

digitalearthpacific / dep-tools

Processing tools for Digital Earth Pacific
MIT License
1 stars 0 forks source link

Consider writing HTTPS asset `href`s instead of `s3://` #65

Open alexgleith opened 5 days ago

alexgleith commented 5 days ago

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

Any thoughts @jessjaco?

jessjaco commented 17 hours ago

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 commented 16 hours ago

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.