FR:Databases and data access APIs

Cette page donne un aperçu des bases de données qui pourraient être utilisées pour stocker et manipuler les données OSM, comment obtenir des données pour alimenter les bases de données et comment les interroger pour trouver quelque chose d'utile.

Elle est destinée aux nouveaux développeurs qui souhaitent écrire des logiciels pour utiliser les données OSM, et non aux utilisateurs finaux de l'information.

Sources des données OSM

Voir aussi Téléchargement de données pour un aperçu des options de base

Les différentes sources de données de l'OSM (soit le monde entier, soit une petite partie de celui-ci) sont identifiées ci-dessous avec des liens vers d'autres pages Wiki qui fournissent plus de détails.

La plupart des méthodes suivantes d'obtention des données renvoient les données au format OSM XML qui peut être utilisé par d'autres outils pour alimenter la base de données. Le format des données est décrit dans Data Primitives.

Planet.osm

Chaque semaine, un dump de l'ensemble des données OSM actuelles est enregistré dans différents formats et mis à disposition sous le nom de Planet.osm. Un certain nombre de personnes décomposent ce fichier en fichiers plus petits pour différentes régions et rendent les extraits disponibles séparément sur des serveurs miroirs. Différents outils sont disponibles pour découper le fichier Planet en plus petites zones si nécessaire.

Les différences entre les données OSM en temps réel et le fichier Planet dump sont également publiées chaque minute sous forme de changeset, de sorte qu'il est possible de maintenir une copie à jour de l'ensemble de données OSM.

XAPI

Les serveurs Xapi permettent de télécharger des données OSM au format XML pour une région donnée du globe, filtrées par balise. Le format Xapi renvoie des zones plus étendues (au niveau des villes) du globe si la demande en est faite, ce qui le rend différent de l'API OSM standard décrite ci-dessous.

API

La principale API est la méthode d'obtention des données OSM utilisée par les éditeurs, car c'est la seule méthode permettant de modifier les données OSM dans la base de données en direct. La page API fournit un lien vers la spécification du protocole à utiliser pour obtenir les données.

Ses limitations sont :

• elle ne renvoie que les très petites zones < 0.25deg square.
• Cette méthode d'obtention de données doit donc être "réservée aux applications d'édition". Utilisez d'autres méthodes pour rendu, routage ou d'autres fins.

API overpass

Permet des requêtes assez complexes sur des zones plus vastes.

GeoFabrik

Propose le téléchargement de régions présélectionnées comme par État. Il existe des options, comme le type de données à inclure et le format de fichier.

ProtoMaps

Offre des téléchargements de données .pbf par polygone délimité et un lien limité dans le temps pour re-télécharger les mêmes données. Certaines méta-données sont omises des nœuds sans balises pour minimiser l'espace.

Choix du SGBD

Il existe plusieurs systèmes de bases de données différents utilisés par les utilisateurs de l'OSM :

Database	Benefits	Disbenefits	Used By
PostgreSQL	Can handle large datasets. The PostGIS extension allows the use geographic extensions	Requires database server to be installed, with associated administrative overhead	Main OSM API, Mapnik renderer
MySQL	Can handle large datasets	Does not have geographic extensions. Requires database server to be installed, with associated administrative overhead	The main database API used MySQL until version 0.6, when it was changed to Postgresql
SQLite	Small, does not require a database server	May struggle with large datasets - See Mail Archive (from 2008, may not be current)	Microcosm
MongoDB	Native Geospatial Indexes and Queries		MongOSM, Node-Mongosm
Hadoop / Hive	Can handle very large datasets (known as big data). Extensions available for geospatial queries (for example ESRI GIS for Hadoop)	Requires Hadoop cluster to be installed, with associated administrative overhead	OSM2Hive

Schémas de base de données

Le schéma de la base de données principale (openstreetmap.org) peut être consulté ici : Schéma du Rails Port/de la base de données".

L'OSM utilise différents schémas de base de données pour différentes applications.

Mise à jour

Si le schéma supporte la mise à jour avec le format OsmChange "diffs". Cela peut être extrêmement important pour maintenir à jour les bases de données mondiales, car cela permet de maintenir la base de données à jour sans nécessiter une réimportation complète (et consommatrice d'espace et de temps) full, worldwide. Cependant, si vous n'avez besoin que d'un petit extract, alors la réimportation de cet extrait peut être une méthode plus rapide et plus facile à maintenir à jour que l'utilisation des OsmChange diffs.

Géométries Si le schéma a des géométries pré-construites. Certains schémas de base de données fournissent des géométries natives (par exemple : PostGIS), ce qui permet leur utilisation dans d'autres logiciels qui peuvent lire ces formats de géométrie. D'autres schémas de base de données peuvent fournir suffisamment de données pour produire les géométries (par exemple : nœuds, voies, relations et leurs liens) mais pas dans un format natif. Certains peuvent fournir les deux. Si vous souhaitez utiliser la base de données avec d'autres logiciels tels qu'un éditeur SIG, alors vous souhaitez probablement un schéma avec ces géométries pré-construites. Cependant, si vous faites votre propre analyse ou si vous utilisez un logiciel écrit pour utiliser le nœud/voie/relation OSM, vous n'aurez peut-être pas besoin de ces géométries.

Sans perte Si l'ensemble des données de l'OSM est conservé. Certains schémas conservent l'ensemble des données OSM, y compris le versionnage, les ID utilisateurs, les informations sur les modifications et toutes les balises. Ces informations sont importantes pour les éditeurs et peuvent être utiles à une personne qui effectue des analyses. Toutefois, si elles ne sont pas importantes, il peut être préférable de choisir un schéma "avec perte", car il est susceptible d'occuper moins d'espace disque et d'être plus rapide à importer.

hcolonnes du magasin

Si le schéma utilise un type de données de paire clé-valeur pour les balises. (Ce type de données est appelé hstore dans PostgreSQL). hstore est peut-être l'approche la plus simple pour représenter le marquage de forme libre de l'OSM dans PostgreSQL. Cependant, tous les outils ne l'utilisent pas et d'autres bases de données peuvent ne pas avoir (ou ne pas avoir besoin) d'équivalent.

Nom du schéma	Créé avec	Utilisé par	Cas d'utilisation primaire	Mise à jour :	Géométries ([[PostGIS])	Sans perte	Colonnes hstore].	Base de données
osm2pgsql	osm2pgsql	Mapnik, Kothic JS	Rendu	oui	oui	non	optional	PostgreSQL
apidb	osmose	API	Miroir	oui	non	oui	non	PostgreSQL, MySQL
pgsnapshot	osmose	jXAPI]	Analyse	oui	optional	oui	oui	PostgreSQL
imposm	Imposm		Rendu	non	oui	non	Imposm2 : non, Imposm3 : oui	PostgreSQL
nominatim	osm2pgsql	Nominatim	Recherche, Géocodage	oui	oui	oui	?	PostgreSQL
ogr2ogr	ogr2ogr		Analyse	non	oui	non	optional	Divers
osmsharp	OsmSharp		Acheminement	oui	non	?	?	Oracle
passager	API de dépassement		Analyse	oui	?	oui	?	coutume.
mongosm	MongOSM		Analyse	peut-être	?	?	?	MongoDB
node-mongosm	Mongoosejs		Analyse	oui	oui	oui	NA	MongoDB
goosm	goosm		Analyse	non	oui	oui	NA	MongoDB
pbf2mongo	pbf2mongo		Analyse	non	oui	oui	NA	MongoDB
waychange	SQL	streetkeysmv	Cache et analyse des données	seulement un schéma	optional	?	non	PostgreSQL
osmium	Osmium		Analyse	non	oui	non	oui	PostgreSQL

osm2pgsql

Le schéma Osm2pgsql est historiquement la manière standard d'importer des données OSM pour les utiliser dans des logiciels de rendu tels que Mapnik. Il est également utilisé dans l'analyse, bien que le schéma ne prenne pas directement en charge le versionnage ou l'historique. L'importation est gérée par le logiciel Osm2pgsql, qui a deux modes de fonctionnement, fin et non fin, qui contrôlent la quantité de mémoire utilisée par le logiciel pendant l'importation et si elle peut être mise à jour. Le mode slim prend en charge les mises à jour, mais le temps nécessaire à l'importation dépend fortement de la vitesse du disque et peut prendre plusieurs jours pour le full planet, même sur une machine rapide. Le mode non slim est plus rapide, mais ne prend pas en charge les mises à jour et nécessite une grande quantité de mémoire.

