You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GeoNode exposes multiple ways to download resources, depending on where the download action is located and the resource type.
Download action inside catalog cards (at the moment not working because download_urls are not included inside the catalog_list API preset)
Download icon inside the preview panel
Download icon inside the details panel
Download action inside the action navbar of the document viewer
Download action inside the action navbar of the dataset viewer (Download -> Dataset)
Download action inside the TOC of maps
1 to 4 implement a custom operation for GeoNode, sending a (possibly AJAX) request to the first download URL marked as default=True from the download_urls array returned by the API.
5 and 6 use MapStore to perform async WPS exports (or WFS if WPS is not available).
The GeoNode URL (cases 1 to 4) returned by GeoNode is a view that can potentially execute different operations depending on the resource configuration or the DownloadHandler implementation. For example, MapStore implements a download handler that returns a pre-signed URL to an S3 bucket for certain datasets.
This logic is not handled by cases 5 and 6, since MapStore bypasses GeoNode.
This brings us to a situation where the user will face different download paths depending on the action they trigger:
by clicking actions 5 and 6 they will trigger a WPS process even if a pre-packaged file was prepared for big datasets (the example for MapStand)
by clicking actions 4 to 6, for the default case a synchronous WPS execution is triggered by the GeoNode backend, potentially causing a synchronous transfer of huge datasets with all the problems that this can cause (blocking backend workers, timeouts, exceeds of buffer watermarks, etc.).
Solution
We want to harmonize the download options by implementing the following:
Cards (Case 1):
the download action is removed. It's already not working, since the required download_urls are not returned in the home page now.
Dataset preview and detail panel (Cases 2 and 3):
The download icon will behave the same as now (only direct download)
Dataset Viewer (Case 5):
The current Download -> Dataset action in the dataset viewer navbar (Case 5) will execute the direct download as in cases 2 and 3. It will use the "default" download URL returned inside the download_urls array by the API. This button will only be available for local datasets.
A new Download -> Export data action will execute MapStore's export, which is available for both local and remote datasets.
Map Viewer (Case 6):
A plugin will replace the export tool for layers in the TOC. It will implement a dropdown with the same logic as the Dataset Viewer, with two options: "Download" and "Export data".
The text was updated successfully, but these errors were encountered:
Overview
GeoNode exposes multiple ways to download resources, depending on where the download action is located and the resource type.
download_urls
are not included inside thecatalog_list
API preset)1 to 4 implement a custom operation for GeoNode, sending a (possibly AJAX) request to the first download URL marked as
default=True
from thedownload_urls
array returned by the API.5 and 6 use MapStore to perform async WPS exports (or WFS if WPS is not available).
The GeoNode URL (cases 1 to 4) returned by GeoNode is a view that can potentially execute different operations depending on the resource configuration or the
DownloadHandler
implementation. For example, MapStore implements a download handler that returns a pre-signed URL to an S3 bucket for certain datasets.This logic is not handled by cases 5 and 6, since MapStore bypasses GeoNode.
This brings us to a situation where the user will face different download paths depending on the action they trigger:
Solution
We want to harmonize the download options by implementing the following:
The text was updated successfully, but these errors were encountered: