Cómo se procesan los datos sin procesar de OSM para openstreetmap.org

¿Alguien puede dar una idea de cómo se procesan o procesan los datos de OSM para www.openstreetmap.org?

Un ejemplo específico ... Extraje datos de un conjunto de datos reciente de planet.osm PostGIS para un área en Missouri. Los datos de OSM necesitan mucha limpieza antes de poder procesarse con los estilos correctos. Muchos cuerpos de agua se almacenan como cadenas de líneas que no se cierran correctamente, por lo que tengo que usar FME para romper y luego construir polígonos para poder tener ríos / lagos llenos de azul.

Si miro los mismos datos aquí, los cuerpos de agua se representan como se esperaba.

Tengo problemas para identificar todos los casos en los que se requiere un ajuste (por ejemplo, qué tipos 'naturales' lo requieren y cuál debería ser la tolerancia). También sospecho que hay muchos otros problemas de datos que nunca veré, ya que estoy tratando con toda América del Norte.

¿Todos los que descargan y usan datos de OSM pasan por su propio proceso de limpieza? ¿Alguien sabe cómo maneja esta limpieza www.openstreetmap.org? Parece que su proceso sería el mejor informado y más probado.

Cualquier idea muy apreciada.

EDITAR : Aquí hay más información sobre mi flujo de trabajo

Se descarga un archivo planet.osm y se carga en PostGIS, utilizando Osmosis, en el esquema pgsql. Luego extraigo OSM xml de PostGIS para muchas áreas pequeñas, nuevamente usando Osmosis. Cada uno de estos pequeños archivos xml se convierte en Shapefiles usando FME y sus amplias categorías de funciones. Es en esta etapa (OSM xml -> Shp vía FME) que espero convertir líneas en polígonos y realizar otra limpieza en los datos.

Estos Shapefiles se sirven a través de GeoServer (y se almacenan en caché usando GWC).

De acuerdo, hay algunos ángulos diferentes para esto, y dado que no está claro cómo está procesando los datos inicialmente, supongo que solo daré una descripción general.

Hay dos formas principales de consumir datos OSM: mediante el uso de osm2pgsql , una utilidad más antigua que admite 'hojas de estilo' y actualizaciones diferenciales, e Imposm , un sistema más nuevo basado en Python que admite transformaciones de hoja de estilo basadas en Python. Cuando las personas procesan, gran parte está en ese tipo de guión. Por ejemplo, aquí hay un mapeo imposm para osm-bright , la hoja de estilo en la que se basa MapBox Streets (divulgación / empleado).

Para ser más específico con lo que está encontrando, es probable que no esté procesando correctamente las relaciones osm , lo que, en el modelo de datos, es lo que permite que múltiples cadenas de líneas formen polígonos. Las herramientas como Imposm y osm2pgsql generalmente manejan este tipo de transformación de datos por usted.

En cuanto a cómo OSM.org hace las cosas: las ediciones se encuentran en una base de datos 'semántica' de Postgres, y se importan continuamente en una base de datos PostGIS con ósmosis , y se representan con Mapnik . No hay un paso de limpieza manual entre la base de datos y la representación del mapa, ya que los dos están muy acoplados y el mapa tiene como objetivo estar actualizado.

En general, no es necesario "ajustar" como tal, ya que los datos OSM originales están organizados topológicamente: un polígono (= modo OSM), por ejemplo, se define a través de una lista de índices de nodo (y no directamente por sus coordenadas). así que si los índices inicial y final son iguales, se considera un polígono cerrado. De lo contrario, es una polilínea (como una carretera).

Los cuerpos más grandes (como el río Osage en su caso) generalmente se definen a través de multipolígonos OSM , que consisten en una serie de formas OSM (cadenas de líneas) que definen la forma y los agujeros (si los hay). Existen varios problemas potenciales con los multipolígonos OSM:

1. Hay más de una forma de definirlos (solo mire las especificaciones). Diferentes personas usan diferentes reglas.
2. Las reglas son implícitas: debe leer los documentos wiki de OSM para tratar de comprender cómo manejarlos.
3. Si usa un extracto de datos OSM, podrían faltar algunas partes del multipolígono (ya que no están geográficamente dentro del estado de Missouri). Por lo tanto, debe encontrar una manera de cerrar el polígono del cuerpo de agua (ya sea recortándolo con el límite de estado o cerrándolo manualmente con alguna herramienta GUI).

Sí, también hay otros problemas de datos. Principalmente provienen de la naturaleza misma del mapeo OSM: diferentes personas mapean las cosas de manera diferente y no hay reglas establecidas sobre cómo hacerlo. Es más o menos una anarquía autoorganizada;)

Yo mismo nunca trabajo con datos OSM aplanados producidos por osm2pgsql; siempre empiezo con datos topológicos originales en formato OSM XML y escribo código para procesarlos en el formulario que necesito. Pero, de nuevo, no uso Mapnik para renderizar, por lo que probablemente soy una minoría.

Si utiliza el esquema de base de datos original de osm2pgsql, tiene los modelos de datos de osm relacionados 'vía cerrada' y 'relación multipolígono' transformados en polígonos y colocados en una tabla llamada 'planet_polygon'. Las formas y los nodos están en 'planet_line' y 'planet_point'. Puede acceder a estas tablas a través de Quantum GIS y exportarlas directamente a shapefiles. También puede hacer consultas SQL desde Quantum GIS para filtrar los datos.

No usaría osmosis para eso. No tiene el manejo de polígonos como osm2pgsql. Osmosis almacena los datos de la misma manera que los contribuyentes los manejan (nodos, formas y relaciones). No es un esquema de base de datos adecuado para renderizar.