Jak przetwarzane są surowe dane OSM dla openstreetmap.org

Czy ktoś może zapewnić wgląd w sposób przetwarzania lub renderowania danych OSM dla www.openstreetmap.org?

Konkretny przykład ... Wyodrębniłem dane z najnowszego zestawu danych PostGIS planet.osmos dla obszaru w Missouri. Dane OSM wymagają dużo czyszczenia, aby można je było renderować przy użyciu odpowiednich stylów. Wiele zbiorników wodnych jest przechowywanych jako ciągi liniowe, które nie zamykają się prawidłowo, więc muszę użyć FME do przyciągania, a następnie do budowy wielokątów, aby mieć niebieskie rzeki / jeziora.

Jeśli spojrzę na te same dane tutaj, części wód są renderowane zgodnie z oczekiwaniami.

Mam problem ze zidentyfikowaniem wszystkich przypadków, w których wymagane jest przyciąganie (np. Które typy „naturalne” tego wymagają i jaka powinna być tolerancja). Podejrzewam również, że istnieje wiele innych problemów z danymi, których nigdy nie zobaczę, ponieważ mam do czynienia z całą Ameryką Północną.

Czy każdy, kto pobiera i wykorzystuje dane OSM, przechodzi własny proces czyszczenia? Czy ktoś wie, jak to czyszczenie jest obsługiwane przez www.openstreetmap.org? Wygląda na to, że ich proces byłby najlepiej poinformowany i najlepiej przetestowany.

Wszelkie informacje bardzo cenione.

EDYCJA : Oto więcej informacji na temat mojego przepływu pracy

Plik planet.osm jest pobierany i ładowany do PostGIS za pomocą Osmosis do schematu pgsql. Następnie wyodrębniam OSM xml z PostGIS dla wielu małych obszarów, ponownie używając Osmosis. Każdy z tych małych plików XML jest następnie konwertowany na pliki Shapefiles przy użyciu FME i jego szerokich kategorii funkcji. To na tym etapie (OSM xml -> Shp przez FME) oczekuję, że przekonwertuję linie na wielokąty i przeprowadzę inne czyszczenie danych.

Te pliki kształtów są obsługiwane przez GeoServer (i buforowane przy użyciu GWC).

Ok, jest na to kilka różnych punktów widzenia, a ponieważ nie jest jasne, w jaki sposób początkowo przetwarzasz dane, myślę, że przedstawię tylko przegląd.

Istnieją dwa główne sposoby konsumowania danych OSM - za pomocą osm2pgsql , starszego narzędzia obsługującego „arkusze stylów” i aktualizacje różnicowe oraz Imposm , nowszego systemu opartego na języku Python, który obsługuje transformacje arkuszy stylów oparte na języku Python. Kiedy ludzie przetwarzają, wiele z nich znajduje się w tego rodzaju skryptach. Na przykład, oto mapowanie impassu dla osm-bright , arkusz stylów, na którym oparte są mapy MapBox (ujawnienie / pracownik).

Aby być bardziej szczegółowym w stosunku do tego, co napotykasz, prawdopodobne jest, że nie przetwarzasz poprawnie relacji osm , co w modelu danych pozwala na tworzenie wielokątów przez wiele linii. Narzędzia takie jak Imposm i osm2pgsql generalnie obsługują tego rodzaju transformację danych.

Jeśli chodzi o sposób, w jaki OSM.org robi rzeczy: zmiany są w „semantycznej” bazie danych Postgres i ciągle importowane do bazy danych PostGIS z osmozą i renderowane za pomocą Mapnika . Pomiędzy renderowaniem bazy danych a mapą nie ma kroku ręcznego czyszczenia, ponieważ oba są ze sobą ściśle powiązane, a mapa ma być aktualna.

Zasadniczo nie potrzebujesz „przyciągania” jako takiego, ponieważ oryginalne dane OSM są uporządkowane topologicznie - na przykład wielokąt (= sposób OSM) jest definiowany poprzez listę indeksów węzłów (a nie bezpośrednio przez ich współrzędne) - więc jeśli indeks początkowy i końcowy są takie same, jest to uważane za zamknięty wielokąt. W przeciwnym razie jest to polilinia (jak droga).

Większe ciała (jak w twoim przypadku rzeka Osage) są zwykle definiowane przez wieloboki OSM , które składają się z szeregu sposobów OSM (linii), które określają kształt i otwory (jeśli występują). Istnieje kilka potencjalnych problemów z wielobokami OSM:

1. Istnieje więcej niż jeden sposób ich zdefiniowania (wystarczy spojrzeć na specyfikację). Różni ludzie stosują różne zasady.
2. Reguły są niejawne - musisz przeczytać dokumentację wiki OSM, aby spróbować zrozumieć, jak sobie z nimi radzić.
3. Jeśli użyjesz wyciągu danych OSM, może brakować niektórych części wieloboku (ponieważ nie są one geograficznie wewnątrz stanu Missouri). Musisz więc znaleźć sposób na zamknięcie wielokąta akwenu (poprzez przycięcie go za pomocą granicy stanu lub ręczne zamknięcie go za pomocą jakiegoś narzędzia GUI).

Tak, są też inne problemy z danymi. Głównie wynikają one z samej natury mapowania OSM: różni ludzie mapują rzeczy inaczej i nie ma ustalonych zasad, jak to zrobić. To mniej więcej samoorganizująca się anarchia;)

Sam nigdy nie pracuję ze spłaszczonymi danymi OSM wytwarzanymi przez osm2pgsql - zawsze zaczynam od oryginalnych danych topologicznych w formie XML OSM i piszę kod, aby przetworzyć je w potrzebny mi formularz. Ale znowu nie używam Mapnika do renderowania, więc prawdopodobnie jestem w mniejszości.

Jeśli korzystasz z oryginalnego schematu bazy danych z osm2pgsql, powiązane modele danych osm są „zamknięte” i „relacja multipolygon” przekształcone w wielokąty i umieszczone w tabeli o nazwie „planet_polygon”. Sposoby i węzły znajdują się w „planet_line” i „planet_point”. Możesz uzyskać dostęp do tych tabel za pośrednictwem Quantum GIS i eksportować je bezpośrednio do plików kształtów. Możesz również wykonywać zapytania SQL z poziomu Quantum GIS w celu filtrowania danych.

Nie użyłbym do tego osmozy. Nie obsługuje wielokąta, jak robi to osm2pgsql. Osmosis przechowuje dane w taki sam sposób, w jaki współpracownicy sobie z nimi radzą (węzły, sposoby i relacje). To nie jest odpowiedni schemat bazy danych do renderowania.