Openstreetmap.org için ham OSM verileri nasıl işlenir

Www.openstreetmap.org için OSM verilerinin nasıl işlendiğine veya işlendiğine dair herhangi bir fikir verebilir mi?

Özel bir örnek ... Missouri'deki bir alan için yeni bir planet.osm PostGIS veri kümesinden veri çıkardım. OSM verilerinin doğru stiller kullanılarak oluşturulmadan önce çok fazla temizlenmesi gerekir. Birçok su kütlesi düzgün kapanmayan çizgi dizeleri olarak saklanır, bu nedenle mavi dolgulu nehirlere / göllere sahip olabilmem için FME'yi yapışma ve sonra çokgen oluşturma için kullanmam gerekir.

Burada aynı verilere bakarsam , su kütleleri beklendiği gibi işlenir.

Yakalamanın gerekli olduğu tüm durumları tanımlamakta zorlanıyorum (örneğin 'Doğal' tipler bunu gerektirir ve toleransın ne olması gerekir). Ayrıca, tüm Kuzey Amerika ile uğraşırken asla görmeyeceğim birçok veri sorunu olduğundan şüpheleniyorum.

OSM verilerini indirip kullanan herkes kendi temizleme işlemlerinden geçiyor mu? Bu temizliğin www.openstreetmap.org tarafından nasıl ele alındığını bilen var mı? Süreçleri en iyi bilgilendirilmiş ve en çok test edilmiş gibi görünüyor.

Herhangi bir fikir çok takdir etmek.

EDIT : İşte benim iş akışı hakkında daha fazla bilgi

Planet.osm dosyası Osmosis kullanılarak pgsql şemasına indirilir ve PostGIS'e yüklenir. Sonra Osmosis kullanarak, birçok küçük alan için PostGIS OSM xml ayıklayın. Bu küçük xml dosyalarının her biri daha sonra FME ve geniş özellik kategorileri kullanılarak Shapefiles'a dönüştürülür. Bu aşamayı (OSM xml -> FME üzerinden Shp), çizgileri çokgenlere dönüştürmeyi ve veriler üzerinde başka bir temizleme gerçekleştirmeyi bekliyorum.

Bu Shapefiles dosyaları GeoServer aracılığıyla sunulur (ve GWC kullanılarak önbelleğe alınır).

Tamam, bunun birkaç farklı açısı var ve başlangıçta verileri nasıl işlediğiniz belirsiz olduğu için, sanırım sadece bir genel bakış sunacağım.

Kullanarak - OSM verilerini tüketmek iki ana yolu vardır osm2pgsql , eski bir yarar olduğunu destekler 'stil' ve diferansiyel güncellemeleri ve Imposm , Python tabanlı stil dönüşümleri destekleyen yeni, Python tabanlı sistem. İnsanlar işlediğinde, bunların çoğu bu tür bir senaryodadır. Örneğin, MapBox Sokaklarının (açıklama / çalışan) dayandığı stil sayfası olan osm -parlak için bir gösterim eşlemesi .

Karşılaştığınız şeye daha spesifik olmak için, osm ilişkilerini düzgün şekilde işlemiyor olabilirsiniz ; bu, veri modelinde birden çok linestring'in çokgen oluşturmasına izin veren şeydir. Imposm ve osm2pgsql gibi araçlar genellikle bu tür veri dönüşümünü sizin için halleder.

Düzenlemeler 'semantik' Postgres veritabanında vardır ve sürekli bir PostGIS veritabanına ithal: nasıl OSM.org kendisi şeyler yapar kadarıyla ozmoz ve birlikte render Mapnik . Veritabanı ve harita oluşturma arasında manuel temizleme adımı yoktur, çünkü ikisi birbiriyle oldukça bağlantılıdır ve harita güncel olmayı amaçlamaktadır.

Genel olarak, orijinal OSM verileri topolojik olarak organize edildiğinden, örneğin bir çokgen (= OSM yolu), düğüm indekslerinin bir listesi aracılığıyla tanımlanır (ve doğrudan koordinatlarıyla değil) olarak tanımlandığı gibi "yakalamaya" ihtiyacınız yoktur. başlangıç ​​ve bitiş indeksleri aynıysa, bu kapalı bir çokgen olarak kabul edilir. Aksi takdirde, bir çoklu yol (bir yol gibi).

(Senin durumunda Osage nehir gibi) Büyük cisimler genellikle aracılığıyla tanımlanır OSM multipolygons şekil ve delikler (varsa) tanımlayan OSM yolları (LineStrings) bir dizi oluşur. OSM çokgenleri ile ilgili birkaç potansiyel sorun vardır:

1. Onları tanımlamanın birden fazla yolu vardır (sadece özelliklere bakın). Farklı insanlar farklı kurallar kullanır.
2. Kurallar örtülüdür - OSM wiki belgelerini nasıl kullanacağınızı anlamaya çalışmak için okumalısınız.
3. Bir OSM veri özü kullanırsanız, çokgengonun bazı kısımları eksik olabilir (coğrafi olarak Missouri eyaletinde olmadıkları için). Bu yüzden su kütlesi poligonunu kapatmanın bir yolunu bulmanız gerekir (ya devlet sınırını kullanarak kırparak ya da bir GUI aracıyla manuel olarak kapatarak).

Evet, başka veri sorunları da var. Temelde OSM haritalamasının doğasından kaynaklanırlar: farklı insanlar şeyleri farklı şekilde haritalar ve nasıl yapılacağına dair kesin kurallar yoktur. Az çok kendi kendini organize eden bir anarşi;)

Kendim asla osm2pgsql tarafından üretilen düzleştirilmiş OSM verileri ile çalışma - Her zaman OSM XML formunda orijinal topolojik verilerle başlar ve ihtiyacım olan forma işlemek için kod yazarım. Ama sonra tekrar Mapnik'i render için kullanmıyorum, bu yüzden muhtemelen azınlıktayım.

Orijinal veritabanı şemasını osm2pgsql'den kullanırsanız, ilgili osm veri modellerine 'kapalı yol' ve 'çokgenli ilişki' çokgenlere dönüştürülür ve 'planet_polygon' adlı bir tabloya konulur. Yollar ve düğümler 'planet_line' ve 'planet_point'dedir. Bu tablolara Quantum GIS aracılığıyla erişebilir ve doğrudan şekil dosyalarına aktarabilirsiniz. Verileri filtrelemek için Quantum GIS içinden SQL sorguları da yapabilirsiniz.

Bunun için ozmoz kullanmam. Osm2pgsql gibi çokgen işleme sahip değildir. Osmoz, verileri katkıda bulunanlarla onlarla aynı şekilde saklar (Düğümler, yollar ve ilişkiler). Oluşturmak için uygun bir veritabanı şeması değildir.