Як обробляються необроблені дані OSM для openstreetmap.org

Чи може хто-небудь надати уявлення про те, як обробляються чи рендеруються дані OSM для www.openstreetmap.org?

Конкретний приклад ... Я витягнув дані з недавнього набору даних planet.osm PostGIS для району в Міссурі. Дані OSM потребують великого очищення, щоб їх можна було відобразити за допомогою правильних стилів. Багато водойм зберігаються як рядкові рядки, які не закриваються належним чином, тому я повинен використовувати FME для оснащення, а потім побудови полігону, щоб я міг заповнити сині заповнені річки / озера.

Якщо я дивлюся на ті самі дані, то тут водойми надаються так, як очікувалося.

У мене виникають проблеми з ідентифікацією всіх випадків, коли потрібне оснащення (наприклад, які "природні" типи вимагають цього та якою має бути толерантність). Також я підозрюю, що існує багато інших проблем з даними, які я ніколи не побачу, оскільки маю справу з усією Північною Америкою.

Чи кожен, хто завантажує та використовує дані OSM, проходить власний процес очищення? Хто-небудь знає, як цим способом очищення займається www.openstreetmap.org? Схоже, що їхній процес був би найкраще обізнаним та найбільш перевіреним.

Будь-яке розуміння дуже цінується.

EDIT : Ось додаткова інформація про мій робочий процес

Файл planet.osm завантажується і завантажується в PostGIS, використовуючи Osmosis, у схему pgsql. Потім я витягую OSM xml з PostGIS для багатьох невеликих областей, знову використовуючи осмос. Кожен з цих невеликих xml-файлів потім перетворюється у Shapefiles за допомогою FME та його широких категорій функцій. Саме на цьому етапі (OSM xml -> Shp через FME) я розраховую перетворити лінії в багатокутники та виконати інше очищення даних.

Ці Shapefiles подаються через GeoServer (і кешуються за допомогою GWC).

Гаразд, для цього є кілька різних ракурсів, і оскільки незрозуміло, як ви спочатку обробляєте дані, я думаю, я просто дам огляд.

Є два основні способи споживання даних OSM - за допомогою osm2pgsql , старішої утиліти, яка підтримує «таблиці стилів» та диференціальних оновлень, та Imposm , більш нової системи на основі Python, яка підтримує перетворення таблиць стилів на основі Python. Коли люди роблять обробку, багато чого є в такому вигляді сценарію. Наприклад, ось відображення імпозного відображення для osm-яскравих , таблиць стилів, на яких засновані MapBox Streets (розкриття / працівник).

Щоб бути більш конкретним щодо того, з чим ви стикаєтесь, швидше за все, ви неправильно не обробляєте відношення осмів , що в моделі даних є тим, що дозволяє декільком рядкам створювати багатокутники. Такі інструменти, як Imposm та osm2pgsql, як правило, обробляють цей вид перетворення даних для вас.

Що стосується того, як працює сам OSM.org: правки знаходяться в "семантичній" базі даних Postgres і постійно імпортуються в базу даних PostGIS з осмосом і надаються разом із Mapnik . Немає жодного кроку очищення вручну між базою даних та рендерінгом карти, оскільки вони сильно поєднані, і карта має на меті бути оновленою.

Взагалі вам не потрібно «оснащення» як такого, оскільки вихідні дані OSM є топологічно організованими - наприклад, багатокутник (= спосіб OSM) визначається через список індексів вузлів (а не безпосередньо за їх координатами) - тож якщо початковий та кінцевий індекси однакові, це вважається закритим багатокутником. Інакше це полілінія (як дорога).

Більш великі тіла (наприклад, річка Осаж у вашому випадку) зазвичай визначаються через багатополігони OSM , які складаються з серії способів OSM (рядків), які визначають форму та отвори (якщо такі є). Існує кілька потенційних проблем з багатополігонами OSM:

1. Існує не один спосіб їх визначення (просто подивіться на характеристики). Різні люди використовують різні правила.
2. Правила неявні - вам потрібно прочитати через вікі-документи OSM, щоб спробувати зрозуміти, як з ними поводитися.
3. Якщо ви використовуєте витяг даних OSM, деякі частини мультиполігону можуть бути відсутніми (оскільки вони географічно не знаходяться в штаті Міссурі). Тож вам потрібно знайти спосіб закрити багатокутник водойми (або відрізавши його за допомогою межі стану, або закривши його вручну деяким інструментом GUI).

Так, є й інші проблеми з даними. В основному вони випливають із самої природи відображення OSM: різні люди відображають речі по-різному, і немає правил, встановлених в камені, як це зробити. Це більш-менш самоорганізована анархія;)

Я сам ніколи не працюю з згладженими даними OSM, що виробляються osm2pgsql - я завжди починаю з оригінальних топологічних даних у формі OSM XML і пишу код, щоб обробити це у потрібну мені форму. Але потім я знову не використовую Mapnik для візуалізації, тому я, мабуть, у меншості.

Якщо ви використовуєте оригінальну схему баз даних з osm2pgsql, то пов'язані з вами моделі даних осма «закритого шляху» та «відношення багатополігонів» перетворені в багатокутники та поміщені в таблицю під назвою «planet_polygon». Шляхи та вузли знаходяться у ‘planet_line’ та ‘planet_point’. Ви можете отримати доступ до цих таблиць за допомогою Quantum GIS та експортувати їх безпосередньо у formfiles. Ви також можете робити SQL запити всередині Quantum GIS для фільтрації даних.

Я б не використовував для цього осмос. Він не має керування полігоном, як це робить osm2pgsql. Осмоз зберігає дані таким же чином, як вкладники поводяться з ними (Вузли, способи та відносини). Це не підходяща схема бази даних для візуалізації.