Le processus d'importation est avec perte, et est contrôlé par un fichier de configuration dans lequel sont listées les clés des éléments d'intérêt. Les valeurs de ces éléments "intéressants" sont importées sous forme de colonnes dans les tableaux de points, de lignes et de polygones. (Alternativement, les valeurs de toutes les balises peuvent être importées dans une colonne de type "hstore"). Ces tableaux peuvent être très volumineux, et il faut faire attention à obtenir de bonnes performances indexées. Si l'ensemble des clés "intéressantes" change après l'importation et qu'aucune colonne de type "hstore" n'a été utilisée, alors l'importation doit être relancée.

Pour plus d'informations, veuillez consulter la page Osm2pgsql.

apidb

ApiDB est un schéma conçu pour reproduire le stockage des données OSM de la même manière que le main API schema et peut être produit en utilisant les commandes Osmosis pour écrire des ApiDB ou mettre à jour les ApiDB avec des modifications. Ce schéma n'a pas de géométrie native, bien que dans les tables des nœuds, voies et relations, il y ait suffisamment de données pour reconstruire les géométries.

Ce schéma supporte l'historique, mais pas le processus d'importation, il peut donc être utilisé pour la mise en miroir de la BD OSM principale. Un historique sera généré au fur et à mesure que les différences de réplication sont appliquées.

Le processus d'importation, même sur du bon matériel, peut prendre plusieurs semaines pour le full planet. La base de données prendra environ 1 To à partir d'avril 2012.

Pour plus d'informations, veuillez consulter la page detailed usage pour Osmosis.

pgsnapshot

Le schéma pgsnapshot est une version modifiée et simplifiée du schéma principal de la BD OSM qui offre un certain nombre de fonctionnalités utiles, notamment la génération de géométries et le stockage des balises dans une seule colonne hstore pour une utilisation et une indexation plus faciles. Le schéma de JXAPI est construit sur pgsnapshot.

imposm

Imposm est un outil d'importation, et est capable de générer des schémas en utilisant un mapping qui est entièrement configurable (il y a aussi un bon default pour la plupart des cas d'utilisation). En tant que tel, il ne devrait pas vraiment compter comme son propre schéma, mais il devait s'intégrer d'une manière ou d'une autre. La possibilité de répartir les données par thème dans différents tableaux simplifie grandement le problème de la performance de l'indexation, et peut entraîner une réduction de la taille des tableaux et des index sur le disque.

Imposm est plus rapide à importer que Osm2pgsql en mode "slim", mais ne permet pas la mise à jour.

nominatim

Nominatim est un géocodeur avant et arrière. La base de données est produite par un back-end spécial de Osm2pgsql. Il s'agit d'une base de données à usage spécifique, et peut ne pas convenir à d'autres domaines problématiques tels que le rendu. La page d'accueil de Nominatim fournit des liens vers la documentation technique détaillée, les journaux de modifications, etc.

ogr2ogr

La bibliothèque OGR peut lire les données OSM (XML et PBF) et peut écrire dans divers autres formats, y compris PostgreSQL/PostGIS, SQLite/Spatialite, et les bases de données MS SQL (bien que je n'aie essayé que PostGIS). L'utilitaire ogr2ogr peut faire la conversion sans aucune programmation nécessaire avec une configuration de schéma qui rappelle osm2pgsql. Une caractéristique intéressante est qu'il résout les relations en géométries : Les multipolygones OSM et les frontières deviennent des multipolygones OGC, les multi-lignes OSM et les routes deviennent des multi-lignes OGC, et les autres relations OSM deviennent des géométries OGC.

Elle est classée comme perdue car les informations sur les membres, telles que les nœuds dans les voies et les membres des relations, ne sont pas conservées. Les métadonnées sont facultatives. Les nœuds et les chemins non étiquetés/non utilisés sont facultatifs.

passage supérieur

Le Overpass_API est un langage d'interrogation construit sur une base de données dorsale personnalisée avec un logiciel appelé OSM3S (voir OSM3S/install pour les instructions d'installation et de configuration). Il s'agit d'une base de données personnalisée et il est donc difficile de la comparer avec d'autres schémas de base de données. Vous pourriez recréer le fichier de la planète complète à partir de la base de données. Elle est conçue pour avoir de bonnes performances sur des ensembles de données concentrés localement.

osmsharp

OsmSharp est une boîte à outils de routines liées à l'OSM, dont certaines pour importer des données OSM dans des bases de données Oracle.

mongosm

MongOSM est un ensemble de scripts Python permettant d'importer, d'interroger et (éventuellement) de conserver des données OSM à jour dans une base de données MongoDB.

node-mongosm

Inspiré de mongOSM, Node-MongOSM utilise Mongoose pour fournir des schémas et des options d'insertion et d'envoi via une interface en ligne de commande.

