Tags panneaux - cartouches et pannonceaux

Hello,
Je tâtonne sur la description sémantique de ce panneau de signalisation directionnel :

Mon intuition, à ce stade, serait de découper en autant d’annotations que de directions.

Ici, ce serait donc 2 (une à gauche et une à droite) :

Et les cartouches et panonceaux seraient des tags détaillant cette même annotation.

pour le panneau du haut, ça donnerait donc :

1. Définir le type de panneau

Ici, il s’agit du D21a cf. Wikipédia :

osm|traffic_sign=FR:D21a

2. Préciser le texte inscrit sur le panneau

On peut rester très fidèle au terrain et indiquer ce qui apparaît :

inscription=16 RAMBOUILLET↲4 CERNAY LA VILLE

… mais je pense que c’est une occasion manquée de séparer dans des champs différents des informations qui n’ont rien à voir, à savoir la direction et la distance.

Ma proposition :

destination_1=RAMBOUILLET
distance_1=16
destination_2=CERNAY LA VILLE
distance_2=4

N.B. 1 : on se voit obligés d’incrémenter explicitement chaque ligne. Je propose le séparateur “_” (underscore) pour incrémenter (par exemple destination_1).

N.B. 2 : l’ordre de l’incrémentation est celui de la lecture, de haut en bas (la première direction indiquée sur le panneau a l’incrément destination_1)

N.B. 3 : je pense qu’on devrait respecter la casse et les abréviations indiquées sur le terrain.
Par exemple, pour cette destination :


Indiquer image en majuscule et avec l’abréviation en exposant et non pas “Brie-Comte-Robert”.
On cherche avant tout à décrire la photo → l’interprétation devrait donc se limiter au minimum.

3. Détailler les cartouches et panonceaux

Côté traduction, j’ai l’impression que “cartouche” se dit “overhead sign” (source gov.uk) et “panonceau” se dit “plate” (source Wikipédia).

Ceci dit, c’est peut-être l’occasion de penser mondial dans l’approche : dans certains pays, le cartouche n’indique pas le nom de la route, donc avec la même clef, on pourrait indiquer une toute autre information en fonction du pays.
Donc, plutôt que d’indiquer l’existence d’un cartouche, on peut indiquer sa fonction, tout simplement “le nom de la route” :

road_name=D906

N.B. : pour les panonceaux, je n’ai pas encore de conviction concernant l’utilisation de plate ou directement indiquer l’impact (véhicule impacté, distance d’application du panneau …)

4. Indiquer la direction (facultatif)

On pourrait préciser la direction cardinale du panneau, en utilisant le format existant dans OSM (source).

Ici, le panneau indique le Sud-Ouest :

direction=SW

Résultat

Voici donc ma proposition pour ces deux annotations :

Annotation 1

osm|traffic_sign=FR:D21a
road_name=D906
direction=SW
destination_1=RAMBOUILLET
destination_2=CERNAY LA VILLE
distance_1=16
distance_2=4

Annotation 2

osm|traffic_sign=FR:D21a
road_name=D906
direction=NE
destination=CHEVREUSE
distance=3.5

N.B. : les décimales des distances doivent être indiquées avec le caractère “.” (point)

Si vous avez d’autres exemples, je suis preneur, pour prendre en compte toutes les exceptions possibles.

Première auto-critique de la méthode proposée : pour faire référence à un objet dans OSM, il faut indiquer osm=node/13495377364 en double, sur chacune des deux notifications … pénible, mais je pense qu’on devrait tout de même assumer cette différence de modélisation.

Aller, premier contre-exemple qui détruit toutes mes convictions précédentes :stuck_out_tongue: :

j’ai taggué

osm|traffic_sign=yes
overhead_sign=MASSIF FORESTIER DE RAMBOUILLET
inscription_1=AUTOMOBILISTES ATTENTION
inscription_2=RISQUES DE TRAVERSÉES DE GRANDS ANIMAUX
osm|destination:symbol=FR:A15b
  • aucune idée du type de panneau
  • le cartouche n’est pas le numéro de la route, donc je l’ai indiqué comme “overhead_sign”
  • l’inscription n’est ni une destination ni une distance, donc j’ai utilisé un “inscription” générique et implémenté

