Cryptic filenames when downloading tiffs, opportunity datasets, results

[erathal]

It would be nice if the tiffs with the regional analysis results would by default be named after the title that the user assigns to any regional analysis.

[Nate-Wessel]

This is also applies to opportunity datasets. e.g. 5e1c7cd3c1f0b40e3af188b3.tiff should be more like region_name-dataset-count_field_name.tiff

[stale[bot]]

This issue has not had any activity for over one year, so it has been marked as stale. It will be closed in 14 days if no further activity occurs. If you would like to keep this issue open, please comment giving an update and confirming its relevance.

[abyrd]

This will require a change to the backend rather than the UI - transferring to R5 repo.

[abyrd]

We need similar logic for giving downloads reasonable names in #610

[abyrd]

I just looked into this a bit. Summary of my current thinking:

• These files are stored (within our system) under seemingly random names for a reason - this associates them with known unique IDs in a database.
• Files could of course be renamed on download and saved under a different name.
• There are several ways to do this. One way is to add a content-disposition header to the HTTP response. Another is to download the file via an HTML anchor (link) with a download attribute specifying the alternate name.

Header Option

A header like Content-Disposition: attachment; filename="Results of Analysis 12A.csv" would have the intended effect. However, when deployed to a cloud environment, our current implementation bypasses the Conveyal backend to retrieve the file directly from cloud object storage so the backend does not have a chance to attach a header. When the files are originally pushed to cloud storage, it is possible to set a content-disposition header, but there are a few issues with this approach: a) This would only affect newly created objects. Existing objects would need to be mass-updated with appropriate filenames. b) Stored objects do not exist solely for download by web clients, but may be used by other components of the system. There is potential for incorrect behavior in other (existing or future) parts of the system if files are always received with a header indicating they are attachments that should be saved under a name different than their internal ID. A hypothetical alternate arrangement where files were served by the backend itself would readily provide control over which headers were supplied in varying situations, but this represents a major change from our current approach. In some cases like Geotiff rasters of regional results, requested files are created on demand but are nonetheless shifted into cloud object storage, allowing them to be retrieved in the same manner as pre-existing results files (directly from cloud object storage).

Download Link Option

I believe this can be implemented as a pure frontend change, by providing files via basic HTML links with download attributes. Files are typically offered for download in a context where all relevant information (region, regional analysis name, layer names etc.) are already needed to render the surrounding page content, so could in principle be assembled to inject meaningful file names into the download attribute.

Backend-assisted Download Link

The backend provides the cloud storage URL to the frontend as a field in a JSON object. This JSON object could be supplemented with another field containing a suggested human-readable alternate name for the object retrieved from the given URL. Depending on the relative availability of the human-friendly information (regional analysis or layer names) between the frontend and backend contexts where these URLs are being handled, it may be more convenient to piece together the name on the backend, such that the frontend need only map {url="https://storage/abcd1234?signature=fdfd1212", name="Regional Results 12C.csv"} to <a href="https://storage/abcd1234?signature=fdfd1212", download="Regional Results 12C.csv">. Conceivably the backend could even return the HTML link directly but then we'd be reinventing https://htmx.org :)