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.