Ajouter des photos très haute définition sur les itinéraires, POI et sites outdoor

[camillemonchicourt]

Lors de la conception du module OUTDOOR, une réflexion avait été initiée sur les possibilités de représentations des sites d'activité Outdoor, notamment celles verticales (escalade, via-ferrata, alpinisme...) pour aller au-delà de leur localisation sur une carte (https://geotrek.ecrins-parcnational.fr/ressources/gt/07-geotrek-apn/2019-06-Benchmark_Representation-Escalade.pdf).

Suite à cela, le PNE a lancé une consultation pour ajouter la possibilité d'ajouter des photos très haute définition (gigapixel) sur les itinéraires et sites outdoor et d'annoter ceux-ci pour les enrichir, ainsi que l'amélioration du module Rando3D et son intégration sur les sites Outdoor (dans Geotrek-rando-v3) : https://geotrek.ecrins-parcnational.fr/ressources/cctp/2022-06-23-CCTP-Geotrek-representation-outdoor.pdf

Les développements de l'ajout de photos très haute résolution ont bien avancé côté Geotrek-admin : #3298

Il s'agit pour cela :

• d'ajouter une table des vues HD assez semblables à celle des fichiers liés
• de pouvoir charger une photo très HD (de plusieurs dizaines ou centaines de Mo) depuis l'onglet "FICHIERS LIES" des itinéraires, POI et sites Outdoor, de la tuiler automatiquement pour disposer d'un fichier plus léger à charger dans un navigateur avec des tuiles à chaque niveau de zoom (fonctionnant comme les fonds de carte tuilés). Pour cela, la librairie python large-image a été utilisée, d'autant qu'elle était déjà portée pour Django (https://github.com/girder/django-large-image)
• d'ajouter une librairie javascript permettant d'ajouter des objets (points, lignes, polygones, cercles...) et des textes pour enrichir les photos. Ceux-ci sont stockés en GeoJSON et pourront donc être affichés par dessus la photo tuilée dans une librairie javascript de cartographie (comme Leaflet ou autre) au niveau de Geotrek-rando-v3 ou autre. Pour cela, on s'est appuyé sur la librairie javascript GeoJS (https://opengeoscience.github.io/geojs/examples/annotations/)
• d'ajouter les vues HD ainsi que leurs annotations dans l'API v2 de Geotrek-admin pour pouvoir les afficher dans Geotrek-rando-v3 ou autre

Liste des photos HD (sous les autres fichiers liés) :

Détail d'une photo HD :

Annotation d'une photo HD :

[babastienne]

Comment les objets HD sont gérés par rapport aux PDFs générés par Geotrek ? Je ne me souviens pas qu'on ai abordé ce sujet.

[camillemonchicourt]

En effet, on n'a pas abordé ce sujet. Ça pourrait être une évolution.
On n'affiche déjà pas toutes les photos des randos ou des sites Outdoor, mais seulement la première, donc je pense qu'intégrer la photo HD en petit n'a pas grand intérêt, du moins dans un premier temps.

[camillemonchicourt]

Fonctionnalité disponible dans la version 2.96.

[Chatewgne]

Chiffrage traductions des annotations

Le problème

La librairie GeoJS ne gère pas la traduction des labels des annotations. Elle n'expose que l'attribut name pour chaque annotation. Cet attribut est automatiquement utilisé comme label pour l'affichage du GeoJSON sur le viewer, il y a des méthodes pour le changer, le masquer. La valeur vide n'est pas autorisée. Nous aurions plutôt aimé avoir name_fr, name_en comme dans le reste de l'application.

Contournement proposé

Rajouter dans les propriétés du geojson autant d'attributs name_xx que de langues. Le formulaire doit donc imiter côté front-end le mécanisme de traduction Django : si la langue courante est fr alors name et name_fr sont en cours d'édition et prendrons la même valeur (parce que si name n'est pas mis à jour, on ne verra pas le résultat du changement de langue sur le viewer.) On considère donc que les "vraies" valeurs sont stockées dans name_en, name_fr et que name est constamment synchronisé avec la lanque courante. Attention cela veut dire qu'en base de données, si la dernière langue à être éditée est l'allemand, alors la valeur name serait en allemand, il faut donc rajouter une étape lors de la sauvegarde pour remettre name à la langue par défaut de l'application).

To do

• modifier le formulaire pour qu'il n'édite plus name mais name_fr -> 1j

Pistes javascript - Click to expand

current_data = JSON.parse($('#id_annotations[type=textarea]').val());

current_data['features'][0]['properties']['name_fr'] = "Mon nom";

$('#id_annotations[type=textarea]').val(JSON.stringify(current_data, null, 2));

$('#id_annotations[type=textarea]').trigger('propertychange') (fonctionne si j'édite le contenu à la main dans le textarea après avoir enlevé display none)

• modifier le formulaire pour que name soit synchronisé avec name_xx à chaque update de name_xx -> 1j
• Remplacer le widget actuel de labels par un widget de traduction avec les petits 'fr' 'en' en bleu -> 2j min (je ne sais pas encore comment faire)

• Au clic sur le widget -> changement de langue courante -> le formulaire n'édite plus name_xx mais name_xy et le viewer est rafraîchit -> 1j
• à la sauvegarde du formulaire : récupérer langue par défaut de l'app et remettre name := name_default avant de sauvegarder les annotations, s'assurer qu'on a bien la cohérence entre name et la langue d'édition par défaut du formulaire-> 0,5j
• dans l'APIv2 : récupérer l'attribut lang pour mettre à jour le geojson avec name := name_fr au cours de la sérialisation du geojson, sinon remplacer l'attribut name par un dictionnaire comme dans le reste de l'APIv2. -> 0,5j

Total 6 jours de travail