feat: convert relative paths to absolute

[blacha]

Motivation

Most of LINZ's STAC items and collections are relative links as to make it easier to move them around, we have a long term goal of converting them all to absolute links but that is going to take a way.

In the mean time it would be great if this map tool supported relative links and assets.

Modification

I have added a symbol to all items that have been fetched via the fetchStac to store their source location onto the STAC document, so then any URL referenced from the document can converted with the source URL.

I tried to avoid mutating the stac documents as I wasn't sure of the imapct, so I avoided these two other ideas

• Converting the self link to be the actual source location then using the self link to create relative
• Converting all links in the document to be absolute

[gadomski]

Thanks for the PR! Really appreciate it.

Converting all links in the document to be absolute

I think this is the approach I'd like to take. Since we're not creating STAC items, but loading it in from external sources, I think it's fine if we mutate-on-read to make the rest of the app "simple" (rather than having to repeatedly "resolve" relative urls).

[blacha]

If your happy with mutating the documents, that would be a better approach, Are you ok if I leave properties alone and only touch objects with .href eg links, and assets?

[gadomski]

Yep, I think links and assets are everything we need to do for now. Appreciate it!

[blacha]

@gadomski I have swapped across to converting the stac document when it is fetched,

I have used URL to handle the complex task of attempting to join two URLs, the javascript URL class has some drawbacks as it expects all URLs to be compliant with HTTP URL standards which S3 URLs are not, this can lead to some unwanted encoding problems. https://github.com/developmentseed/stac-map/pull/108/files#diff-9c0b5e75493690a4857c2530601f541478f133f9cfc40191dafaa02fa3d29143R21

A more comprehensive external lib like uri-js may be better suited for the advanced joins, or possibly just ignoring non http(s?) URLS would be the best approach?

[gadomski]

Thanks for iterating, and for adding tests!

A more comprehensive external lib like uri-js may be better suited for the advanced joins, or possibly just ignoring non http(s?) URLS would be the best approach?

I'd be more in favor of using an external lib. While s3 urls aren't supported for direct loading now, I'd like to be able to point the app at s3 at some point down the road.

[blacha]

I'd be more in favor of using an external lib. While s3 urls aren't supported for direct loading now, I'd like to be able to point the app at s3 at some point down the road.

The current logic handles S3 URLs, however the STAC document would need to be loaded from a S3 URL for the logic to trigger, I am not sure how relevant that is for a client side library, unless your providing credentials to the client then it would be better to use HTTP access?

If in the future other source protocols are added that need specialised encoding, ideally you would want to use a specific URL parser/joiner per protocol.

With the current logic:

If the links inside the document are absolute, no changes are applied.

If the links inside the document are relative:

• If the STAC source is http/https, they are URL encoded as per WHATWG URL standard
• If the STAC source is S3 link, they are returned as a raw s3 string without URL encoding

[gadomski]

I am not sure how relevant that is for a client side library, unless your providing credentials to the client then it would be better to use HTTP access?

Yup, this is the long-term idea, very much in the future at this point. Thanks for talking through things, I'll review.

[gadomski]

Just a couple small tweaks, but in general looks great!

[github-actions]

🎉 This PR is included in version 0.3.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