FR:Import/Logiciel

From OpenStreetMap Wiki
Jump to navigation Jump to search

Selon le format de vos données source, vous aurez besoin de logiciels pour la conversion vers le format OSM.


Processus

Ceci est un exemple de la manière dont l'import peut être effectué. Les imports individuels peuvent être différents.

  1. Voir les données source et déterminer la correspondance entre les attributs de la source et ceux utilisés dans OSM.
  2. Créez ou adapter des logiciels pour réaliser la correspondance entre les données sources et générer un ou plusieurs fichiers XML au format OSM. Utiliser des identifiants uniques négatifs pour créer des noeuds, des chemins ou des relations.
  3. Chargez le fichier XML dans JOSM et vérifier les données. Répéter les étapes 1 à 3 jusqu'à ce que tout paraisse correct.
  4. Téléverser les données à l'aide de JOSM ou avec un script de téléchargement en masse.


Identifiants négatifs

Chaque objet de la base de données OSM a un identifiant unique. Il est attributé par la base de données OSM lorsque l'objet est créé. Par exemple, les identifiants servent à lier les chemins aux nœuds qu'ils contiennent.

Lorsque vous créez votre propre fichier XML au format OSM avec des données qui sont à téléverser, vous ne pouvez pas utiliser des identifiants parce que vous ne les avez pas. En effet, la base de données centrale ne sait rien de vos objets à ce moment. Pourtant vous devez donner un identifiant à vos objets, sinon vous ne pouvez créer de lien entre noeuds, chemins et relations.

L'astuce habituelle pour résoudre ceci est de donner des valeurs négatives distinctes à ces identifiants dans vos fichiers locaux. Au moment du téléversement, les objets sont créés un à un dans la base de données et se voient attribué leur véritable identifiant. Par la suite, vous allez récupérer la valeur de cet identifiant dans la base de données et l'utiliser à la place de votre valeur négative.

A titre d'exemple, cette façon de faire est employée par JOSM.

Importer des données

Il y a plusieurs manière d'ajouter des données en masse à OSM. Chacune a ses forces et ses faiblesses. Une chose est cruciale : n'effectuez pas de test avec l'API réelle. Des instances de base de données dédiées au développement sont à votre disposition pour vérifier que votre processus, vos méthodes ou vos scripts fonctionnent.

Diverses méthodes d'import en masse sont décrites ci-dessous.

avec JOSM

L'une des façons d'importer les plus anciennes et les plus communes consiste à utiliser JOSM. Certains programmes prennent les données source et les convertissent sous forme d'un ou plusieurs fichiers au format JOSM. Un utilisateur peut alors ouvrir JOSM, chargez le fichier et cliquez sur le bouton d'envoi des données vers le serveur.

Cette méthode est assez fiable et permet à l'utilisateur de visualiser et de manipuler les données avant de les télécharger. L'inconvénient est que JOSM doit être en mesure de charger les données, ce qui devient impossible lorsque les données font plusieurs méga-octets. Par ailleurs, il a été constaté que lors du téléchargement de grands volumes de données, le processus est généralement bloqué après quelques milliers d'objets. De ce fait, il n'est pas très utile pour des téléchargements volumineux.

Cette méthode ne peut pas être exécutée directement sur le serveur parce que JOSM est un programme interactif.

avec JOSM et osmsync

osmsync est une bibliothèque qui compare des données externes avec les données déjà présentes dans OSM, puis produit un fichier au format JOSM destiné à être revu par un humain. Cet utilitaire fonctionne parfaitement avec des ensembles de données spécifiques conçus pour la maintenance à long terme avec osmsync.

par manipulation directe de l'API

Cette méthode est plutôt inhabituelle en général, bien qu'elle soit utilisée par Almien coastlines. Le fichier de formes (shapefile) est traité enregistrement par enregistrement et les objets sont créés immédiatement. Le principal inconvénient de cette méthode est que généralement aucun enregistrement n'est fait de ce qui est téléversé (upload) et créé. Et comme c'est fait à la volée, toute interruption ne permet généralement pas de savoir où on était rendu. Le véritable groupe de modifications (changeset) est ambigûe puisqu'il est aussi généré à la volée.

En général, cette méthode devrait être déconseillée.

via Osmosis

Osmosis est un programme qui effectue des manipulations de données OSM. Parmi ses nombreuses fonctionalités, il permet d'appliquer un "fichier de modifications" à une base de données. Cela comprend le format OSM des groupe de modifications.

Toutefois, il ne peut s'exécuter que directement sur une base de données et non via l'API et il lui manque des fonctions telles que des réservations pendant la création d'objets (identifiants négatifs) et l'intégrité référentielle des objets de la base de données. Néanmoins, pour exécuter des modifications pour lesquelles les identifiants des objets sont connus et pour une base de données locale, c'est imbattable.

Ces outils sont prometteurs sur le long terme.

(FIXME: Expliquer pourquoi c'est une manière prometteuse pour l'exécution d'imports volumineux, partant du constat qu'il ne peut pas du tout faire de téléversement (upload).)

via bulk_upload.py

bulk_upload.py est un outil développé en Python qui vise à remplacer bulk_upload.pl et implémente l'API v0.6 (ce que bulk_upload.pl ne fait pas). De même que bulk_upload.pl, il enregistre de manière intelligente la progression. Il divise aussi les groupes de modifications de manière à réduire la taille des tâches de téléchargement. Toutefois, il ne parait pas supporter le format osmChange et, de ce fait, ne peut être utilisé pour des éditions.

via upload.py

upload.py est un autre ensemble de scripts en python dédié au chargement de modifications vers OpenStreetMap et qui utilise actuellement l'API v0.6. L'accent est mis sur la reprise sur incident de réseau ou d'autres situations problématiques, de sorte qu'il est presque toujours possible de reprendre un import qui a échoué sans générer de doublons ou d'autres artefacts. Au lieu d'exécuter la totalité de l'import en une seule commande, ces scripts construisent des blocs qui s'exécutent à bas niveau.

via bulk_upload.pl (obsolète)

Le script en perl bulk_upload.pl a été utilisé pour les imports AND et TIGER, ainsi que pour le chargement de quelques lignes de côte. La méthode appliquée suit basiquement le principe consistant à prendre un fichier de modifications et à les appliquer à la base de données OSM. Le script bulk_upload.pl ne fonctionne pas avec la version actuelle de l'API (à moins que quelqu'un ne le récrive pour créer des groupes de modifications).

Dans le réseau des serveurs OSM

Des sources de données volumineuses (comme TIGER) peuvent parfois être chargées à partir de client avec une latence très faible et bénéficiant d'une bande passante très large vers les principaux serveurs d'OSM.

(FIXME: Est-ce que de tels clients sont actuellement disponibles ? Ou est-ce seulement une chimère ? Peut-être que l'on pourrait utiliser le serveur de dev ?)

Voir aussi