Come vengono elaborati i dati OSM non elaborati per openstreetmap.org

Qualcuno può fornire informazioni su come i dati OSM vengono elaborati o resi per www.openstreetmap.org?

Un esempio specifico ... Ho estratto i dati da un recente set di dati PostGIS planet.osm per un'area nel Missouri. I dati OSM richiedono molta pulizia prima di poter essere resi usando gli stili corretti. Molti corpi idrici sono memorizzati come stringhe di linea che non si chiudono correttamente, quindi devo usare FME per scattare e quindi costruire un poligono in modo da poter avere fiumi / laghi riempiti di blu.

Se guardo gli stessi dati qui, i corpi idrici vengono visualizzati come previsto.

Sto riscontrando problemi nell'identificare tutti i casi in cui è richiesto lo snap (ad es. Quali tipi "naturali" lo richiedono e quale dovrebbe essere la tolleranza). Inoltre, ho il sospetto che ci siano molti altri problemi relativi ai dati che non vedrò mai, poiché ho a che fare con tutto il Nord America.

Chiunque scarica e utilizza i dati OSM passa attraverso il proprio processo di pulizia? Qualcuno sa come questa pulizia è gestita da www.openstreetmap.org? Sembra che il loro processo sia il più informato e il più testato.

Qualsiasi intuizione molto apprezzata.

EDIT : ecco ulteriori informazioni sul mio flusso di lavoro

Un file planet.osm viene scaricato e caricato in PostGIS, usando Osmosi, nello schema pgsql. Quindi estraggo xml OSM da PostGIS per molte piccole aree, usando nuovamente l'osmosi. Ognuno di questi piccoli file XML viene quindi convertito in Shapefile utilizzando FME e le sue ampie categorie di funzionalità. È in questa fase (OSM xml -> Shp via FME) che mi aspetto di convertire le linee in poligoni ed eseguire altre operazioni di pulizia sui dati.

Questi Shapefile vengono offerti tramite GeoServer (e memorizzati nella cache tramite GWC).

Va bene, ci sono alcuni punti di vista diversi e, dato che non è chiaro come stai elaborando i dati inizialmente, immagino che fornirò solo una panoramica.

Esistono due modi principali per utilizzare i dati OSM: utilizzare osm2pgsql , un'utilità precedente che supporta "fogli di stile" e aggiornamenti differenziali e Imposm , un nuovo sistema basato su Python che supporta le trasformazioni di fogli di stile basate su Python. Quando le persone eseguono l'elaborazione, molto è in quel tipo di sceneggiatura. Ad esempio, ecco una mappatura di imposm per osm-bright , il foglio di stile su cui si basa MapBox Streets (informativa / dipendente).

Per essere più specifici di ciò che stai incontrando, è probabile che tu non stia elaborando correttamente le relazioni osm , che, nel modello di dati, sono ciò che consente a più stringhe di linee di formare poligoni. Strumenti come Imposm e osm2pgsql gestiscono generalmente questo tipo di trasformazione dei dati per te.

Per quanto riguarda OSM.org stesso: le modifiche si trovano in un database Postgres "semantico" e vengono continuamente importate in un database PostGIS con osmosi e rese con Mapnik . Non esiste un passaggio di pulizia manuale tra il database e il rendering della mappa, poiché i due sono altamente accoppiati e la mappa mira ad essere aggiornata.

In generale non è necessario "agganciarsi" in quanto tale, poiché i dati OSM originali sono organizzati topologicamente - un poligono (= via OSM), ad esempio, è definito attraverso un elenco di indici di nodo (e non direttamente dalle loro coordinate) - quindi se gli indici iniziale e finale sono uguali, viene considerato un poligono chiuso. Altrimenti, è una polilinea (come una strada).

I corpi più grandi (come Osage river nel tuo caso) sono generalmente definiti attraverso i multipoligoni OSM , che consistono in una serie di modi OSM (linestring) che definiscono la forma e i fori (se presenti). Esistono diversi potenziali problemi con i multipoligoni OSM:

1. Esiste più di un modo per definirli (basta guardare le specifiche). Diverse persone usano regole diverse.
2. Le regole sono implicite: è necessario leggere i documenti wiki dell'OSM per cercare di capire come gestirli.
3. Se si utilizza un estratto di dati OSM, alcune parti del multipoligono potrebbero mancare (poiché non sono geograficamente all'interno dello stato del Missouri). Quindi è necessario trovare un modo per chiudere il poligono del corpo idrico (tagliandolo usando il confine di stato o chiudendolo manualmente con qualche strumento GUI).

Sì, ci sono anche altri problemi relativi ai dati. Principalmente derivano dalla natura stessa della mappatura OSM: persone diverse mappano le cose in modo diverso e non ci sono regole stabilite su come farlo. È più o meno un'anarchia auto-organizzata;)

Io stesso non lavoro mai con dati OSM appiattiti prodotti da osm2pgsql - inizio sempre con dati topologici originali in formato XML OSM e scrivo il codice per elaborarlo nel modulo di cui ho bisogno. Ma poi non uso Mapnik per il rendering, quindi probabilmente sono in minoranza.

Se si utilizza lo schema di database originale di osm2pgsql, i modelli di dati osm correlati 'modo chiuso' e 'relazione multipoligono' vengono trasformati in poligoni e inseriti in una tabella chiamata 'planet_polygon'. Modi e nodi sono in "planet_line" e "planet_point". È possibile accedere a queste tabelle tramite Quantum GIS ed esportarle direttamente in shapefile. È anche possibile eseguire query SQL dall'interno di Quantum GIS per filtrare i dati.

Non userei l'osmosi per quello. Non ha la gestione dei poligoni come fa osm2pgsql. L'osmosi memorizza i dati nello stesso modo in cui i collaboratori li gestiscono (nodi, modi e relazioni). Non è uno schema di database adatto per il rendering.