Como são processados ​​os dados brutos do OSM para openstreetmap.org

Alguém pode fornecer informações sobre como os dados OSM são processados ​​ou renderizados para www.openstreetmap.org?

Um exemplo específico ... Extraí dados de um conjunto de dados planet.osm PostGIS recente para uma área no Missouri. Os dados do OSM precisam de muita limpeza antes de serem renderizados usando os estilos corretos. Muitos corpos d'água são armazenados como cadeias de linhas que não fecham adequadamente, então eu tenho que usar o FME para encaixar e depois construir polígonos para que eu possa ter rios / lagos cheios de azul.

Se eu olhar os mesmos dados aqui, os corpos d'água serão processados ​​conforme o esperado.

Estou tendo problemas para identificar todos os casos em que o snap é necessário (por exemplo, quais tipos "naturais" exigem e qual deve ser a tolerância). Também suspeito que existem muitos outros problemas de dados que nunca verei, pois estou lidando com toda a América do Norte.

Todo mundo que baixa e usa dados OSM passa por seu próprio processo de limpeza? Alguém sabe como essa limpeza é tratada pelo www.openstreetmap.org? Parece que o processo deles seria o melhor informado e o mais testado.

Qualquer insight muito apreciado.

Edição : Aqui está mais informações sobre o meu fluxo de trabalho

Um arquivo planet.osm é baixado e carregado no PostGIS, usando Osmosis, no esquema pgsql. Em seguida, extraio o xml do OSM do PostGIS para muitas áreas pequenas, usando novamente osmose. Cada um desses pequenos arquivos xml é então convertido em Shapefiles usando o FME e suas amplas categorias de recursos. É nesta fase (OSM xml -> Shp via FME) que espero converter linhas em polígonos e executar outra limpeza nos dados.

Esses Shapefiles são servidos por meio do GeoServer (e armazenados em cache usando o GWC).

Ok, existem alguns ângulos diferentes para isso e, como não está claro como você processa os dados inicialmente, acho que vou dar uma visão geral.

Existem duas maneiras principais de consumir dados OSM - usando osm2pgsql , um utilitário mais antigo que suporta 'folhas de estilo' e atualizações diferenciais, e Imposm , um sistema mais novo baseado em Python que suporta transformações de folhas de estilo baseadas em Python. Quando as pessoas processam, muitas delas estão nesse tipo de script. Por exemplo, aqui está um mapeamento impositivo para osm-bright , a folha de estilo na qual se baseia o MapBox Streets (divulgação / funcionário).

Para ser mais específico ao que você está encontrando, é provável que você não esteja processando corretamente as relações osm corretamente, o que, no modelo de dados, é o que permite que várias cadeias de linhas formem polígonos. Ferramentas como Imposm e osm2pgsql geralmente lidam com esse tipo de transformação de dados para você.

No que diz respeito à maneira como o OSM.org faz as coisas: as edições estão em um banco de dados 'semântico' do Postgres e são importadas continuamente para um banco de dados PostGIS com osmose e renderizadas com o Mapnik . Não há etapa de limpeza manual entre o banco de dados e a renderização do mapa, já que os dois são altamente acoplados e o mapa pretende estar atualizado.

Em geral, não é necessário "encaixar", pois os dados originais do OSM são organizados topologicamente - um polígono (= modo OSM), por exemplo, é definido por meio de uma lista de índices de nós (e não diretamente por suas coordenadas) - portanto, se os índices inicial e final forem os mesmos, isso é considerado um polígono fechado. Caso contrário, é uma polilinha (como uma estrada).

Corpos maiores (como o rio Osage no seu caso) geralmente são definidos por multipolígonos do OSM , que consistem em uma série de caminhos do OSM (cadeias de linhas) que definem a forma e os furos (se houver). Existem vários problemas em potencial com multipolígonos OSM:

1. Há mais de uma maneira de defini-las (basta olhar as especificações). Pessoas diferentes usam regras diferentes.
2. As regras estão implícitas - você precisa ler os documentos do wiki do OSM para tentar entender como lidar com elas.
3. Se você usar uma extração de dados OSM, algumas partes do multipolígono podem estar ausentes (já que não estão geograficamente dentro do estado de Missouri). Portanto, você precisa encontrar uma maneira de fechar o polígono do corpo de água (cortando-o usando o limite de estado ou fechando-o manualmente com alguma ferramenta da GUI).

Sim, também existem outros problemas de dados. Principalmente, eles se originam da própria natureza do mapeamento OSM: pessoas diferentes mapeiam as coisas de maneira diferente e não há regras estabelecidas sobre como fazê-lo. É mais ou menos uma anarquia auto-organizada;)

Eu mesmo nunca trabalho com dados OSM nivelados produzidos pelo osm2pgsql - eu sempre começo com dados topológicos originais no formulário XML do OSM e escrevo código para processá-los no formulário necessário. Mas, novamente, eu não uso o Mapnik para renderização, então provavelmente estou em minoria.

Se você usar o esquema de banco de dados original do osm2pgsql, os modelos de dados osm relacionados 'caminho fechado' e 'relação multipolígena' serão transformados em polígonos e colocados em uma tabela chamada 'planet_polygon'. Formas e nós estão em 'planet_line' e 'planet_point'. Você pode acessar essas tabelas via Quantum GIS e exportá-las diretamente para shapefiles. Você também pode fazer consultas SQL a partir do Quantum GIS para filtrar os dados.

Eu não usaria osmose para isso. Ele não possui a manipulação de polígono como osm2pgsql. Osmose armazena os dados da mesma maneira que os colaboradores lidam com eles (nós, formas e relações). Não é um esquema de banco de dados adequado para renderização.