Agenzia mobilità ambiente territorio/AMAT per Milano

From OpenStreetMap Wiki
Jump to navigation Jump to search

Inquadramento del progetto

Introduzione

Il Comune di Milano vuole realizzare il portale infomobilità nell'ambito dell'ecosistema digitale E015, allo scopo di fornire mashup di dati e servizi integrati al cittadino in vista di Expo 2015. AMAT dovrà fornire i dati statici sulla viabilità a supporto delle applicazioni del portale che verranno realizzate da Engineering (ad esempio il routing multimodale).

Alcune delle applicazioni di routing e WebMapping che verranno realizzate nell'ambito del portale saranno basate su dati OpenStreetMap.

Nell'ambito di queste attività nasce il progetto AMAT/OSM, allo scopo di analizzare la modalità di integrazione dei dati AMAT con quelli OpenStreetMap in modo da beneficiare, da un lato, delle informazioni specifiche e validate sulla carta tecnica del Comune, e dall'altro, degli aggiornamenti e dei controlli costanti operati dalla community OSM, oltre che del motore di routing basato su OSM (OSRM).

Riferimenti normativi

Direttiva EU 2010/40 sul popolamento dei dati relativi alla viabilità e alla struttura delle strade da parte degli enti pubblici o dei proprietari delle strade.


Il problema dell'integrazione AMAT-OSM

Confronto tra le strutture

AMAT utilizza sistemi GIS tradizionali (MapInfo, PostGIS, QGIS) per gestire il dato cartografico. I dati vengono suddivisi in "layer" o "tabelle geografiche", ovvero tabelle database con una colonna di tipo geometrico. La struttura viene prefissata per ogni layer. Vengono inoltre gestiti vincoli topologici e di integrità referenziale tra tabelle.

La cartografia OSM non è divisa in dataset o layers; i diversi oggetti inseriti sono distinguibili per mezzo di TAG, e l'uso convenzionale di TAG predefiniti consente di attribuire gli oggetti ai diversi tematismi (es. strade, fiumi, ponti). In questo modo, lo stesso oggetto lineare può rappresentare contemporaneamente una strada e un ponte.

Il primo problema da affrontare quindi è mappare le strutture una sull'altra in modo da rendere automatica la traduzione dei dati. In generale, l'appartenenza di un oggetto OSM ad un layer AMAT può essere determinata dalla presenza o dal valore di alcuni tag; le colonne del layer corrispondono a valori o combinazioni di valori di tag, e viceversa. La corrispondenza così determinata riguarderà solo un sottoinsieme delle tabelle e dei campi AMAT.

Granularità, dettaglio geometrico e distinzione tematica degli oggetti

Nel grafo AMAT, gli archi possono rappresentare:

  • strade
  • tram in sede propria
  • tram in sede promiscua, ovvero strade in cui passano tram e mezzi su gomma.

In questo modo tutti i percorsi dei mezzi pubblici, su gomma e rotaia, sono tracciati su ElementoStradale.

Esiste poi un layer dedicato alla tracciatura dei binari: ElementoTranviario.

Questa modalità di rappresentazione è in apparente contrasto con la pratica in uso in OSM di non mecolare i tag highway e railway. Per una discussione sulla tematica si veda la pagina Agenzia_mobilità_ambiente_territorio/tram.

Confronto fra gli oggetti della rete stradale

Il secondo problema riguarda le convenzioni di disegno e il modello geometrico e topologico utilizzato per la rete stradale. Laddove questi differiscano significativamente, diventa problematico mettere in relazione le rappresentazioni degli stessi oggetti nei due sistemi - ad esempio, lo stesso tratto di strada tra due incroci.

Nel grafo AMAT, gli archi stradali devono essere spezzati in corrispondenza degli incroci a raso. In OSM questo vincolo è assente, ma è perfettamente lecito spezzare gli archi alle intersezioni, e addirittura obbligatorio quando si vuole inserire una turn_restriction all'incrocio. Nello specifico si pensa quindi di poter modificare la rete stradale OSM implementando le regole topologiche di AMAT.