Aie aie aie, la bonne balance entre standardisation et prise en compte des exceptions risque d’être particulièrement compliquée …

Je m’en prends maintenant à ce pauvre panneau sens interdit détecté automatiquement et qui n’a rien demandé :

1. Agrandir le périmètre de l’annotation

En attendant qu’il soit possible d’agrandir le périmètre de l’annotation, je suis forcé de recréer une nouvelle annotation et de supprimer l’ancienne :

J’y ai recopié les tags originels :

detection_confidence[osm|traffic_sign=yes]=0.926
detection_model[osm|traffic_sign=yes]=SGBlur-yolo11s/0.1.0
osm|traffic_sign=yes

Je précise maintenant le type de panneau :

osm|traffic_sign=B1

Pour les panonceaux, je vois plusieurs possibilités :

Solution générique

Elle est strictement descriptive :

plate_1=SAUF VÉLOS
plate_2=SAUF BUS

Solution spécifique

Elle est plus directement utilisable :

exception_1=SAUF VÉLOS
exception_2=SAUF BUS

Solution algorithmisable

Elle est directement utilisable par une machine :

osm|bicycle=yes
osm|bus=yes

Évidemment, si le job est fait par un opérateur humain, il parait préférable de ne pas utiliser la solution générique.
Néanmoins, c’est peut-être la seule chose qu’un algo pourrait réaliser automatiquement. Et donc on va peut-être devoir y passer, au moins temporairement.

Quel est ton avis @cquest ?

Qu’il faut prendre du recul et ne pas partir d’un cas précis.

On a des panneaux, qui peuvent être complétés par des panonceaux.
On peut tagguer soit :

  • soit le modèle de panneau/panonceau (exemple B1+M9v pour une sens interdit sauf vélos),
  • soit le sens associé, mais sens qui est associé au filaire de voie, pas au panneau en lui même (oneway=yes + oneway:bicycle=no).

Je resterai sur la première possibilité, parce qu’on parle bien ici du panneau, pas de son effet sur des objets environnants. De plus, les modèles de classification sortent le type de panneau (B1, M9v).

Là où ça se complique c’est pour le “SAUF BUS”, car c’est un M9z avec du texte générique… le modèle de classification des panonceaux va sortir “M9v[SAUF BUS]” car c’est un des libellés que j’ai pu entraîner.

Ensuite se pose la question de comment lier panneau et panonceau et là, oui, je pense qu’on doit avoir une annotation plus large ou alors associer le panonceau détecté et classé à l’annotation du panneau.

Il faut aussi penser à cela dans un contexte plus international… ce que je suis en train d’explorer avec les Pays-Bas.

C’est une question clef pour moi.

Vu que tu es parti sur une catégorisation très franco-française des panneaux (qui garde évidemment tout son sens dans le contexte d’une détection automatisée), on trouve des panneaux “français” en dehors du territoire national.
En tant que tel, ce n’est pas un problème : affiner les modèles pour chaque pays au fur-et-à-mesure est la bonne voie à suivre.

