Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data service: better detect file formats from WFS outputs #786

Merged
merged 2 commits into from
Feb 1, 2024

Conversation

jahow
Copy link
Collaborator

@jahow jahow commented Feb 1, 2024

Description

This PR reworks the logic for inferring file formats from a list of output types provided by a WFS endpoints. WFS will typically advertise these kinds of formats:
image

With this PR, formats such as DXF, Shapefile and GML will now be recognized and show up properly in the Datahub download list.

Note that the DXF and GML formats were added to the list of recognized formats in the process.

Architectural changes

none

Screenshots

image

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

This work is sponsored by Géo2France.

The generated links now have a 'download' type. Also the access protocol
is now allowed on the download link model as well, which makes sense if we
want to know what protocol the links goes through
… output, add GML and DXF formats

The WFS services sometimes offer otuput formats like SHAPE-ZIP or GML2,
and we need a more reliable way to infer a file format from them

Use this in the data service to make sure we output known mime types from
WFS and ESRI Rest
Copy link
Contributor

github-actions bot commented Feb 1, 2024

Affected libs: common-domain, api-metadata-converter, feature-editor, api-repository, feature-catalog, feature-record, feature-router, feature-search, feature-map, feature-dataviz, feature-auth, ui-search, common-fixtures, util-shared, ui-elements, ui-catalog, ui-widgets, ui-inputs, ui-map, ui-dataviz,
Affected apps: metadata-converter, metadata-editor, datafeeder, demo, datahub, webcomponents, map-viewer, search, data-platform,

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

@@ -45,7 +45,7 @@ interface WfsDownloadUrls {
export class DataService {
constructor(private proxy: ProxyService) {}

private getDownloadUrlsFromWfs(
getDownloadUrlsFromWfs(
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes were made to avoid TS errors in the corresponding test file

@coveralls
Copy link

Coverage Status

coverage: 83.185% (+0.9%) from 82.251%
when pulling 91aad32 on fix-missing-shp-format-wfs
into 95201f8 on main.

Copy link
Collaborator

@Angi-Kinas Angi-Kinas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing this! 🚀

Copy link
Collaborator

@cmoinier cmoinier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks ! 🙂

@jahow jahow merged commit aecf190 into main Feb 1, 2024
9 checks passed
@jahow jahow deleted the fix-missing-shp-format-wfs branch February 1, 2024 13:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants