FR:Créer un attribut qui manque

Note : un grand nombre d'éléments cartographiques se trouve déjà dans la page Éléments cartographiques (Map Features) et il est recommandé d'utiliser les attributs déjà documentés, sinon d'autres contributeurs vont peut-être convertir vos contributions.

Documenter les attributs qui n'existent pas dans les Éléments cartographiques

Vous avez suivi les Bonnes pratiques et recherché dans le Wiki, les Éléments cartographiques, les Propositions rejetées, les Relations proposées et les archives des listes de discussion et vous ne parvenez toujours pas à trouver l'attribut que vous voudriez ajouter à la carte? Taginfo est probablement la ressource la plus utilise pour suggérer des attributs. Le service liste les attributs déjà existants dans la base, et indique le volume de leur utilisation. Il liste également le attributs qui sont utilisés en combinaison de n'importe quel attribut d'un objet.

Gardez à l'esprit qu'OpenStreetMap n'impose pas de restrictions sur le contenu des attributs qui peuvent être assignés à des nœuds, des chemins ou des surfaces. Vous pouvez utiliser n'importe quel attribut, mais SVP documentez-les ici sur le wiki OpenStreetMap, même si ces attributs semblent explicites (voir le Processus de proposition)

Documenter permet aussi à d'autres contributeurs OSM de trouver vos éléments cartographiques ou même de corriger des erreurs à proximité.

Documenter est particulièrement utile pour qu'ultérieurement, dans le cas où quelqu'un proposerait des attributs pour un sur-ensemble de l'élément cartographique que vous êtes en train d'ajouter, vos expériences et objets puissent être intégrés dans ce processus de proposition. Par la suite ils pourraient même être convertis dans ce nouveau modèle, s'il est adopté par la communauté.

Choisir les attributs à utiliser Par exemple, si vous désiriez cartographier tous les nids d'Écureuil volant sur Wikipédia, vous créeriez juste une page endangered_nest=Siberian_flying_squirrel et vous documenteriez sur cette page à quoi sert cet attribut. Soyez seulement prêt à ce qu'un jour, quelqu'un d'autre propose un modèle différent et plus structuré pour documenter d'autres aspects des espèces animales en danger et que vos anciennes éditions soient finalement converties dans ce nouveau modèle.

Vous pouvez consulter par exemple les Standards IOF pour les standards de classification utilisés dans les cartes d'orientation, pour se rendre compte s'ils peuvent être utiles et si votre nouvel attribut serait compatible avec les besoins de ses utilisateurs. D'autres documents comparables existent probablement.

Quand créer une proposition

Vous devriez créer une page de proposition pour votre élément cartographique, si :

1. Votre élément est d'intérêt général, ou
2. Vous n'êtes pas certain de la bonne manière de le modéliser, ou
3. La dernière proposition d'attribut pour cet élément a été rejetée, ou
4. Vous voulez changer la signification d'un attribut déjà existant

(Notez bien que créer une proposition n'est pas une obligation pour que votre élément cartographique apparaisse sur la carte principale, de même qu'une proposition qui a été adoptée ne signifie pas que votre élément figurera sur la carte principale. Cependant, si votre élément cartographique a passé toutes les étapes du processus de proposition pour être finalement adopté par une majorité, beaucoup plus de personnes souhaiteront le voir apparaître et par conséquent le voir présent sur les principaux rendus.)

Ce qu'il ne faut pas cartographier

Les éléments dans la base OpenStreetMap doivent avoir un caractère géographique ou dépendre d'un objet géographique.

Par exemple, ajouter l'emplacement de hotspots Wifi est accepté, mais ajouter des nœuds tout autour avec des attributs indiquant le signal perçu n'est pas souhaité. Ce type d'information doit être stocké dans une base à part.

Il est nécessaire de tenir compte du consensus communautaire de la page des Bonnes pratiques en ce qui concerne la Vérifiabilité. Ne cartographiez pas des objets historiques, temporaires ou hypothétiques, des données d'opinion ou de législation.

Mode d’emploi pour les nouvelles clés/attributs/propriétés

Cette section vise à résumer les conventions existantes utilisées par les contributeurs qui inventent de nouveaux attributs, en fonction des attributs déjà existants dans les Éléments cartographiques et les propositions récentes. Corrections et ajouts d'autres usages généralisés qui pourraient manquer sont bienvenus !

Un attribut (tag en anglais) est une paire de chaîne de texte numérique Unicode (clé, valeur), souvent écrites sous la forme clé=valeur dans les discussions.

En fonction de l'existence ou non d'une catégorie déjà définie qui corresponde à votre besoin, vous allez peut-être créer une nouvelle clé, une nouvelle valeur pour une clé existante, une nouvelle propriété modifiant une ou plusieurs combinaisons de clés/valeurs ou une autre forme de raffinement.

En cas de doute par rapport au choix de définir quelque chose complètement nouveau plutôt que d'utiliser des combinaisons existantes avec de nouvelles propriétés ou des raffinements, il faut toujours garder en tête que les nouvelles propriétés ne devraient pas modifier des éléments cartographiques établis au point d’altérer la compréhension naturelle que tout le monde en a.

Conventions syntaxiques pour de nouvelles clés