Le way OSM che rappresentano archi stradali possono essere spezzate in corrispondenza di variazioni degli attributi (sosta, corsie...). Lo stesso non avviene nel grafo AMAT. La relazione tra gli oggetti delle due reti si basa quindi sul presupposto che ogni arco AMAT sia composto da una o più way OSM (con tag highway), e che ogni way OSM rappresenti una porzione di uno ed un solo arco AMAT. Una volta materializzata la relazione tra way OSM e archi AMAT, sarà possibile ricostruire la sequenza degli archi OSM utilizzando la segmentazione dinamica, e trasferire attributi da un sistema all'altro.

Questa relazione verrà mantenuta da AMAT in una struttura dati dedicata.

Identificazione degli oggetti

Ogni oggetto OSM (node, way, relation) è identificato da un ID, intero a 8 byte, univoco per tipologia nodo / way / relation. E' possibile che vengano mantenuti gli ID degli oggetti anche a seguito di modifiche drastiche (es. uno split di un arco in due dove una delle due metà mantiene l'ID del padre).

Si tratta oviamente dell'ID della primitiva geometrica: la stessa way può rappresentare una strada ed un ponte, ed è quindi possibile che in una rappresentazione GIS tradizionale il ponte e la strada abbiano ciascuno il proprio ID univoco.

Verifica e certificazione del dato

Sarà necessario fornire al sistema un dato verificato e certificato, creando un filtro tra il dato OSM pubblico e quello utilizzato dal portale.

Si pensa di mantenere le banche dati allineate in continuo, ma di fornire un ID transazione OSM al quale scaricare l'ultima versione di riferimento, per la quale siano state fatte girare tutte le validazioni e si siano risolti gli errori e i dubbi. In questo modo, sarà possibile scaricare in locale i dati OSM alla versione richiesta e lavorare in attesa della prossima versione verificata.

Editing concorrente

Nel caso in cui si lavori su copie offline di OSM, si potranno avere collisioni dovute a modifiche concorrenti.

E' consigliabile limitare il più possibile l'intervallo di tempo che separa lo scaricamento del dato al suo commit su server OSM.

Dati condivisi

AMAT dispone di dati geografici relativi alla mobilità, parte dei quali già pubblicata sul portale OpenData del Comune di Milano, parte ancora da rilasciare. La maggior parte di questi dati derivano da elaborazioni su basi cartografiche fornite dal SIT del comune di Milano (Carta Tecnica Comunale) o da altri uffici comunali (Segnaletica, statistica, toponomastica...):

  • Grafo stradale
  • Piste ciclabili
  • Percorsi dei mezzi sul grafo
  • ...

AMAT è interessata a:

  • Segnalazioni sulle variazioni degli strati già in uso (strade, segnaletica, trasporti) in modo da attivare confronti e verifiche del dato
  • Dati che, pur potenzialmente di pertinenza della pubblica amministrazione, non sono attualmente disponibili per problemi tecnici o politici (pali della luce...)

Piattaforma di condivisione

Non è necessario installare una istanza del server OSM in rete AMAT. Vanno invece sviluppate procedure per:

  • scaricare in locale una copia di OSM (batch)
  • trovare (batch) e visualizzare (GUI) le modifiche effettuate in un certo intervallo, tramite procedure locali o servizi web basati su OSM
  • confrontare le modifiche OSM con quelle AMAT (GUI/batch)
  • integrare i risultati (GUI)
  • effettuare il commit delle modifiche (GUI)


Procedure e software utilizzato

...

Avvisi sulle modifiche in OSM

...

Validatori OSM

...

Scaricamento dati OSM

Si può usare wget per scaricare un XML da uno dei server mirror:

wget -O milano_all.osm http://overpass-api.de/api/map?bbox=9.01,45.32,9.31,45.60

Conversione in:

I tool di spatialite consentono di convertire l'XML scaricato in un DB geografico spatialite.

Editing locale

Serve un ambiente che consenta di modificare contemporaneamente il dato OSM scaricato e altri DB geografici, in modo da poter tenere allineate le modifiche facilmente.

JOSM consente di lavorare molto bene con OSM e di visualizzare altri dati, ma non di modificare dati che non siano OSM.

QGIS con plugin integrato OSM converte OSM in spatialite, ne genera la topologia e consente di lavorare con il dato in quanto gestito come normale spatialite. Rimane da capire se sia possibile aggiornare OSM dallo stesso tool.