[Datahub]: Handle OGC API in Downloads and Preview sections

[cmoinier]

Thanks @Angi-Kinas for the pairing on this!

Description

This PR adds OGC API support in the downloads and preview section :

• If any OGC API download link exists, it will be returned as a download item
• Currently, it is not important is there are multiple links with the same type (ie: one GeoJson link for WFS & one GeoJson link for OGC)
• If any OGC API download link of the right type exists (eg, geosjon), this link will be added to the dropdown lists of the three preview dropdowns.

Architectural changes

This depends on ogc-client version 1.1.0 (upgraded in the package).

Quality Assurance Checklist

• Commit history is devoid of any merge commits and readable to facilitate reviews
• If new logic ⚙️ is introduced: unit tests were added
• If new user stories 🤏 are introduced: E2E tests were added
• If new UI components 🕹️ are introduced: corresponding stories in Storybook were created
• If breaking changes 🪚 are introduced: add the breaking change label
• If bugs 🐞 are fixed: add the backport <release branch> label
• The documentation website 📚 has received the love it deserves

[github-actions]

Affected libs: feature-dataviz, feature-record, feature-router, util-shared, feature-catalog, feature-search, feature-map, ui-elements, feature-notifications, feature-editor, ui-catalog, ui-search, ui-widgets, ui-inputs, ui-layout,
Affected apps: datahub, metadata-editor, demo, webcomponents, search, metadata-converter, map-viewer, datafeeder,

• 🚀 Build and deploy storybook and demo on GitHub Pages
• 📦 Build and push affected docker images

[github-actions]

📷 Screenshots are here!

[coveralls]

coverage: 84.115% (+2.4%) from 81.762%
when pulling 3e2d3b0 on DH/ogc-api-support
into e07c560 on main.

[tkohr]

Thanks for the nice work @cmoinier ! I've left a couple of suggestions inline. Besides that I noticed some things when testing:

• I had CORS issues when using the /dev-proxy? in our local dev compo (not sure, if this is expected)
• The SCOT testing dataset seems to have an erroneous OGC API URL in the dump
• What do you think of sorting the downloads by dataset instead of format? Not sure if this was specified anywhere? It would need to be discussed, but it seems more intuitive to me.

[cmoinier]

Thanks for the review @tkohr ! It was really helpful, and I hope my answers are easy to understand.
For these points :

* I had CORS issues when using the `/dev-proxy?` in our local dev compo (not sure, if this is expected)

I had CORS issues as well, unless I activated a CORS plugin. Not sure if this is what you meant.

* The SCOT testing dataset seems to have an erroneous OGC API URL in the dump

True, I knew it and forgot about it. I will update the dataset with a working URL.

* What do you think of sorting the downloads by dataset instead of format? Not sure if this was specified anywhere? It would need to be discussed, but it seems more intuitive to me.

Nothing was specified about it, but it was written in the ticket that duplicates should be left as is (ie if wfs and ogc both return the same download type) for now. So we assumed that the display would be figured out later, but Christophe said during the review that we shall meet to discuss it this week.

[tkohr]

Thanks for the adaptions @cmoinier, especially in the dump!

Almost everything LGTM. The only thing I'm still concerned about, is that we get CORS errors using the /dev-proxy?. They occur on the API call to detect the proposed formats as well as on data fetching where the URLs are not "proxified".
It should not be a problem in the MEL use case where the API and client are on the same host, and we could also blame the host for not including a response header with a Access-Control-Allow-Origin: * (btw we should probably add the header to the MEL data API?), but I saw for WFS we proxify certain requests. @jahow what is your opinion on this?

Regarding the earlier comment about the sorting, I think we can rework this again in the future if necessary. It should not block this PR as the current sorting has already been present with multiple datasets before.

[jahow]

@tkohr oh you're right, we're missing a "getProxiedUrl" for the OGC API endpoints I think, similar to WFS:

geonetwork-ui/libs/feature/dataviz/src/lib/service/data.service.ts

Line 59 in 0044387

new WfsEndpoint(this.proxy.getProxiedUrl(wfsUrl)).isReady()

[jahow]

@tkohr oh you're right, we're missing a "getProxiedUrl" for the OGC API endpoints I think, similar to WFS:

geonetwork-ui/libs/feature/dataviz/src/lib/service/data.service.ts

Line 59 in 0044387

new WfsEndpoint(this.proxy.getProxiedUrl(wfsUrl)).isReady()

I looked into it more and using a proxy with OGC API will be more complicated than that, because ogc-client navigates through the url path by looking for "/". When the endpoint url is encoded this won't work at all.

Using a dev proxy for an OGC API endpoint will be more involved than that, I think this should be done in a separate PR.

[jahow]

This is looking very good, thanks for this awesome contribution! I've added stubs for the ogc api responses in the E2E tests, hopefully this will make the tests faster and more reliable.

[jahow]

Oh, also I left out the changes on the dump and everything works fine 👌