Mais cela pose la question de la ré-utilisabilité des données.
J’ai fait une proposition pour faire cohabiter dans l’interface des tags génériques avec des tags spécifiques par pays : search option : semantic gallery & OSM id calling (#256) · Issues · Panoramax / Server / Website · GitLab et qui, je pense, (est la voie à suivre pour) règle(r) ce soucis en particulier.

Je crois qu’on est d’accord pour rester sur un tag le plus descriptif possible, au moins dans un premier temps (quitte à ajouter des tags complémentaires qui ajoutent des infos algorithmisables par la suite, en effet liées à un filaire externe).

Est-ce que tu peux documenter + donner un exemple de sémantique de panonceau mais aussi de cartouche tel que tes modèles les créent dans le wiki stp ?

J’ai simplement repris le consensus OSM pour les panneaux, qui consiste à mettre le pays en préfixe et le modèle de panneau avec les valeurs variables entre

Effectivement, la classification utilise un seul modèle, conçu pour les panneaux français et ne vérifie pas si les panneaux détectés sont en France ou ailleurs (peut être à ajouter).

Sur l’instance IGN on a en principe uniquement des panneaux en France
Sur l’instance OSM très majoritairement en France…
Sur les autres instance, la classification n’est pas faite.

Je vois avec les pays-bas qu’au delà des panneaux très similaires d’un pays à l’autre, il y a une multitude de petites différences à prendre aussi en compte et du coup faire du générique est forcément quelque part réducteur.

Exemple de différence FR/NL:

Je pense qu’ils indiquent la même chose mais avec des logiques différentes (pas la même culture vélo).

Donc ce qui est sûrement plus exploitable c’est une table de conversion d’un modèle de panneaux vers sa signification, puis ce que ça implique ensuite sur le filaire de voie à proximité qui ici donnerait quelque chose comme oneway=yes + oneway:bicycle=no comme je l’indiquais plus haut.

D’une manière générale il ne faut pas réinventer la roue :wink:
Il existe déjà un standard de facto dans OSM pour la description de ce type d’itinéraires.

Vous en parlez juste au dessus :grinning_face:

OSM ne sait pas bien gérer les valeurs multiples et est limité dans la longueurs des valeurs/ On est donc tenté d’utiliser des tags suffixés comme destination_1, destination_2

Heureusement ce n’est pas le cas de Panoramax.
On peut donc avoir ceci :

destination=RAMBOUILLET
distance=16
destination=CERNAY LA VILLE
distance=4

Je propose de repartir du Wiki qui traite le sujet de manière globale : Key:destination — OpenStreetMap Wiki

Quel est l’usage ?

  • Si le libellé doit être utilisable par une synthèse vocale ou pour afficher une liste “propre” des destinations, on doit mettre le le “vrai” libellé de la destination (et si besoin, ajouter le fac-similé du panneau).
  • Si c’est pour montrer ce qu’il y a sur la photo ?
    … Il suffit de la regarder :wink:

Il me semblait que ce point était traité mais j’ai un doute (cf. discussion Abbreviations on signs).

Voir aussi :

Sauf qu’on ne sait pas qui est à 16 et à 4km…

Je pense qu’on s’enfonce juste dans des détails sans fin dont je ne saisit pas l’intérêt.

Si l’API respecte l’ordre des “tags”, ça correspond à des tableaux en JSON
L"index fait le lien.

On peut garder la syntaxe OSM actuelle :

destination=RAMBOUILLET;CERNAY LA VILLE
destination:distance=16;4

Elle est très utilisée pour décrire les poteaux directionnels en randonnée.

Par exemple Près la Beaume dans le Parc national des Écrins :

Je ne sais pas pour les panneaux routiers :sweat_smile:

Par contre pour la randonnée pédestre, détailler les destinations est très utile pour vérifier la cartographie des itinéraires dans OSM, préparer une rando…

Malheureusement on est limité pour le faire dans OSM (pas de réelle gestion des valeurs multiples, limitation des longueurs de clés à 255 caratères).

Il n’y a absolument rien pour garantir l’ordre des tags dans Panoramax et si c’est un tags “OSM”, il est préférables d’avoir la même logique avec des valeurs multiples.

Tu préconiserais d’utiliser les valeurs multiples ?
Je ne suis pas sûr de bien comprendre.

Je parle de ça:

osm|destination=RAMBOUILLET;CERNAY LA VILLE
osm|destination:distance=16;4

plutôt que

osm|destination=RAMBOUILLET
osm|distance=16
osm|destination=CERNAY LA VILLE
osm|distance=4
1 Like

J’espérais éviter les valeurs multiples dans des cas complexes comme le poteau ci-dessus :

destination=Sous le Queyrelet;Sommet du Queyrelet;Lac de Jujal|Via Naouva;Forest des Estaris;Orcières Merlette|Le Balet;Prapic
destination:distance=0.5;1.2;1.1|0.6;0.9;3.0|1.6;5.4
destination:duration=0:15;0:25;0:30|0:10;0:15;0:45|0:25;1:20

Mais dans Panoramax Florian propose d’utiliser une annotation par lame directionnelle. On aurait donc 3 annotations :

osm|destination=Sous le Queyrelet;Sommet du Queyrelet;Lac de Jujal
osm|destination:distance=0.5;1.2;1.1
osm|destination:duration=0:15;0:25;0:30
osm|destination:arrow=left

osm|destination=Via Naouva;Forest des Estaris;Orcières Merlette
osm|destination:distance=0.6;0.9;3.0
osm|destination:duration=0:10;0:15;0:45
osm|destination:arrow=right

osm|destination=Le Balet;Prapic
osm|destination:distance=1.6;5.4
osm|destination:duration=0:25;1:20
osm|destination:arrow=right

Voici concrètement le résultat :

Merci @pyrog de relancer le sujet, je pense que les décisions que l’on prend sur le sujet seront très structurantes pour tous les choix futurs du tagging dans Panoramax.

Je constate qu’il n’y a pas de système parfait, donc pour récapituler, il faut choisir entre 3 systèmes concurrents :

1. Tags à clefs dupliquées

Exemple :

destination=RAMBOUILLET
distance=16
destination=CERNAY LA VILLE
distance=4

2. Tags à valeurs multiples

Exemple :

destination=RAMBOUILLET;CERNAY LA VILLE
distance=16;4

3. Tags multiples incrémentés

Exemple :

destination_1=RAMBOUILLET
distance_1=16
destination_2=CERNAY LA VILLE
distance_2=4

Mon avis

  • Le système 1 me paraît à éviter absolument tant le risque d’ambiguïté parait grand concernant le lien entre la destination et ses tags complémentaires (distance, temps de parcours …)
  • Les systèmes 2 et 3 corrigent ce défaut et sont donc des prétendants sérieux.
  • Le système 3 a ma préférence pour deux raisons :
    • il permet une exploitation directe, sans retraitement, par un ordinateur
    • il est plus lisible et donc moins sujets à création d’erreurs pour un humain

Je suis curieux d’avoir votre avis et celui d’autres personnes également (ping @PanierAvide @flacombe @antoine-de)

Tu préfixes bien ces tags avec osm| ?

Si oui, c’est côté OSM que tout ceci est définit (et à discuter) car il ne faudrait pas s’en éloigner pour conserver une interopérabilité, tout comme tout ce qui est préfixé wd| doit être conforme aux pratiques côté wikidata, sinon on va créer un bazar monstre.

1 Like

La solution “1 annotation par panneau physique” + les tags avec ; pour garder l’ordre logique me semble appropriée

osm|destination=Sous le Queyrelet;Sommet du Queyrelet;Lac de Jujal
osm|destination:arrow=left
osm|destination:distance=0.5;1.2;1.1
osm|destination:duration=0:15;0:25;0:30

Oui, car en plus il ne fonctionne pas dans les cas où il manque des valeurs comme pour ce poteau :

destination = Table d'Orientation;Croix des Salles;Plan des Crêtes;La Jorasse
destination:arrow = left
destination:distance = 0.150;;;
destination:duration = ;0:25;0:40;0:50

En plus des arguments de @cquest on réinvente une rimbambelle de tags qu’il faudrait documenter sans fin.

C’est en fait la solution 2 :rofl:
Mais contrairement à OSM où l’on détaille toutes les lames directionnelles d’un poteau, on ne détaille qu’une seule lame à la fois (donc on se passe du séparateur | ce qui simplifie la lecture et la saisie).

Par contre comment indiquer que plusieurs lames correspondent à 1 même objet OSM (1 poteau en randonnée, un portique sur des voies d’autoroutes…) ?

  1. On met une grande annotation qui recouvre les annotations détaillées ?
    Avec l’id de l’objet osm et son “preset” correspondant ?

  2. On met en plus l’id de l’objet dans chaque annotation détaillée ?

  3. Comme 2 avec en plus le “preset” ?

Je tâtonne aussi pour celui-ci qui semble tout bête :

.

J’aillais utiliser traffic_sign=FR:D21a[Sentier Découverte de Maincourt] mais les panneaux D21a peuvent avoir des couleurs différentes, des distances, des logos (cf. Wikipedia).

La solution serait :

traffic_sign=FR:D21a
destination=Sentier Découverte de Maincourt
destination:symbol=PNR_Chevreuse

(Pour le symbol j’ai inventé une valeur au pif, il faudrait creuser plus)