openstreetmap.orgの未加工OSMデータはどのように処理されますか


12

www.openstreetmap.orgでOSMデータがどのように処理またはレンダリングされるかについて、誰でも洞察を提供できますか

具体的な例...ミズーリ州のある地域の最近のplanet.osm PostGISデータセットからデータを抽出しました。OSMデータは、正しいスタイルを使用してレンダリングする前に、多くのクリーニングが必要です。多くの水域は、適切に閉じないラインストリングとして保存されるため、FMEを使用してスナップし、次にポリゴンビルディングを使用して、青色で満たされた川/湖を持たせる必要があります。

ここで同じデータを見ると、水域は予想どおりにレンダリングされています。

スナップが必要なすべてのケースを特定するのに問題があります(たとえば、どの 'Natural'タイプがスナップを必要とするか、許容値はどうあるべきか)。また、私は北米のすべてを扱っているので、私は決して見ないであろう他の多くのデータの問題があると思います。

OSMデータをダウンロードして使用するすべての人が、独自のクリーンアッププロセスを実行しますか?このクリーンアップがwww.openstreetmap.orgによってどのように処理されるかを知っている人はいますか?彼らのプロセスは、最も情報に基づいており、最もテストされているようです。

どんな洞察も大歓迎です。

編集:ここに私のワークフローの詳細があります

planet.osmファイルがダウンロードされ、Osmosisを使用してpgsqlスキーマにPostGISにロードされます。次に、Osmosisを使用して、多くの小さな領域のPostGISからOSM xmlを抽出します。これらの小さなxmlファイルはそれぞれ、FMEとその幅広い機能カテゴリを使用してシェープファイルに変換されます。この段階(OSM xml-> FME経由のShp)で、ラインをポリゴンに変換し、データに対して他のクリーンアップを実行することを期待しています。

これらのシェープファイルは、GeoServerを通じて提供されます(GWCを使用してキャッシュされます)。


あなたはタイルを提供したいですか?その場合、開始する場所はここにあります:switch2osm.org/serving-tiles
neuhausr

回答:


9

さて、これにはいくつかの異なる角度があり、最初にデータを処理する方法が不明であるため、単に概要を説明します。

OSMデータを使用するに、主に2つの方法があります。「スタイルシート」と差分更新をサポートする古いユーティリティであるosm2pgsqlと、Pythonベースのスタイルシート変換をサポートする新しいPythonベースのシステムImposmを使用する方法です。人々が処理を行うとき、その多くはそのようなスクリプトにあります。たとえば、これはosm-brightのimposmマッピングです。これは、MapBox Streets(情報開示/従業員)が基づいているスタイルシートです。

発生しているものにより具体的には、osmリレーションを適切に処理していない可能性があります。データモデルでは、複数のラインストリングでポリゴンを形成できます。Imposmやosm2pgsqlなどのツールは通常、この種のデータ変換を処理します。

OSM.org自体の動作に関する限り、編集は「セマンティック」なPostgresデータベースにあり、osmosisを使用してPostGISデータベースに継続的にインポートされ、Mapnikでレンダリングされます。データベースとマップレンダリングの間に手動のクリーンアップ手順はありません。2つは高度に結合されており、マップは最新の状態を目指しているためです。


情報のおかげで。私の編集を見て、これが私のオプションにどのように影響するか教えてください。Imposmまたはosm2pgsqlを使用してこれらの領域を作成するというアイデアが好きですが、ノードとウェイテーブルのみがあり、領域がないことが確実であるため、PostGISで異なる(非pgsql)スキーマが必要だと思います。おそらく、PostGISにエリアを取得した場合、OSM xmlに抽出するときに再び失われますか?PostGISでデータを別の方法で保存し、SHPに直接抽出する必要がありますか?
-tomfumb

5

通常、元のOSMデータはトポロジ的に編成されているため、「スナップ」は必要ありません。たとえば、ポリゴン(= OSMウェイ)はノードインデックスのリストによって(および座標によって直接ではなく)定義されます。したがって、開始インデックスと終了インデックスが同じ場合、それは閉じたポリゴンと見なされます。それ以外の場合は、ポリライン(道路など)です。

より大きなボディ(あなたの場合のOsage川のような)は通常、形状と穴(存在する場合)を定義する一連のOSMウェイ(ラインストリング)で構成されるOSMマルチポリゴンによって定義されます。OSMマルチポリゴンにはいくつかの潜在的な問題があります。

  1. それらを定義する方法は複数あります(仕様を見てください)。異なる人々は異なるルールを使用します。
  2. ルールは暗黙的です。OSMwikiのドキュメントを読んで、ルールの処理方法を理解する必要があります。
  3. OSMデータ抽出を使用する場合、マルチポリゴンの一部が欠落する可能性があります(地理的にミズーリ州内にないため)。そのため、水域ポリゴンを閉じる方法を見つける必要があります(状態境界を使用してクリップするか、GUIツールを使用して手動で閉じます)。

はい、他のデータの問題もあります。主にOSMマッピングの性質に由来します。異なる人々が異なる方法でマッピングを行い、それを行う方法について定められたルールはありません。それは多かれ少なかれ自己組織化された無秩序です;)

私自身は、osm2pgsqlによって生成された平坦化されたOSMデータを使用しません。OSMXML形式の元のトポロジデータから開始し、それを必要な形式に処理するコードを記述します。しかし、それでもレンダリングにMapnikを使用しないので、おそらく少数派です。


1

osm2pgsqlの元のデータベーススキームを使用すると、関連するosmデータモデルが「クローズドウェイ」および「マルチポリゴンリレーション」にポリゴンに変換され、「planet_polygon」というテーブルに配置されます。ウェイとノードは「planet_line」と「planet_point」にあります。Quantum GISを介してこれらのテーブルにアクセスし、シェープファイルに直接エクスポートできます。Quantum GIS内からSQLクエリを実行して、データをフィルタリングすることもできます。

そのために浸透圧を使用しません。osm2pgsqlのようなポリゴン処理はありません。Osmosisは、貢献者がデータを扱うのと同じ方法(ノード、ウェイ、およびリレーション)でデータを保存します。レンダリングに適したデータベーススキームではありません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.