Les chaînes de texte utilisées pour les clés obéissent à certaines conventions :

• idéalement, une clé est composée d’un seul mot en minuscules
• quand cela n’est pas possible, la clé devrait être un concept dont les mots sont séparés par des tirets bas _. Cela évite les problèmes liés aux espaces, et provient des développeurs au sein de la communauté OSM, qui aiment généralement ce type de syntaxe.
• certaines clés complexes sont construites avec plusieurs mots ou concepts séparés par des doubles points. Elles doivent pouvoir être lues naturellement de gauche à droite. Un certain nombre de modèles est déjà largement utilisé :
  1. un simple espace de nom comme préfixe, dans un style similaire à celui utilisé dans certains langages de programmation. Il rassemble de manière libre des informations sans entrer en conflit avec d’autres attributs OSM. Cette pratique est notamment utilisée pour les imports de données dans OSM.
     • tiger:county=*, tiger:upload_uuid=* sont tous deux liés aux imports de données US TIGER
     • KSJ2:lat=*, KSJ2:curve_id=* sont des attributs qui proviennent de l’import Japan KSJ2
  2. des ensembles d’informations fortement corrélées qui réunies expriment un fait unique ou une propriété. Cette convention syntaxique est très adaptée pour l’adressage ou pour des modèles de nommage inhabituels.
     • name:left=*, name:right=* pour des rues avec des noms différents de chaque côté
     • addr:housenumber=*, addr:street=* sont tous reliés à l’adressage
  3. Qualifications par code de langue. Voir Names#Localization
     • name:en=*, name:cy=* pour les noms en anglais et en gallois pour un élément
     • note:ja=* pour une note spécifiquement en japonais
  4. Peu couramment utilisé, se rapproche du modèle 2 et s’apparente à du méta-attribut (information sur les attributs)
     • source:name=* est la source pour l’attribut name
     • source:ref=* est la source source pour l’attribut ref

• Il existe une pratique de raffinement itératif en usage dans beaucoup de modèles d’attributs, qui offre l’avantage de pouvoir croître avec le temps pour entrer de plus en plus dans le détail, et en même temps de pouvoir être rétrocompatible. Par exemple :

highway=crossing

crossing=uncontrolled

Conventions syntaxiques pour de nouvelles valeurs

Le format et les conventions diffèrent selon que l’attribut définisse un élément ou une propriété.

• Un attribut peut définir soit un élément caractéristique (feature en anglais, comme par exemple highway) ou une propriété d’un élément (tel que width).

• Les Propriétés peuvent avoir un plus grand nombre de valeurs possibles ou peuvent être une information numérique quantitative (par exemple width=2).
  • Les Noms sont un exemple de valeur d’une propriété (par exemple l’attribut name=*), et ces valeurs sont flexibles et non structurées, contenant souvent majuscules et minuscules, espaces et autres caractères spéciaux.

• Les Éléments caractéristiques contiennent souvent des valeurs qui affinent la catégorie de l’élément cartographique dont elles dépendent (par exemple highway=motorway).
  • Pour les attributs d’éléments caractéristiques, la valeur suit des conventions de format similaires à celles des clés :
  • Idéalement, la valeur de l’attribut d’un élément caractéristique tient en un mot, en minuscules.
  • quand cela ne peut être le cas, la valeur de l’attribut d’un élément caractéristique devrait représenter un concept, dont les mots sont séparés par des tirets bas _.

• Parfois le point virgule ";" est interprété comme un séparateur de multi-valeurs - voir Semi-colon value separator.

Caractères

N’importe quel caractère Unicode (UTF-8) peut être utilisé. Dans la pratique, la majorité des clés (telle que highway) et les valeurs de classification (comme trunk_link) utilisent des caractères en minuscules, tiret bas et double point. Il est préférable d’éviter les caractères qui causent des problèmes dans les chaînes de caractères pour un grand nombre de logiciels :

• Espaces en blanc Il faut utiliser des tirets bas '_' à la place d’espaces en blanc, et éviter les espaces en blanc au début et à la fin de clés.
• <>&/+?#%'"\ Il faut éviter les caractères spéciaux pour les langages XML, HTML ou les URL ou utilisés pour les citations.
• = Il faut éviter également le signe égal, dans la mesure où il est utilisé comme caractère de séparation entre la clé et la valeur de l’attribut
• ; L’usage du point virgule fait toujours l’objet d’avis contrastés (voir les recommandations à ce sujet dans les bonnes pratiques).

Pour les valeurs de forme libre (par exemple, comme celles de la clé name), n’importe quel caractère peut être utilisé. Les noms sur une carte font cependant l’objet de conventions cartographiques concernant les majuscules et minuscules (voir Majuscules, minuscules et traits d’union pour les toponymes).

Guide de style ?

Les indications ci-dessus peuvent être considérées comme un guide de style, mais ne le sont pas. Au final, l’interprétation dépend de l’utilisateur et le seul principe à réellement appliquer est le principe KISS soit « faire au plus simple pour que cela fonctionne». Plus un attribut est clair et simple, meilleures sont les chances qu’il soit adopté par d’autres.

Voir aussi

• Just Map
• Bonnes pratiques
• Comment inventer des attributs(en) par Jochen Topf