Débat sur l'emploi des tags pour enrichir la description d'un objet

Bonjour, je publie ici des échanges sur Twitter entre @ZIMMY @tony.emery @InfosReseaux @jmfavreau au sujet de l’emploi de tags pour enrichir la description d’un objet.

Le point de départ https://twitter.com/JLZIMMERMANN/status/1526537820533293056 puis https://twitter.com/tonyemery/status/1526794945000050688

Ces échanges sont intéressants et méritent à mon sens d’être partagés…

2 Likes

Merci d’avoir relayé ça ici, grosse discussion en effet.

A noter que je ne me prononce pas en faveur de l’une ou l’autre des méthodes. Chacun emploi l’échelle qu’il souhaite.
Mes objections ne concernent que la situation où on les utilise simultanément sur les mêmes objets du terrain.

1 Like

L’intérêt de cette discussion est de mettre sur la place publique les réflexions, les diversités de point de vue de la communauté OSM. Bon faut quand même suivre les différents comptes ou suivre les tags mais c’est une démarche d’ouverture à encourager.
Bon faut pas que je mette les mains dans cet engrenage sauf nécessité absolue sinon c’est carnage au niveau productivité boulot.

1 Like

qqun se sent de faire un résumé de la discussion ici sur le forum ?
Parce que pour quelqu’un qui n’est pas habitué à lire du Twitter, je vois juste un débat sur « l"arbre doit-il être décrit une fois, l’autre fois, ou les deux ».

Ajd qd on a un restaurant avec une terrasse, on mappe la terrasse, et sur le restaurant on ajoute outdoor_sitting=yes.

1 Like

En une phrase : faut-il indiquer qu’une rue est éclairée sachant que les lampadaires sont cartographiés individuellement à proximité ?
Vous avez 4 heures.

Moi, je penche pour une relation.
Ok, je sors…

ce qui compte c’est que la rue soit éclairée. Donc en priorité l’attribut sur la highway, et ensuite en bonus, ajouter le lampadaire.

Y a-t-il des cas avérés où le fait que l’information soit en deux endroits pose des problèmes ?
Je me réponds à moi-même : il y a le problème des parking lots, avec un attribut qui indique le nombre de place handicapées, sachant qu’il est aussi possible de les mapper inviduellement sous forme de Node.
Si on le fait aux deux endroits, on se retrouve avec deux fois trop de places handicapées ce qui peut être problématique.

Pour des arbres ou des lampadaires, cela me semble être un non-problème.

Le problème est que non seulement il y a plusieurs manières de décrire une même réalité ou une même caractéristique, mais si on ajoute au-dessus de la redondance d’information, on ne facilité pas la réutilisation.
Si on abaisse la marche de la contribution (chacun fait un peu comme il le sent et surtout dans son coin), on la réhausse pour les ré-utilisateurs.
Sans viser une base de données où aucun attribut de doit pas dépasser la taille prévue par la modélisation, il parait quand même raisonnable de chercher à décrire de manière substitutive (s’il y a des lampadaires, est-ce nécessaire d’indiquer que la rue est éclairée ?) que cumulative.
On est plus sur des principes de description que d’analyse de tel ou tel cas ou des conséquences potentielles dans certains cas d’usage.

1 Like

J’ai tiqué aussi sur le tree=yes qui n’est documenté sûrement nulle part (j’ai pas cherché).

Je ne vois pas trop le rapport direct entre banc et arbre.

Pour double mapping (objet et effet de l’objet), ça peut être vu comme une complication pour les réutilisateurs mais ça peut aussi être une simplification.

Pour la terrasse de resto/bar, outdoor_seating=* existe depuis plus longtemps que leisure=outdoor_seating.

On a mis des oneway=yes, avant de mapper les panneaux par eux même… si on devait s’appuyer sur les panneaux pour déterminer que les tronçons de voirire sont à sens unique, il faudrait faire soit des analyses géométriques bien compexes, soit créer des relations pour savoir que le panneau s’applique à tel way (et dans tel sens). Pareil pour tous les panneaux routiers… quel bazar ce serait !

