Bagaimana data OSM mentah diproses untuk openstreetmap.org

Adakah yang bisa memberikan wawasan tentang bagaimana data OSM diproses atau diterjemahkan untuk www.openstreetmap.org?

Contoh spesifik ... Saya mengekstraksi data dari dataset postGIS planet.osm baru-baru ini untuk area di Missouri. Data OSM membutuhkan banyak pembersihan sebelum dapat diberikan menggunakan gaya yang benar. Banyak badan air disimpan sebagai string garis yang tidak menutup dengan benar, jadi saya harus menggunakan FME untuk mematahkan dan kemudian membangun poligon sehingga saya dapat memiliki sungai / danau berwarna biru.

Jika saya melihat data yang sama di sini badan air diberikan seperti yang diharapkan.

Saya mengalami kesulitan mengidentifikasi semua kasus di mana patah diperlukan (misalnya jenis 'Alami' mana yang memerlukannya dan apa toleransi yang seharusnya). Saya juga curiga ada banyak masalah data lain yang tidak akan pernah saya lihat karena saya berurusan dengan semua Amerika Utara.

Apakah semua orang yang mengunduh dan menggunakan data OSM menjalani proses pembersihan mereka sendiri? Adakah yang tahu bagaimana pembersihan ini ditangani oleh www.openstreetmap.org? Sepertinya proses mereka akan menjadi yang terbaik dan paling teruji.

Setiap wawasan sangat kami hargai.

EDIT : Berikut ini informasi lebih lanjut tentang alur kerja saya

File planet.osm diunduh dan dimuat ke PostGIS, menggunakan Osmosis, ke dalam skema pgsql. Saya kemudian mengekstrak OSM xml dari PostGIS untuk banyak area kecil, sekali lagi menggunakan Osmosis. Masing-masing file xml kecil ini kemudian dikonversi ke Shapefile menggunakan FME dan kategori fitur luasnya. Ini adalah tahap ini (OSM xml -> Shp via FME) yang saya harapkan untuk mengubah garis menjadi poligon dan melakukan pembersihan lainnya pada data.

Shapefile ini dilayani melalui GeoServer (dan di-cache menggunakan GWC).

Oke, ada beberapa sudut berbeda untuk ini, dan karena tidak jelas bagaimana Anda memproses data pada awalnya, saya kira saya hanya akan memberikan ikhtisar.

Ada dua cara utama untuk mengkonsumsi data OSM - dengan menggunakan osm2pgsql , sebuah utilitas lama yang mendukung 'stylesheet' dan pembaruan diferensial, dan Imposm , sistem berbasis-Python yang lebih baru yang mendukung transformasi stylesheet berbasis-Python. Ketika orang melakukan pemrosesan, banyak yang ada dalam jenis script. Misalnya, inilah pemetaan mustahil untuk osm-bright , lembar gaya yang menjadi dasar MapBox Streets (pengungkapan / karyawan).

Untuk lebih spesifik dengan apa yang Anda temui, kemungkinan Anda tidak memproses dengan benar hubungan osm dengan benar, yang, dalam model data inilah yang memungkinkan banyak linestrings untuk membentuk poligon. Alat seperti Imposm dan osm2pgsql umumnya menangani transformasi data semacam ini untuk Anda.

Sejauh bagaimana OSM.org sendiri melakukan hal-hal: suntingan berada dalam database Postgres 'semantik', dan terus-menerus diimpor ke dalam database PostGIS dengan osmosis , dan diterjemahkan dengan Mapnik . Tidak ada langkah pembersihan manual antara database dan rendering peta, karena keduanya sangat berpasangan dan peta bertujuan untuk selalu terbaru.

Secara umum Anda tidak perlu "gertakan", karena data OSM asli diatur secara topologi - poligon (= cara OSM), misalnya, ditentukan melalui daftar indeks titik (dan tidak secara langsung dengan koordinatnya) - jadi jika indeks awal dan akhir sama, itu dianggap poligon tertutup. Kalau tidak, itu polyline (seperti jalan).

Badan yang lebih besar (seperti sungai Osage dalam kasus Anda) biasanya ditentukan melalui multipoligon OSM , yang terdiri dari serangkaian cara OSM (linestrings) yang menentukan bentuk dan lubang (jika ada). Ada beberapa potensi masalah dengan OSM multipolygons:

1. Ada lebih dari satu cara untuk mendefinisikannya (lihat saja spesifikasinya). Orang yang berbeda menggunakan aturan yang berbeda.
2. Aturannya implisit - Anda perlu membaca dokumen wiki OSM untuk mencoba memahami cara menanganinya.
3. Jika Anda menggunakan ekstrak data OSM, beberapa bagian dari multipolygon bisa hilang (karena mereka tidak secara geografis di dalam negara bagian Missouri). Jadi, Anda perlu menemukan cara untuk menutup poligon badan air (baik dengan memotongnya menggunakan batas negara atau menutupnya secara manual dengan beberapa alat GUI).

Ya, ada masalah data lainnya juga. Terutama mereka berasal dari sifat pemetaan OSM: orang yang berbeda memetakan sesuatu secara berbeda dan tidak ada aturan baku tentang bagaimana melakukannya. Ini lebih atau kurang anarki yang terorganisir sendiri;)

Saya sendiri tidak pernah bekerja dengan data OSM pipih yang dihasilkan oleh osm2pgsql - Saya selalu mulai dengan data topologi asli dalam bentuk XML OSM dan menulis kode untuk memprosesnya menjadi bentuk yang saya butuhkan. Tapi sekali lagi saya tidak menggunakan Mapnik untuk rendering, jadi saya mungkin dalam minoritas.

Jika Anda menggunakan skema database asli dari osm2pgsql, Anda memiliki model data osm terkait 'cara tertutup' dan 'hubungan multipoligon' ditransformasikan menjadi poligon dan dimasukkan ke dalam tabel yang disebut 'planet_polygon'. Cara dan simpul ada di 'planet_line' dan 'planet_point'. Anda dapat mengakses tabel ini melalui GIS Quantum, dan mengekspornya langsung ke shapefile. Anda juga dapat melakukan kueri SQL dari dalam Quantum GIS untuk memfilter data.

Saya tidak akan menggunakan osmosis untuk itu. Itu tidak memiliki penanganan poligon seperti osm2pgsql. Osmosis menyimpan data dengan cara yang sama seperti yang dilakukan oleh kontributor (Nodes, cara dan hubungan). Ini bukan skema database yang cocok untuk rendering.