Как обрабатываются необработанные данные OSM для openstreetmap.org

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

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

Если я посмотрю на те же данные, то здесь водоемы отображаются так, как и ожидалось.

У меня проблемы с определением всех случаев, когда требуется привязка (например, какие типы «Natural» требуют этого и какой должна быть допуск). Также я подозреваю, что есть много других проблем с данными, которые я никогда не увижу, поскольку имею дело со всей Северной Америкой.

Все ли, кто загружает и использует данные OSM, проходят свой собственный процесс очистки? Кто-нибудь знает, как эта очистка обрабатывается www.openstreetmap.org? Кажется, что их процесс будет наиболее информированным и наиболее проверенным.

Любое понимание высоко ценится.

РЕДАКТИРОВАТЬ : Вот больше информации о моем рабочем процессе

Файл planet.osm загружается и загружается в PostGIS, используя Osmosis, в схему pgsql. Затем я извлекаю OSM xml из PostGIS для множества небольших областей, снова используя Osmosis. Каждый из этих небольших XML-файлов затем преобразуется в шейп-файлы с использованием FME и его широких категорий функций. Именно на этом этапе (OSM xml -> Shp через FME) я ожидаю преобразовать линии в полигоны и выполнить другую очистку данных.

Эти шейп-файлы обслуживаются через GeoServer (и кешируются с помощью GWC).

Хорошо, у этого есть несколько разных точек зрения, и поскольку неясно, как вы обрабатываете данные вначале, я думаю, что я просто дам обзор.

Есть два основных способа использования данных OSM - с помощью osm2pgsql , более старой утилиты, которая поддерживает «таблицы стилей» и дифференциальные обновления, и Imposm , более новой системы на основе Python, которая поддерживает преобразования таблиц стилей на основе Python. Когда люди занимаются обработкой, многое происходит в таком виде сценария. Например, вот отображение imposm для osm-bright , таблицы стилей, на которой основана карта MapBox Streets (раскрытие / сотрудник).

Чтобы быть более точным в отношении того, с чем вы сталкиваетесь, скорее всего, вы неправильно обрабатываете отношения osm , которые в модели данных позволяют многострочным строкам формировать полигоны. Такие инструменты, как Imposm и osm2pgsql, обычно обрабатывают этот вид преобразования данных для вас.

Что касается того, как сам OSM.org делает вещи: изменения находятся в «семантической» базе данных Postgres и непрерывно импортируются в базу данных PostGIS с помощью osmosis и отображаются с помощью Mapnik . Нет никакого шага ручной очистки между базой данных и рендерингом карты, поскольку они тесно связаны между собой, и карта стремится быть актуальной.

В общем случае вам не нужно «привязывать» как таковой, поскольку исходные данные OSM организованы топологически - например, полигон (= путь OSM) определяется через список индексов узлов (а не напрямую их координатами) - поэтому, если начальный и конечный индексы совпадают, это считается замкнутым многоугольником. В противном случае это ломаная линия (как дорога).

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

1. Существует несколько способов их определения (просто посмотрите на спецификации). Разные люди используют разные правила.
2. Правила неявные - вам нужно прочитать вики-документы OSM, чтобы понять, как с ними обращаться.
3. Если вы используете извлечение данных OSM, некоторые части мультиполигона могут отсутствовать (поскольку они географически не находятся в штате Миссури). Поэтому вам нужно найти способ закрыть многоугольник водоема (либо обрезать его с помощью государственной границы, либо вручную закрыть его с помощью какого-либо инструмента с графическим интерфейсом).

Да, есть и другие проблемы с данными. Главным образом они проистекают из самой природы отображения OSM: разные люди отображают вещи по-разному, и нет никаких установленных правил, как это сделать. Это более или менее самоорганизованная анархия;)

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

Если вы используете исходную схему базы данных из osm2pgsql, у вас есть соответствующие модели данных osm «закрытый путь» и «мультиполигон-отношение», преобразованные в полигоны и помещенные в таблицу с именем planet_polygon. Пути и узлы находятся в «planet_line» и «planet_point». Вы можете получить доступ к этим таблицам через Quantum GIS и экспортировать их непосредственно в шейп-файлы. Вы также можете выполнять SQL-запросы из Quantum GIS для фильтрации данных.

Я бы не использовал осмос для этого. У него нет обработки многоугольника, как у osm2pgsql. Осмос хранит данные таким же образом, как с ними справляются вкладчики (узлы, пути и отношения). Это не подходящая схема базы данных для рендеринга.