FR:Import/Guidelines
Ces directives visent à aider les personnes qui s'intéressent à l'import de données vers la base de données OpenStreetMap. Peu de règles sont strictes mais elles devraient vous aider à débuter. Bien sûr, tout ceci est ouvert à la discussion, de même que sur la liste de diffusion des imports et cette page de discussion.
Notez que cette version française est la traduction d'une ancienne version anglaise, et qu'entre temps, la version anglaise à plusieurs fois évolué, la version anglaise précise plus clairement les points qui doivent être suivis lors d'un import. Si vous lisez l'anglais, vous pouvez lire la version anglaise plus à jour. (Celle-ci n'étant pas, fin 2013, obsolète non plus).
Une liste de contrôle
Vous pensez que les services de votre ville, département, région ou pays ou un organisme, qu'il soit à but non lucratif ou non, ont de nombreuses données qui pourraient améliorer la qualité d'OpenStreetMap. Voici une brève liste de contrôle pour vous aider à débuter de la bonne manière. La plupart de ces domaines sont approfondis dans les paragraphes suivants et les pages liées. Les premières étapes ne sont pas très techniques et toute personne motivée peut s'engager dans la démarche. Toutefois, des compétences techniques et une bonne connaissance d'OSM sont nécessaires par la suite.
- Se familiariser avec les bases d'OpenStreetMap, y compris l'édition, comme par exemple par l'ajout de détails de votre quartier. Consulter le guide du débutant.
- Contacter la communauté OSM locale pour être sûr que vous ne vous engagez pas dans une démarche que quelqu'un a déjà tenté et pour savoir dans quelle mesure la communauté est ouverte aux imports. Vérifier l'existence d'un éventuel groupe local de contributeurs, user groups, local chapters, and country-specific mailing lists.
- Vérifier la licence des données. Si la licence n'est pas compatible avec la licence d'OpenStreetMap, vous ne pouvez pas utiliser ces données.
- Déterminer quelles couches de données sont proposées par l'organisme. Cela peut être un linéaire de voiries, des contours de bâtiments, des cours d'eau, des adresses, etc...
- Discuter avec la communauté de l'utilité de chaque couche pour l'import. Certaines données s'importent en l'état sans trop de difficultés alors que d'autres sont bien plus difficiles à traiter (par exemple le tracé de voies). De même, certaines sont couramment acceptées pour l'import alors que d'autres ne recueillent que peu de consensus (par exemple, les limites de parcelles).
- Développer avec la communauté un processus pour convertir les données au format XML d'OSM. Il inclut la définition de la manière de traduire les attributs des données en attributs d'OSM et la manière de convertir proprement la géométrie en incluant les nettoyages de données et les simplifications qui paraissent nécessaires.
- Développer avec la communauté un processus pour fusionner les données converties avec OSM. Cela peut comprendre la constitution de lots de données gérables et l'utilisation du wiki ou d'autres solutions pour attribuer des lots à des contributeurs.
- Développer avec la communauté un processus d'assurance qualité.
Créer une communauté
OpenStreetMap est entièrement consacré à construire une grande carte en rassemblant une large communauté de cartographes. Bien que l'import de données puisse aider à améliorer rapidement la couverture, des simulations suggèrent que les données importées peuvent nuire à la croissance d'une communauté. Il est véritablement beaucoup plus important de sortir et d'organiser de nombreuses cartoparties, d'y diffuser de la publicité pour OSM, et d'amener des gens sur le terrain.
- Note (user:Pieren) : Cette section est la traduction de la version anglaise. Cette dernière est rédigée par ceux qui souhaitent décourager les imports en général. Son contenu est très contesté par ceux qui pensent que les imports ne peuvent nuire au participatif. Simplement, c'est le profil des contributeurs qui peut changer suite à import (ceux qui préfèrent partir de rien plutôt que de corriger l'existant passeront leur chemin).
- Note (sly) : +1 sur l'avis de Pieren. De plus, l'annonce d'une simulation en 2009 c'est bien, mais j'ai réalisé une mesure sur les années 2006 à 2012 [1] de l'évolution en nombre de kilomètre des routes et chemins en France. Peut être discutable sur la méthode mais cela montre que le début des importations du cadastre de bâtiments et toponyme (utilisation principale) n'ont pas réduit les contributions de la communauté française sur les routes, bien au contraire. Tous les imports ne nuisent donc pas forcément à la communauté locale, parfois même au contraire
S'assurer que la licence est compatible
Nous sommes uniquement intéressés par des données libres. Nous devons être capable de publier ces données avec notre licence OpenStreetMap. De toute évidence, nous sommes autorisés à utiliser des sources de données du domaine public. Il y en a un certain nombre. Pour les autres, c'est plus compliqué.
OpenStreetMap a migré vers la licence ODbL en septembre 2012. Vos données doivent être compatibles avec cette licence. De plus, vous devez être capable d'accepter termes de la licence pour votre compte d'import, ce qui comprend des dispositions pour passer sous une autre licence libre et ouverte si la communauté le souhaite.
Vous ne devez pas exiger de copyright supplémentaire pour vous-même en tant qu'importateur. Par exemple, si vous importez des données du domaine public, vous ne devez pas chercher à restreindre l'utilisation de vos données importées. Votre compte d'import ne doit pas refuser les autorisations qui ont été données par les créateurs originaux des données que vous importez.
Veuillez noter en détail l'exigence d'attribution. Nous pouvons offrir quelques attributions : nous pouvons mentionner leur crédit sur notre site web (pas sur la page d'accueil, mais dans la page des contributeurs de notre wiki, et sur la page www.openstreetmap.org/copyright pour des contributions à grande échelle). Nous pouvons renvoyer vers des informations sur eux en relation avec le compte utilisé pour réaliser l'import, sachant que l'historique des éditions va permettre à tout un chacun de remonter à la source du don de données. Nous pouvons aussi mettre leur nom en valeur du tag source sur les données sous-jacentes. Ceci est peut être plus marquant mais peut être retiré par des éditeurs réalisant des travaux de cartographie par la suite. Le crédit à l'auteur s'arrête là. Ce que nous ne pouvons certainement pas faire, c'est d'exiger des utilisateurs finaux de nos données ou des rendus réalisés qu'ils mentionnent le crédit de donateurs particuliers.
Ayez à l'esprit que notre attribution peut ne pas être suffisante d'un point de vue juridique et pourrait être considérée comme non satisfaisante par les auteurs des données d'origine.
Souvent, nous découvrons que des données prétendument disponibles sous une licence compatible se révèlent finalement dérivées de sources que nous considérons comme non libres. Par exemple, bien que certaines données géographiques soient disponibles dans Wikipedia sous une licence Creative Commons, il est largement admis dans OSM que certaines données sont simplement dérivées de Google Maps et, pour cette raison, pas vraiment conforme à la license mentionnée. Dans de tels cas, il y a une norme établie par la communauté de ne pas importer de données dont la provenance est incertaine, indépendamment de la license indiquée. Mieux vaut prévenir que guérir.
Discuter de l'import avec la communauté
Il est important de discuter de l'import proposé avec la communauté à chaque étape. Avant tout, ajoutez une entrée aux Sources de données potentielles. Vous pouvez y décrire brièvement ce que vous avez déterminé à propos de la license des données et la pertinence des données par rapport à celles que nous avons déjà. Si vous avez besoin de plus d'espace, créez une page spécifique dans le wiki et ajoutez un lien vers cette page.
Discuter de votre import sur la liste de diffusion imports@openstreetmap.org mailing list et avec les communautés locales appropriées. De nombreuses communautés locales ont leur propres [Mapping projects|pages du wiki]] et/ou une liste de diffusion. Assurez la coordination avec les personnes ayant des projets similaires.
Même si un projet identique ou similaire a été discuté précédemment, vous devriez tout de même en discuter avec la communauté locale. Cela signifie que la communauté est au courant de votre projet et peut soulever des questions ou émettre des objections pour éviter des dommages. C'est vrai en particulier si les données étaient disponibles depuis longtemps et n'ont pas été importées : une telle situation ne signifie pas qu'il est acceptable de se lancer sans discussion préalable avec la communauté locale.
Discutez toujours de vos investigations concernant la licence et la pertinence des données. Si le consensus aboutit à ce que les données ne répondent pas à nos critères, ne soyez pas déçu. Qualifiez le projet de rejeté sur la page des sources de données potentielles et donner les raisons. Documenter une telle décision est une contribution utile en soi. Si on aboutit à un consensus satisfaisant pour la communauté, passez à la discussion sur la mise en oeuvre de scripts d'import, etc...
Documentez votre import sur le wiki
Si vous vous engagez dans votre import, veuillez créer une page dédiée sur le wiki, avec tous les détails. Créez une entrée sur le catalogue des imports et mettez le lien vers votre page. Placez également le lien sur les pages des projets locaux de cartographie.
Cette page devrait avoir le contenu suivant :
- Pertinence de la source de données et licence (également mentionnés sur Sources de données potentielles)
- Import et logiciels que vous prévoyez d'utiliser. Partagez le code source que vous utilisez.
- Précisez la manière dont les données seront transposées d'un autre format vers le format OSM
- De quoi auront l'air les données résultantes, les tags exactes utilisés.
- Lien vers un échantillon de données importés sur la base de données de test.
- Nom du compte utilisateur exécutant l'import et autres détails sur la manière dont le groupe de modifications (changeset) sera commenté.
Et quand l'import est en cours :
- Lien vers un exemple de données importées dans la base réelle.
Utiliser un compte dédié à l'import
Créez un nouvel utilisateur pour l'import. Vous ne devez pas utiliser votre propre compte d'utilisateur OSM. La page du compte d'import doit être utilisée pour compiler des informations relatives à la source et aux détails du contact pour l'import. De plus, cela signifie que l'attribution peut souvent être portée dans le nom affiché pour le compte ou dans la page associée au compte? C'est mieux que de le mettre sous forme de tag étant donné que l'historique des éditions est un enregistrement permanent de la source qui n'interfère pas avec les tags et que cela n'augmente pas autant la taille de la base de données. Pour ces raisons, créer un compte dédié est préférable à l'utilisation du tag source=*.
Définissez vos propres préfixes de tag
Vous avez probablement quelques métadonnées telles que des identifiants figurant dans les données d'origine. Définissez vos propres préfixes et utilisez les pour toutes ces données. Par exemple, l'import TIGER utilise le préfixe "tiger:". L'identifiant d'origine d'un objet TIGER est taggé en "tiger:tlid".
N'exagérez pas avec les métadonnées. Votre source de données peut avoir de nombreux champs mais les données OSM avec de nombreux tags peuvent se révéler difficiles à manipuler. Trouvez un équilibre. Déterminez (discutez!) quels champs intéressent la communauté OSM.
Gardez à l'esprit les ressources des serveurs
Assurez-vous de ne pas surcharger le serveur lors de l'import de grandes quantités de données. L'import TIGER a du être étalé sur plusieurs mois pour ne pas saturer le serveur central ! Importez les données par petits lots de données ou ralentissez vos scripts d'import. Dans le doute, parlez-en à l'administrateur système.
Évitez des dégâts dans les données !
Ce devrait véritablement aller sans dire, mais ne faites pas de dégâts dans les données d'OpenStreetMap ! Pensez toujours aux contributeurs ordinaires qui travaillent à l'aide de iD et ne présumez jamais que ces personnes seraient heureuses de réparer vos dégâts. Si vous n'avez pas vous-même d'expérience avec iD, vous ne devriez pas effectuer d'import. JOSM est un peu plus performant pour réparer des dégâts mais cela reste laborieux. En tous cas, la plupart des utilisateurs, en particulier les nouveaux utilisateurs, utilisent iD. Vos données vont-elles gâcher leurs travaux d'édition dans OpenStreetMap ? Si oui, nous n'en voulons pas.
N'ignorez pas les données existantes et n'importez pas de nouvelles données par dessus. Généralement, ajouter des données aux données existantes est une mauvaise idée (voir les notes ci-dessous), mais vous devez aussi vous rappeler que les données existantes peuvent être des données dont se préoccupe un utilisateur réel et qu'il les tient à jour.
Vous pouvez essayer de distinguer ces cas à l'aide de méthodes automatisées ou semi-automatisées et traiter l'existant en conséquence. Par exemple, pour des zones dans lesquelles des utilisateurs réels travaillent, vous pouvez décider de laisser les données existantes en l'état.
Si un import part de travers, ou si vous avez eu besoin d'interrompre un téléversement (upload), cela doit être corrigé immédiatement en revenant à la situation antérieure. S'il y a besoin d'aide, contactez Imports. Mais l'import n'ira pas de travers parce que vous l'avez testé scrupuleusement sur la base de données de test, n'est-ce pas ?
Si vous ne savez pas comment revenir sur un import, ne faites pas l'import !
Directives particulières pour les données
N'ajoutez pas de données sur les données existantes
Contrairement aux systèmes SIG traditionnels, OpenStreetMap n'a pas de notion de couche. Superposer des données est un gâchis. C'est un type de gâchis qui rend le travail des utilisateurs extrêmement difficile avec les éditeurs normaux d'OpenStreetMap. La carte des nœuds dupliqués montre des imports qui n'ont pas suivi ces directives. (Des importateurs de TIGER ont causé cela, mais il y a malheureusement beaucoup d'autres imports plus récents qui ont raté).
Si vos données se présentent sous forme de couches au format GIS, vous allez devoir adopter une approche différente. Peut être fusionner les couches et calculer les meilleurs tags d'aggrégat, mais vous pouvez toujours éviter l'import direct et, à la place, créer une source destinée à l'import manuel sélectif par des utilisateurs, ou un calque WMS pour digitaliser (comme pour Natural Resources Canada - Toporama.
Pensez à simplifier
Les fichiers de formes (Shapefiles) comportent souvent trop de détails, c'est-à-dire plus de nœuds que nécessaire pour représenter des courbes, ou plus de deux nœuds pour représenter une ligne parfaitement droite. Vous le verrez en particulier sur des zones étendues qui présentent des nœuds éloignés de quelques mètres ou paraissent crénelées parce que la résolution est trop ou pas assez fine. Des outils comme Map Shaper permettent de simplifier les formes qui sont trop détaillées. Rappelez vous la manière dont la donnée est représentée et peut être travaillée dans Potlatch.