lit=yes sur la voie (ou un autre objet) est plus simple d’utilisation que de vérifier la présence de lampadaire à proximité d’un objet qui est un niveau de détail de plus.

Je ne vois pas ça comme une redondance, on décrit l’effet de l’objet séparément de l’objet (qui est bien plus rarement cartographié).

L’un ou l’autre ET les deux. En tout cas si quelqu’un veut utiliser les données d’Openstreetmap pour savoir si une rue est éclairée, c’est comme ça qu’il doit s’attendre à trouver l’information.

Voilà l’un mentionne (résumé) et l’autre décrit (complétude).

Je propose une mise en perspective semantique :

  • à la redondance je propose la récursivité

Le principe est de permettre un miroir contextuel des tags; un objet peut préciser une réalité périphérique et l’autre qui est mentionné être porteur de la complétude.
Le cas du restaurant et la terrasse est un bon exemple.

1 Like

A condition que ces pratiques soient documentées de manière aussi détaillées que possible.

2 Likes

Et à la condition qu’il y ait bien un effet direct et logique entre les deux objets.

Je le vois sur le lampadaire et le lit=yes, sur les panneaux routiers et leurs effets sur la voirie, sur le resto et sa terrasse, mais pas vraiment entre le banc et l’arbre.

Il y a un principe à définir ici pour fixer une limite et éviter d’ajouter des tags pour ajouter des tags.

Tel n’est pas le cas pour les arbres-bancs.
II s’agit de pertinences liées aux ilots de chaleur (thème d’actualité), cela va être nécessaire de permettre de trouver les aménagements qualitatifs dans les villes.
Search: arbre-banc | Flickr

Et là… arbre-banc, parc commercial Orange les vignes (ORANGE,FR84… | Flickr

Arbre-banc-fontaine ?

On a toujours ce questionnement sur les objets combinés, comme avec le bar-tabac-épicerie-poste… (j’avais une épicerie+bricolage près de chez moi… un beau casse tête qui a fermé, ce qui résolu le problème de mapping).

Doit-on cartographier un arbre-banc comme un banc + un arbre ? L’un pouvant disparaître sans l’autre et n’ont de véritable lien que par leur proximité qui ici est juste recherchée/choisie. Rares sont les cas où le banc est en appui sur l’arbre… car ça le détériore.
Je suis plutôt favorable à ça, mapper les deux séparément.

Donc on revient au principe d’un contexte sémantique distribué.

Dans le cas d’un hôtel restaurant ce sont souvent deux entités et voire 2 SIRET.
Donc on a un hôtel + un restaurant et pour l’hôtel restaurant=yes .

Bonjour,

Pour ce cas très spécifique, serait-il opportun de regarder le résultat plutôt que la raison ?
un attribut covered=partial ou covered=sun permettrait de répondre spécifiquement à la cartographie de ces îlot de chaleur ?
Cela étant posé, je doute du côté vérifiabilité incontestable de cette information. Un peu comme la controverse à propos de l’attribut smoothness.

1 Like

Je n’ai pas tout compris du jargonnage mais je me dis qu’il faut éviter de céder à la mode. Certes, on cause beaucoup des îlots de chaleur mais on ne cartographie pas en fonction d’un seul sujet.
Concernant les arbres bancs, je suis favorable à les cartographier séparément car si on veut aller dans le détail de la description de l’arbre, en notant sa hauteur, son âge, sa circonférence, son caractère (dénotation) et bien entendu son espèce, le banc sera surtout une source de confusion.
Avec tree=yes , l’arbre est l’élément secondaire, c’est pas sympa pour l’arbre et surtout, il est plus structurant qu’un banc, c’est lui qui devrait être l’élément principal.

C’est la limite des conversations décorrélées du sujet initial : tout est parti d’un tweet qui avait vocation à encourager une finesse descriptive. https://twitter.com/ChallengeOsm/status/1526533003442278401?s=20&t=zyuRqCzaQv01Iv5iC5iEVQ

Le reste n’est pas de miser sur l’exclusivité d’un arbre ou d’un banc :slight_smile:
Ni non plus de croire que telle thématique est l’obsession du jour, il y a simplement des émergences liées à des qualités d’observations alimentées par des cultures différentes.