Plusieurs fois ça peut-être utile peut-être pour importer dans Label Studio si Label Studio prend en charge ou si panoramax prend en charge un format d’export pour Label Studio.
Label Studio sert pour faire des modèles d’entrainement IA (comme détection de visage, SIV, panneaux…)
Pour l’instant, on mentionne avec le préfixe |osm uniquement les tags OSM.
Ça permet de s’assurer que l’utilisateur qui clique sur “information” sur l’interface soit bien redirigé vers une page existante.
Par exemple, ce panneau renvoie vers la page Key:traffic_sign — OpenStreetMap Wiki
Étant donné que cette information s’applique à un objet en particulier, je pense qu’il serait particulièrement adapté d’utiliser un qualifier, c’est à dire osm[node;way;relation]=* pour indiquer directement l’ID d’un objet OSM.
Par exemple : osm[node]=2085947986
Il faudrait alors que l’interface renvoie vers sa bonne URL si ce qualifier est utilisé (dans ton exemple : https://www.openstreetmap.org/node/2085947986).
J’ai créé un ticket ici : OSM objects tags to link with Osm.org URL (#1) · Issues · Panoramax / Server / Tagging Presets · GitLab (mais ce n’est pas une décision définitive, la discussion continue !).
Concernant cette syntaxe, ca sort de ta réflexion ou c’est quelque chose qui est déjà vu avec les dev? Dans le sens où elle est déjà différente de osm|node=2085947986 ou pour reprendre une autre syntaxe OSM osm|node|2085947986
Les qualificatifs sont déjà standards (voir la doc que j’ai traduit Syntaxe · Wiki · Panoramax / Clients / Web viewer · GitLab).
Ils ont été créé spécifiquement pour préciser une information complémentaire sur un tag existant.
Par exemple, pour indiquer le niveau de confiance, le modèle utilisé … concernant un panneau détecté automatiquement.
Comme je l’ai précisé sur le ticket, une manière alternative à ma proposition serait d’utiliser un tag simple, comme tu le propose @gendy54 : osm|node=2085947986.
Avantages : plus simple et évite de devoir définir un autre tag au préalable.
Inconvénient : Ça créé une exception dans la règle d’utiliser uniquement des tags OSM (car ici, c’est un objet OSM, sans page wiki directement liée).
Dans tous les cas, il faudra une évolution pour que ça renvoie vers osm.org et non pas vers le wiki.
Bref, pas de solution miracle, c’est un choix à faire.
Il me semblait aussi que le numéro du noeud n’était pas un truc stable si jamais l’objet est supprimé / recréé dans OSM par exemple, ça pète le lien non ?
C’est un défaut structurel d’OSM avec lequel nous devons composer. Cela n’empêche pas de faire référence à un objet : il faut simplement avoir conscience que le lien créé n’est pas éternel.
J’ai commencé à lister les tags que nous avons tous proposés sur une page de wiki dédiée : Dictionnaire · Wiki · Panoramax / Clients / Web viewer · GitLab
Cette page est à construire collaborativement …
Je découvre Pic4review, l’idée est intéressante !
Ça m’a donné envie de tester quelque chose, un peu comme panolinker mais avec une carte, mais pour l’instant je reste bloqué à l’étape où il faut parler à l’api de Panoramax…
Si le projet intéresse quelqu’un, c’est ici : GitHub - LaTeteDansLeGuidon/panoramax2osm
mes 2 premiers défibrillateurs taggés 
Trop bien ! Si tu bloques, n’hésites pas à poser des questions directement sur ce forum (un nouveau post serait tout indiqué) pour avancer.
Salut !
Toujours pas d’idée concernant l’absence, pour certaines séquences, du bouton d’édition (“Voir l’envoi”) ?
Faut-il que j’ouvre un ticket sur le dépôt GitLap ?
Hello, pas besoin, merci : on a bien identifié le problème.
Version courte : c’est un bug, on va corriger.
Version longue : toutes les séquences qui ont été créés avant l’introduction du concept d’uploadset sont concernées (les séquences créées avant cette date sont épargnées).
J’ai vérifié empiriquement et je situe la date entre entre le 10 et le 15 octobre 2025 pour l’instance OSM-Fr.
Nous envisageons de recréer un uploadset pour chacune des séquences, à moins que l’on n’opte pour une autre solution… on vous tient au courant.
En attendant, désolé.es ! Vous pouvez toujours jouer avec les tags dans les images, il y a du gros potentiel 
NB : petite explication de vocabulaire : un uploadset est un envoi de photo, qui dispose d’un identifiant unique. Il dispose également d’une URL unique depuis quelques semaines, par exemple https://panoramax.openstreetmap.fr/upload/f11c1aa0-28f6-4856-ab55-89414d1c432c
Dans cet exemple, on voit qu’un uploadset peut contenir plusieurs séquences (listées en bas de l’écran). Celles-ci sont créées automatiquement.
J’ai créé ma première voiture en utilisant Wikidata.
Je ne connais pas bien la syntaxe Wikidata, mais j’ai l’impression que la clef P31, qui décrit “la nature d’un élément”, sera très souvent utilisée :
wd|P31=Q1420 (nature de l’élément : voiture) (exemple)wd|P31=Q15978631 (nature de l’élément : être humain) (exemple)wd|P31=Q1281598 (nature de l’élément : palette de transport) (exemple)À l’usage, j’utilise
Et du coup, comment tu dirais que c’est le modèle “Renault Twingo”
J’ai déjà le Q720634, mais il manque la clé (P ou Q) et je ne vois pas comment tourner ca.
Sur la page Renault Twingo - Wikidata il est fait mention assez rapidement que la nature de l’élément “Renault Twingo” est une “série de modèles d’automobile” :
Du coup, j’ai rajouté wd|Q59773381=Q720634 (série de modèle d’automobile = Renault Twingo)
Je n’'étais pas très sûr mais spontanément c’était le 1er truc qui me venait à l’esprit. Je trouvais bizarre de mettre Qxxx=Qxxx
Du coup, je viens d’essayer la syntaxe `wd|Qxxx=Qxxx` ne fonctionne pas pour le moment et/ou n’est pas logique car il attend plutôt `wd|Pxxx=Qxxx`. Peu-être est-ce juste qu’il manque l’import des tags Wikidata dans Panoramax comme ca l’est pour OSM.
en effet, les presets ne contiennent pour l’instant que les tags OSM.
Change le label (traduit) et l’icône
je suis embêtée car il faut un compte pour pouvoir ajouter les tags. Or sur l’instance MapComplete on ne peut pas créer de compte… donc pas de tag possible…
J’ai ajouté pas mal de photos depuis MapComplete (street art, plaques commémoratives) parceque c’est beaucoup plus rapide que d’envoyer des photos individuelles via l’interface (1 par 1) mais maintenant je me demande si c’était une bonne idée.
Je réponds un peu tard… mais mieux vaut tard que jamais !
C’est aussi ce que j’ai en tête… établir les liens “retour” d’une façon plus automatique, voire dans les deux sens.
Il faut se méfier du côté militant, mais pour ces exemples, ça me parait pertinent.
Cela permet de sélectionner rapidement des images d’exemple, voire de les exploiter ensuite pour entraîner des modèles (cas des nids de poules) car repérer les images utiles à annoter c’est aussi très chronophage !
Côté OSM, on est plutôt dans la sélection de la photo la plus représentative de l’objet, mais c’est aussi lié à l’unicité du tag panoramax=*
Côté Panoramax, on pourrait se limiter à des photos qui représente “suffisamment” l’objet OSM.
Oui, les id ne sont pas stables sur le long terme dans OSM, mais c’est mieux que rien.
