Human-friendly URLs / Generate cleaner slugs in the browser.

[lossyrob]

Current stac-browser uses a Base58 encoding of a STAC object's relative path to its root catalog as the slug for the URL path. This produces slugs that can be directly decoded into paths, but the URLs are long and not human readable.

The goal of this issue is to develop better slugs for STAC objects.

#29 represents a draft that solves the issue by utilizing conventions.

[m-mohr]

It seems like we have the choice between

1. nice URLs like http://localhost/browser#/item/CBERS4/AWFI/007/075/CBERS_4_AWFI_20201019_007_075_L2.json
2. convenient navigation (e.g. breadcrumb)

The issue is that the URL stores information about the catalog structure (e.g. all parents) so that a breadcrumb can be shown. If we remove this and only show the location of the current file, I can only lazy load the parents and they need to be present for that in the links, of course. The question is what is more desirable? Of course, I could try to cache things in local storage to mitigate the issue a bit. Nevertheless, on a page reload it would need to load all parents. If parents are not given, you are stuck anyway. I'd like to get people in a discussion what they would prioritize... cc @cholmes

[m-mohr]

What we could rely on is a set of pre-defined catalog structures a publisher could choose from. For example, the old best practice (we've changed it recently to be not very useful here any longer, see radiantearth/stac-spec#925) would have allowed to make breadcrumbs based on the folder structure.

If we go for clean slugs, the breadcrumb would miss some levels of the catalog. For example the CBERS link from above:
Before: CBERS4 > AWFI > 007 > 075 >CBERS_4_AWFI_20201019_007_075_L2
After: CBERS4 > ... > 075 >CBERS_4_AWFI_20201019_007_075_L2 (i.e. it can usually only show the root and parent)

You'd be able click the ... and then it would load the remaining items for you.

Side Note: I could also request all "parent" catalogs via additional HTTP requests. This is currently also done by STAC Browser, but this leads to quite a lot of data to transfer and I'd like to make the Browser more lightweight with data transfer consumption.

[m-mohr]

Some catalog structures that we could make configurable to get nicer slugs:

• default: Just shows parent and root, in between there will be dots as show above. The default works well for catalogs with up to three levels (i.e. root -> catalog -> item). *
• best-practice: Follows the STAC best-practice. Has a catalog.json in each folder. *
• ogc-api-features -> If the catalog is following the OGC API -Features spec, we could rely on the API structure with /collections, /collections/:cid, /collections/:cid/items and /collections/:cid/items/:id.

* = With the recent change in radiantearth/stac-spec#925 this is not true any longer and in each folder there could also be a collection.json instead of a catalog.json. Thus, for some catalogs it is true that the collection.json is only at a specific level (e.g. root -> catalog -> collection -> catalogs... -> items) and thus an option to set the "collection level" would be required (maybe multiple levels?).

The following catalogs fullfil the requirements:

• API:
  • All APIs implementing OGC API Features, but some API implementations have both a link structure and the API structure. This may need us to allow selecting two options.
• default (without ...):
  • California Forest Observatory (collection level 0 = no collections)
  • GEE (no collection level required as there are no items)
  • Open SkySat Data (collection level 1 = root)
  • eBird Status and Trends 2018 (collection level 1)
  • Planet Disaster Data (collection level 1)
  • USGS 3DEP Lidar (collection level 0)
  • SPOT 4 (collection level 2)
  • NASA ISERV (collection level 2)
  • Pangeo (collection level 3)
• best-practice:
  • CBERS (collection level 3)
  • Sentinel 5P Level 2 (collection level 0)

The issue with setting this is that for general-purpose deployments (STAC Index) one would need to specify this individually and thus usually the default would be active and have ... in the breadcrumbs.

[m-mohr]

I don't think I fully understand your request.

So right now the Mars data can be "shared" with this link:
https://stac.astrogeology.usgs.gov/browser/#/3q52Dkr5nBe3g684y9fzjwTFMjyyQ66QitBuDrNggEBLhzMJFUvkYYXvSppyx71tvJpVWQkxLgEHK What are you missing?

Is this not "clean" due to the "strange" URL? Or is the issue that the catalogs reside on different (sub-)domains/buckets?
The URL in the future would likely look something like this:
https://stac.astrogeology.usgs.gov/browser/#/browse/asc-mars.s3.us-west-2.amazonaws.com/catalog.json

And yes, it's planned to solve the issue with different domains/buckets, too. Right now it just uses URL without protocol in the URL, but I may actually also implement that you can define aliases for certain "base URLs" so that it looks more like
https://stac.astrogeology.usgs.gov/browser/#/mars/browse/catalog.json or so.

[jlaura]

@m-mohr I think I had some cacheing issues going on. The link looked and worked really well. I was having that link resolve with a NoSuchKey error and thought it was due to the URL. Apologies for the noise on this issue. I'll hide the post to keep this issue on topic!

[m-mohr]

Alright, if you find any other issues or have feature requests, let me know.

[m-mohr]

Clean-urls have been implemented in STAC Browser v3