Comment les données OSM brutes sont-elles traitées pour openstreetmap.org

Quelqu'un peut-il donner un aperçu de la façon dont les données OSM sont traitées ou rendues pour www.openstreetmap.org?

Un exemple spécifique ... J'ai extrait des données d'un ensemble de données PostGIS planet.osm récent pour une région du Missouri. Les données OSM nécessitent beaucoup de nettoyage avant de pouvoir être rendues en utilisant les styles appropriés. De nombreux plans d'eau sont stockés sous forme de chaînes de lignes qui ne se ferment pas correctement, je dois donc utiliser FME pour la capture puis la construction de polygones afin de pouvoir avoir des rivières / lacs remplis de bleu.

Si je regarde les mêmes données ici, les plans d'eau sont rendus comme prévu.

J'ai du mal à identifier tous les cas où la capture est requise (par exemple, quels types «naturels» l'exigent et quelle devrait être la tolérance). Je soupçonne également qu'il existe de nombreux autres problèmes de données que je ne verrai jamais car je traite avec toute l'Amérique du Nord.

Est-ce que tous ceux qui téléchargent et utilisent des données OSM passent par leur propre processus de nettoyage? Quelqu'un sait-il comment ce nettoyage est géré par www.openstreetmap.org? Il semble que leur processus soit le mieux informé et le plus testé.

Toute idée très appréciée.

EDIT : Voici plus d'informations sur mon workflow

Un fichier planet.osm est téléchargé et chargé dans PostGIS, à l'aide d'Osmosis, dans le schéma pgsql. J'ai ensuite extrait OSM xml de PostGIS pour de nombreuses petites zones, en utilisant à nouveau l'osmose. Chacun de ces petits fichiers xml est ensuite converti en Shapefiles à l'aide de FME et de ses grandes catégories de fonctionnalités. C'est à cette étape (OSM xml -> Shp via FME) que je m'attends à convertir des lignes en polygones et à effectuer d'autres nettoyages sur les données.

Ces fichiers de formes sont servis via GeoServer (et mis en cache à l'aide de GWC).

D'accord, il y a plusieurs angles différents à cela, et comme on ne sait pas comment vous traitez les données au départ, je suppose que je vais simplement donner un aperçu.

Il existe deux façons principales de consommer des données OSM - en utilisant osm2pgsql , un ancien utilitaire qui prend en charge les `` feuilles de style '' et les mises à jour différentielles, et Imposm , un nouveau système basé sur Python qui prend en charge les transformations de feuilles de style basées sur Python. Quand les gens font du traitement, une grande partie se trouve dans ce genre de script. Par exemple, voici un mappage imposm pour osm-bright , la feuille de style sur laquelle MapBox Streets (divulgation / employé) est basé.

Pour être plus précis sur ce que vous rencontrez, il est probable que vous ne traitez pas correctement les relations osm , ce qui, dans le modèle de données, permet à plusieurs chaînes de lignes de former des polygones. Des outils comme Imposm et osm2pgsql gèrent généralement ce type de transformation de données pour vous.

En ce qui concerne la façon dont OSM.org fait les choses: les modifications sont dans une base de données Postgres «sémantique», et sont continuellement importées dans une base de données PostGIS avec osmose , et rendues avec Mapnik . Il n'y a pas d'étape de nettoyage manuel entre la base de données et le rendu de la carte, car les deux sont fortement couplés et la carte vise à être à jour.

En général, vous n'avez pas besoin de "capturer" en tant que tel, car les données OSM d'origine sont organisées de manière topologique - un polygone (= façon OSM), par exemple, est défini via une liste d'index de nœuds (et non directement par leurs coordonnées) - donc si les indices de début et de fin sont identiques, cela est considéré comme un polygone fermé. Sinon, c'est une polyligne (comme une route).

Les corps plus grands (comme la rivière Osage dans votre cas) sont généralement définis par des multipolygones OSM , qui consistent en une série de voies OSM (chaînes linéaires) qui définissent la forme et les trous (le cas échéant). Il existe plusieurs problèmes potentiels avec les multipolygones OSM:

1. Il existe plusieurs façons de les définir (il suffit de regarder les spécifications). Différentes personnes utilisent des règles différentes.
2. Les règles sont implicites - vous devez lire les documents wiki d'OSM pour essayer de comprendre comment les gérer.
3. Si vous utilisez un extrait de données OSM, certaines parties du multipolygone peuvent être manquantes (car elles ne sont pas géographiquement à l'intérieur de l'état du Missouri). Vous devez donc trouver un moyen de fermer le polygone de plan d'eau (soit en le découpant à l'aide de la frontière d'état, soit en le fermant manuellement avec un outil graphique).

Oui, il existe également d'autres problèmes de données. Ils découlent principalement de la nature même de la cartographie OSM: différentes personnes cartographient les choses différemment et il n'y a pas de règles figées sur la façon de le faire. C'est plus ou moins une anarchie auto-organisée;)

Je ne travaille jamais avec des données OSM aplaties produites par osm2pgsql - je commence toujours par des données topologiques originales sous forme XML OSM et j'écris du code pour les traiter dans la forme dont j'ai besoin. Mais là encore, je n'utilise pas Mapnik pour le rendu, donc je suis probablement en minorité.

Si vous utilisez le schéma de base de données d'origine d'osm2pgsql, vous avez les modèles de données osm associés «voie fermée» et «relation multipolygone» transformés en polygones et placés dans une table appelée «planet_polygon». Les voies et les nœuds sont dans 'planet_line' et 'planet_point'. Vous pouvez accéder à ces tables via Quantum GIS et les exporter directement vers des fichiers de formes. Vous pouvez également effectuer des requêtes SQL depuis Quantum GIS pour filtrer les données.

Je n'utiliserais pas l'osmose pour ça. Il n'a pas la gestion des polygones comme osm2pgsql. L'osmose stocke les données de la même manière que les contributeurs les traitent (Noeuds, voies et relations). Ce n'est pas un schéma de base de données approprié pour le rendu.