Zenodo: Prise en charge de la « demande de plage d'octets HTTP/1.1 » dans la récupération de fichiers

Je vais seconder ceci. Il serait très utile, par exemple, d'accéder directement aux ensembles de données génomiques avec tabix . Cela semble nécessiter un changement de configuration dans le paramètre 'max_ranges' du serveur Web

Y a-t-il une raison technique de ne pas le faire ?

Notre backend de stockage de fichiers n'est actuellement pas optimisé pour servir les demandes de plage HTTP (ce qui signifie que l'activation de cette fonctionnalité entraînerait potentiellement des ralentissements importants pour l'API de téléchargement/téléchargement de fichiers). Bien sûr, il y a des gens qui travaillent à rendre cela possible, bien que nous ne puissions pas donner d'ETA précis là-dessus...

Je voulais juste ajouter mon :+1: pour indiquer que l'activation des demandes de plage serait très utile pour les formats de données géospatiales. Cloud Optimized GeoTIFF en particulier en bénéficierait beaucoup. Autoriser les demandes de plage pourrait vraiment réduire la bande passante nécessaire à zenodo.

Notre backend de stockage de fichiers n'est actuellement pas optimisé pour servir les demandes de plage HTTP (ce qui signifie que l'activation de cette fonctionnalité entraînerait potentiellement des ralentissements importants pour l'API de téléchargement/téléchargement de fichiers). Bien sûr, il y a des gens qui travaillent à rendre cela possible, bien que nous ne puissions pas donner d'ETA précis là-dessus...

De nombreuses personnes ne peuvent pas télécharger de gros fichiers génétiques (plusieurs Go). par exemple,
https://github.com/zenodo/zenodo/issues/460#issuecomment -546623751

Certains doivent réessayer plusieurs fois, et cela gaspille en fait votre bande passante...

Pour notre projet, il est également important que nous puissions utiliser des GeoTIFF optimisés pour le cloud (voir par exemple https://zenodo.org/record/4483227) directement depuis Zenodo. Figshare fonctionne apparemment avec les COG, pas zenodo ? Nous avons écrit un tutoriel pour les utilisateurs sur la façon d'obtenir de petits morceaux de données à l'aide de fichiers COG .

Pourriez-vous s'il vous plaît soutenir cela?

Nous en avons besoin pour servir de gros fichiers image (au format Zarr) par morceaux, ce qui nous permet de visualiser instantanément les fichiers dans le navigateur. Le navigateur ne pourra pas télécharger le fichier, par exemple 10 Go, et l'afficher.

Juste en notant la valeur pour le cas d'utilisation de Zarr. Merci à tous pour votre travail sur Zenodo !

Pour Zarr, nous pourrions hypothétiquement faire fonctionner zenodo aujourd'hui, sans aucun changement. Zenodo ne prend pas en charge les répertoires, mais si nous pouvions mapper un magasin de répertoires zarr standard à une sorte de hiérarchie plate, via un caractère spécial, nous pourrions le faire fonctionner. Par exemple, si le caractère spécial est __

.zgroup
foo__.zarray
foo__.zattrs
foo__0.0
foo__0.1

etc.

Pourriez-vous s'il vous plaît soulever un problème ici ( https://github.com/zarr-developers/zarr-specs/issues ) ?

@rabernat J'ai peur que cela ne change pas car Zenodo n'autorise que 100 fichiers au maximum.

La limite de taille totale des fichiers par enregistrement est de 50 Go (max 100 fichiers). Un quota unique de 100 Go peut être demandé et accordé au cas par cas.

source : https://www.openaire.eu/technical-requirements