goosm

Goosm est une application écrite en go pour importer des fichiers XML OSM dans MongoDB. Elle importe en deux passes, d'abord pour les nœuds, puis pour les voies. Les nœuds sont importés en tant que points Geo-JSON, et les voies sont importées en tant que lignes Geo-JSON. Les deux collections créées sont indexées avec des indices géospatiaux permettant une recherche rapide.

pbf2mongo

Il s'agit d'une application basée sur goosm écrite en go pour l'importation de fichiers OSM PBF dans MongoDB. Elle est en cours de développement et à manipuler avec précaution mais vaut la peine d'être essayée.

waychange

Ce simple schéma de base de données a été créé pour stocker les nœuds temporels, les voies, les balises, les relations et les relations entre les nœuds et les voies ainsi qu'entre les relations et ses membres dans une base de données PostgreSQL. Elle sera utilisée avec un script PHP pour séparer et mettre à jour les voies avec les official street keys dans le nord-est de l'Allemagne. Le script charge les données osm via l'API dans la base de données et crée des fichiers de modification à partir de ces données ainsi que des nœuds créés manuellement qui divisent les voies de communication en parties. Ces parties correspondent aux rues officielles et à leurs clés, catégories et numéros. Les voies n'ont pas de changement de position géographique, donc aucune colonne PostGIS n'est nécessaire. La mise à jour ajoute des balises aux voies et si les voies ont été divisées, elle modifie les listes de nœuds, ajoute de nouveaux nœuds et voies et modifie la liste des membres des relations. Ce schéma de base de données ne stocke que les parties dont nous avons besoin pour créer l'ensemble des modifications. La relation spatiale entre les rues officielles et les voies osm a été calculée dans un schéma de base de données séparé avec les voies osm et leur géométrie dans les colonnes PostGIS. Cependant, il est également possible d'ajouter des colonnes de géométrie à ce schéma de changement de voie. N'hésitez pas à utiliser ce schéma et à contacter la OSM Community in Mecklenburg-Western Pomerania et streetkeysmv user.

Exemple de schéma pour le traitement des données OSM

CREATE SCHEMA osm;
-- metadata (optional)
CREATE TABLE osm.users
(
  id               integer NOT NULL, -- 32-bit minimum recommanded if you need this field
  name             character varying NOT NULL, -- user names shold be short, may be empty for users with deleted accounts
  -- other public or private user information may be added here
  CONSTRAINT users_pkey PRIMARY KEY (id)
);
CREATE TABLE osm.changesets
(
  id               integer NOT NULL, -- 32-bit minimum but 64-bit strongly recommanded
  visible          boolean NOT NULL, -- only needed if we can request redacted objects
  closed           boolean NOT NULL,
  uid              integer NOT NULL, -- 32-bit minimum recommanded if you need this field
  last_change      timestamp NOT NULL,
  edit_comment     character varying, -- may also be stored as a changeset's tag
  CONSTRAINT changesets_pkey PRIMARY KEY (id)
);
-- core elements
CREATE TABLE osm.nodes
(
  id               integer NOT NULL, -- 64-bit now required for nodes
  version          integer NOT NULL, -- 16-bit minimum recommanded if you need this field
  visible          boolean NOT NULL, -- only needed if we can request redacted objects
  changeset_id     integer, -- NOT NULL if id>0
  longitude        number NOT NULL, -- only needed if you want to compute geometries
  latitude         number NOT NULL, -- only needed if you want to compute geometries
  CONSTRAINT nodes_pkey PRIMARY KEY (id, version)
);
CREATE TABLE osm.ways
(
  id               integer NOT NULL, -- 32-bit minimum but 64-bit strongly recommanded
  version          integer NOT NULL, -- 16-bit minimum recommanded if you need this field
  visible          boolean NOT NULL, -- only needed if we can request redacted objects
  changeset_id     integer, -- informative metadata, NOT NULL if id>0
  CONSTRAINT ways_pkey PRIMARY KEY (id, version)
);
CREATE TABLE osm.relations
(
  id               integer NOT NULL, -- 32-bit minimum but 64-bit strongly recommanded
  version          integer NOT NULL, -- 16-bit minimum recommanded if you need this field
  visible          boolean NOT NULL, -- only needed if we can request redacted objects
  changeset_id     integer, -- informative metadata, NOT NULL if id>0
  CONSTRAINT relations_pkey PRIMARY KEY (id, version)
);
CREATE TYPE osm.entry_type AS ENUM ('node', 'way', 'relation', 'changeset');
-- children elements
CREATE TABLE osm.way_nodes
(
  way_id           integer NOT NULL, -- 32-bit minimum but 64-bit strongly recommanded
  way_version      integer NOT NULL, -- 16-bit minimum recommanded if you need this field
  nodes_order      integer NOT NULL, -- 16-bit at least (for up to ~2000 nodes per way)
  node_id          integer NOT NULL, -- 64-bit now required for nodes
  node_version     integer NOT NULL, -- 16-bit minimum recommanded if you need this field
  CONSTRAINT way_nodes_pkey PRIMARY KEY (way_id, way_version, nodes_order)
);
CREATE TABLE osm.relation_members
(
  relation_id      integer NOT NULL, -- 32-bit minimum but 64-bit strongly recommanded
  relation_version integer NOT NULL, -- 16-bit minimum recommanded if you need this field
  members_order    integer NOT NULL, -- 16-bit minimum, but optional (order is not significant in most relations)
  member_type      osm.entry_type NOT NULL,
  member_id        integer NOT NULL, -- 64-bit now required for node members
  member_version   integer NOT NULL, -- 16-bit minimum recommanded if you need this field
  role             character varying NOT NULL, -- may be an empty string
  CONSTRAINT relation_members_pkey PRIMARY KEY (relation_id, relation_version, members_order)
);
-- for all core elements and changesets
CREATE TABLE osm.tags
(
  entry_type       osm.entry_type NOT NULL,
  entry_id         integer NOT NULL, -- 64-bit now required for tagging nodes
  entry_version    integer NOT NULL, -- 16-bit minimum recommanded if you need this field
  k                character varying NOT NULL, -- maximum key length should be lower than 256 characters
  v                character varying NOT NULL, -- maximum value length should be lower than 256 characters
  CONSTRAINT tags_pkey PRIMARY KEY (entry_type, entry_id, entry_version, k)
);

Notes :

• ce schéma ne décrit aucune contrainte de clé étrangère entre les tables, seulement les clés primaires avec des contraintes uniques. De plus, il ne contient pas d'index utiles dont vous pourriez avoir besoin pour les performances de votre base de données dérivée.
• le champ entry_type de la dernière table osm.tags n'est pas nécessaire si cette table est divisée en tables séparées pour node_tags, way_tags, relation_tags (et changeset_tags ajoutés dans l'API OSM v0.6).
• la date de la dernière modification et les champs "changeset" les tables "changesets" et "users" sont uniquement informatives, vous n'en avez pas besoin pour traiter les données et éventuellement soumettre des modifications à la base de données OSM.
• Les champs visibles sont informatifs, la plupart des utilisateurs ne peuvent pas y accéder ou ne font que détecter les objets qui sont visibles. Pour le traitement normal ou même pour la mise à jour des objets, vous n'avez pas besoin de ces champs qui seront implicitement vrais.
• les champs de version ne sont pas nécessaires pour les accès en lecture seule, ils ne sont utiles que pour détecter et traiter les changements, mais ils sont nécessaires pour soumettre vos propres changements à la base de données OSM.
• Voir aussi pourquoi 64-bit identifiers sont maintenant requis pour les noeuds dans la base de données OSM.
• Tous les champs de texte doivent être codés en UTF-8 dans la base de données OSM. Veuillez ne pas soumettre d'autres encodages (il reste encore des données anciennes qui utilisent des encodages non valides, le plus souvent dans les commentaires, notes, sources ou fixme tags créés avec d'anciens éditeurs). Ne les stockez pas en utilisant des entités de caractères nommés ou décimaux (HTML, XML et JSON utiliseront automatiquement et de manière transparente des séquences d'échappement, uniquement lorsque leur syntaxe l'exige). N'utilisez pas de contrôles ASCII, de caractères Unicode à usage privé ou de caractères Unicode non attribués. Veuillez couper les espaces avant et arrière. Les clés de balises standard doivent également éviter d'utiliser des espaces, des symboles ou des signes de ponctuation (à l'exception du soulignement et des deux points), afin de les rendre compatibles avec les identificateurs HTML, XML, CSS ou DOM.

osmium

Le jeu d'outils Osmium peut lire les données OSM et avec osmium export peut écrire dans PostgreSQL/PostGIS.

Les objets sont chargés dans une seule table de données OSM avec des géomètres à colonnes et des balises.