User:Voschix/OSMIT2014
(Pagina in costruzione)
Ecco la mia presentazione a OSMIT 2014 che presenta, con un pizzico di ironia, alcune mie critiche alla mappatura OSM in Veneto.
La mia intenzione è di lanciare una operazione di risanamento.
La maggior parte degli argomenti è già stato presentato nella mailing list italiana, ma senza nessuna conclusione produttiva.
Appunti di un mappatore viaggiante sulla qualità dati OSM
Sono un mappatore viaggiante
Mi muovo lungo percorsi ciclabili in Italia e in Europa, per la maggior parte del tempo davanti al computer, ma anche in sella della bicicletta, se ho l'occasione.
Utilizzo OSM quando faccio il cicloturista, sia nella fase di preparare un viaggio o una gita, sia per navigare lungo il percorso che avevo preparato al computer.
Sono arrivato a OSM come utente, per la precisione nella preparazione di un viaggio di gruppo Padova-Paris-London nel 2010.
Quando preparo un giro e quando, successivamente, utilizzo le mie foto e tracce GPX per aggiornare la mappa, mi muovo lungo dei corridoi, aggiornando non solo la mia strada, ma anche quello che mi capita di vedere a sinistra e a destra.
Oltre a questo ho inserito i percorsi ciclo-turistici della Regione Veneto (1200km) in due successivi incarnazioni e alcuni percorsi della rete Bicitalia.
Ma non ho mi fatto mapping strettamente territoriale e non ho partecipato in nessun import (per paura di essere troppo principinate per poter farlo bene)
Questa presentazione ha come oggetto la qualità dei dati OSM, e vi racconto alcuni aspetti che mi hanno colpito durante questi viaggi virtuali su OSM con particolare riferimento al Veneto, alcuni seri, alcuni più divertenti, ma tutti da rivedere seriamente.
Il Veneto si stacca dall'Italia?
Guardando la mappa c'è una chiara tendenza del Veneto, o almeno degli edifici in Veneto, di scivolare verso nord-nord-ovest.
Si tratta di un evidente errore di tanti import: non-allineamento di edifici con PCN2006 e tracce GPX degli utenti.
La Guida dice:
| Attenzione È OBBLIGATORIO riallineare tramite le ortofoto PCN2006. Non caricate dati non allineati con queste foto e soprattutto NON DOVETE RIALLINEARE con Bing (troppa differenza con la realtà)!. |
Lo stesso tanti dati di edifici e accessori sono stati importati con scostamenti di 4 metri e più
Gli scostamenti non sono uniformi e variano da posto a posto, ma c'è una generale tendenza verso nord-nord-ovest.
Rimedio?
Richiede un noioso spostamento a mano dalla parte degli importatori stessi.
Esempi
Cominciamo con casa mia (Padova-Voltabarozzo):
https://www.openstreetmap.org/#map=20/45.378634/11.899684
Scostamento PCN2006: 4m verso nord-ovest
[[Image:|thumb|Treviso - scostamento da PCN2006]]Treviso
http://osm.org/go/0IDfMoHeb?m=
scostamento di 5m verso nord-nord-ovest
Rovigo
http://osm.org/go/0IAj7~rJ9?m=
[[Image:|thumb|Rovigo - scostamento da PCN2006]]scostamento di 4m verso nord.
Adria
è soggetto a due “forze” contrastanti: gli edifici scivolano verso sud, ma i landuse (entrambi importati!) scivolano verso nord:
http://osm.org/go/0ICDHO9~_?m=
[[Image:|thumb|Illustration 1: Adria - scostamento da PCN2006]]Gli edifici sono spostati di ca 5m verso sud, ma i landuse sono spostati di alcuni metri verso nordovest
Le strade della fantasia
[[Image:]]Ovvero: utenti che mappano troppo in fretta.
Ci sono alcuni (pochi, per fortuna) utenti che mappano grandi quantità di strade in fretta, ma
- con bassa precisione geometrica (il percorso su mappa è spesso sbagliato anche di decine di metri),
- con falsi collegamenti
- con tag sbagliati (tipicamente strade bianche taggate “unclassified” o “residential”)
Devo aggiungere che ne ho corretto a centinaia, ma non voglio più farlo.
Esempio 1:
Esempio 2: http://osm.org/go/xcb3t37qg-?m=
Questa strada ha la geometria sbagliata e non finisce, ma continua. Si tratta di una strettissima stradina asfaltata.
[[Image:]]
Rimedio?
Gli utenti in questione dovrebbero revisionare il loro lavoro del passato.
Patate o Polenta ?
Ovvero i problemi dei “landuse” importati.
Chi ha importati i landuse spesso non ha controllato se hanno una relazione con la realtà
- sia per quanto riguarda il valore (patate o granoturco)
- sia per quanto riguarda la geometria.
- sia per quanto riguarda la categoria (per esempio centro commerciale al posto di farmland)
Rimedio?
Distinguere fra patate e granoturco è impossibile da foto aeree. Inoltre l'uso del terreno cambia in funzione dei sussidi dell'Unione Europea. Quindi io toglierei sistematicamente i valori troppo specifici. Un vero lavoraccio!
Per gli altri due errori si possono utilizzare foto aeree aggiornate, ma bisogna farlo sistematicamente. E' un lavoro lungo.
Strade di larghezza zero
Spesso i landuse sono incollati fra di loro e strade confinanti, cioè le strade hanno larghezza zero.
Rimedio?
Correggere a mano i landuse in questione.
Strade sotto acqua
[[Image:|thumb|Strade sotto acqua - esempio 1]]Esempio 1
http://osm.org/go/xdV_F6yOh--?m= (in Emilia-Romagna)
Problema sembra con i dati CORINE. Code 5114
[[Image:|thumb|Strade sotto acqua - esempio 2]]Esempio 2
(http://osm.org/go/xdXz4BmEB--?m=&way=223315879)
Noto problemi con l'import in questa zona. I canali includono gli argini e la geometria non è in accordo con le foto PCN.
Il canale
http://www.openstreetmap.org/way/223315879
è troppo largo ed è contiguo col campo http://www.openstreetmap.org/way/223318173/.
Fra i due c'è un argine con una strada agro-forestale (non ancora mappata) in cima, che adesso è sotto acqua.
(qui non trovo riferimento al codice CORINE)
Esempio 3
http://osm.org/go/0ICA0jeX5?layers=D&m=
In questo caso due canali (larghi 12 e 10 metri) si incrociano senza essere fra di loro collegati, con il più piccolo passando sotto quello più largo, ma in OSM condividono il riverbank, che inoltre è molto troppo largo in vari punti.
[[Image:|thumb|Strano riverbank - 1]][[Image:|thumb|Strano riverbank - 2]]
Rimedio ?
Eliminare tutti riverbank prodotti in questo modo e ricominciare manualmente
Faccio riferimento all'import di corsi d'acqua minori taggati come waterway=canal
Il wiki è molto chiaro sulla definizione di waterway=canal:
[[Image:|thumb|Scolo taggato come "ditch" e "canal"]]“Use waterway=canal for man-made waterways used for transportation or also for the largest waterways created for irrigation purposes. “
(l'inglese "canal" non corrisponde all'uso della parola "canale" nel Veneto. )
Esempio dove lo stesso scolo è parte “ditch” e parte “canal” con endering Mapnik:
http://osm.org/go/xdX28yI8H--?m=
L'errore sta nella tabella di conversione (che ovviamente non è stata utilizzata in tutti casi in modo consistente neanche dallo stesso utente come nel esempio.)
[[Image:]]
Il problema preciso è l'interpretazione sbagliata della parola “maggiore”.
Case Fantasma
Tanti edifici sono stati importati senza controllo se esistono ancora
La Guida scrive chiaramente:
“Prima dell'upload finale controllate che:
- Non vi siano edifici presenti che si sovrappongano con quelli presenti nel vostro file. Nel caso siano presenti, tramite Bing controllate che non siano più recenti rispetto a quelli presenti nei dati del veneto. Se si, cancellateli dal vostro file convertito. “
Esempio:
Chioggia - http://osm.org/go/0ICajV00F-?m=
[[Image:]]
Quando avevo sollevato il discorso nella mailing list IT si è sviluppata una discussione un po' bizzarra:
D scrisse:
Vero che bisogna controllare il più possibile i dati prima di importare, però se un mappatore si è preso la briga imparare a fare tutto il processo di trasformazione dati ed è arrivato a coprire un paese intero di edifici (o landuse) e di questi dati un 5% sono sbagliati perchè hanno demolito un vecchio capannone oppure un farmland ora è vigneto, io ringrazio comunque il mappatore e quindi approvo in generale l'import regionale. Ovvio che casi di errori lampanti devono essere evitati ed eventualmente segnalati o risolti direttamente, questo però senza screditare tutto il processo
P rispose a D:
+1
Mia risposta:
Non sono d'accordo per niente. Se dati importati sono sbagliati in partenza di qualcosa come 5% sono spazzatura, se importati senza controllo immediato. Se avessi detto “meno di 1%” sarei forse stato d'accordo, ma 5% è semplicemente troppo.
Le falesie di Venezia
Si tratta di import di muri e bordi di percorsi acque come natural=cliff
[[Image:|thumb|natural=cliff in montagna ed in laguna]][[Image:|thumb|Le falesie della Laguna di Venezia]]In alcune zone con l'import sono stati creati un sacco di falesie (= cliff in inglese, se non sbaglio) che non sono reali. Mi sono accorto per la prima volta di questi artefatti nella Laguna di Venezia dove ne ci sono 185.
Esempio (ways 152544684; 152545253):
[[Image:]][[Image:]]
Ho controllato a campione in Laguna. Sono dovuti al Veneto Import Day di due anni fa. Probabilmente un errore di mappatura dei tag nei dati originali sui tag di OSM. Poteva essere evitato senza problemi. Le “falesie” sono di due categorie: murazzi e normale bordo d'acqua in laguna (non spiaggia). Cioè sono barrier=sustaining_wall o waterway=riverbank.
Streetview
Rimedio ?
La riparazione richiede una verifica manuale di ogni way, prima di assegnarlo alla categoria “riverbank” o “sustaining wall”
La foresta di Monselice
Parlo dell'import indiscriminato di alberi, (e muri, recinzioni, …) senza discriminazione per la loro esistenza o meno (zona Monselice e Colli Euganei), spesso sovrapposti a oggetti pre-esistenti e spesso con posizioni non corrette.
In primo luogo la mia perplessità riguarda la quantità di dettagli importati senza nessun controllo di correttezza e con nessuna possibilità di tenerli aggiornati in futuro.
In secondo luogo, rigurdante gli alberi, si trata per mio avviso di un errore di mappatura: la pagina wiki “tree” dice chiaramente che natural=tree si utilizza per “alberi singoli, spesso significativi”:
Per darvi una idea del problema, ho fatto un confronto Monselice – Oxford (due zone che conosco e che si assomigliano):
Ho fatto una piccola prova su un rettangolo centrato su Monselice :
21840 singoli alberi (nodi con natural=tree)4562 muri (ways con barrier=wall)
2771 recinzioni (ways con barrier=fence)
4308 ways taggati come highway
Una zona simile attorno a Oxford di dimensioni uguali:
307 singoli alberi
1019 muri
640 recinzioni
12195 ways taggati come highway
Rimedio?
Gli utenti in questione dovrebbero fare un revert completo dei loro changeset facendo attenzione di non eliminare alberi o altri oggetti “veri”, cioè oggetti significativi.
Gli alberi che non ci sono
Poi ho notato anche un altro problema di alberi importati: In altre zone ci sono pochi alberi e sembrano stati importati a caso.
Esempio: Isola di Sant'Erasmo nella Laguna di Venezia
http://osm.org/go/0IDmBOpNV-?m=
[[Image:]]
Nel esempio vedo nessun nesso fra gli alberi della mappa e gli alberi nella foto Bing.
(Secondo il source nel changeset sono dati della Regione Veneto importati)
Rimedio?
Gli utenti in questione dovrebbe fare revert dei loro changeset eliminando così i dati falsi
Tracce Aliene?
[[Image:]]Ho notato che una zona (di nuovo Monselice) dove qualcuno ha lasciato tracce GPX che delineano edifici. Offuscano le vere trace GPX e non so come contattare l'autore.
Per me si tratta di graffiti (vandalismo)
Rimedio?
Non so come si fa ad eliminare tracce GPX dal database. Non so come identificare l'autore
Canali re-naturalizzati
[[Image:]] … ma solo sulla mappa.
Un mappatore ha scansionato le foto PCN per produrre riverbanks. Cosi ha convertito i “brutti” canali artificiali in “bei” percorsi d'acqua quasi naturali.
Peccato solo che il risultato ha poco in comune con la realtà.
Rimedio?
revert totale e rifare tutto in modo “tradizionale”
Scaricare il barile a chi viene dopo di noi
Commento Generale
Alcuni importatori di dati e alcuni mappatori hanno deciso di far fare i controlli dei dati inseriti dagli utenti. Il loro concetto è di mettere dati non controllati (cioè potenzialmente sbagliati) in OSM sperando che gli errori siano trovati da successivi mappatori.
A parte il fatto che questa prassi non è in linea con le linee guide per gli import, non avete mai pensato che questo approccio non può funzionare per due precisi motivi?
1) Siamo in pochi
Il primo è ovvio e matematico: se siamo in tutta Italia qualcosa come 400 mappatori attivi (come ho letto da qualche parte) e se buttiamo dentro la mappa dati non controllati in quantità così elevate, è altamente probabile che gli errori non verranno mai corretti.
2) Sono stufo di dover correggere errori intenzionali inseriti da altri
Secondo, e questo è un aspetto umano: se mappare il mio percorso che ho fatto la domenica in bicicletta mi costringe di correggere in continuazione gli errori inseriti intenzionalmente da altri invece di solo aggiungere le cose che ho rilevato io, mi stufo alla grande. Io correggo volentieri e in modo costruttivo errori non intenzionali che uno ha commesso, ma non errori sistematici dovuto a lavoro altrui fatto male.
Commenti specifici
Strade sbagliate
La mappatura al grezzo di strade, spesso con collegamenti sbagliati (tipicamente non esistenti in realtà) hanno un aspetto specifico e importante. Questi errori danno una cattiva reputazione alla mappa perché il navigatore satellitare ti manda su percorsi non percorribili.
(Per essere onesti di questi problemi ne ho trovati anche negli USA, dove sono dovuti agli dati spazzatura del famoso TIGER import)
Import
Gli import sono “landuse”, “edifici”, e “waterways”. Sono tutte e tre categorie cui errori non saltano fuori nel più frequente uso dei dati OSM, cioè per la navigazione in auto. Problemi lungo strade principali si scoprono forse, lungo strade bianche no per il semplice fatto che sono meno frequentate
Import di oggetti che non si vedono nelle renderizzazioni su GPS
Se gli oggetti importati (esempi: alberi o muretti) non vengono visualizzati sulla mappa del navigatore GPS con il quale vado in giro, è ovvio che le probabilità che io corregga un errore di importazione sono minime.
Se una strada ha un percorso sbagliato, mi ne accorgo sul GPS, se ci sono alberi sulla mappa dove adesso c'è un capannone, non mi ne accorgo.
Meno attenzione alla viabilità minore?
Una mia impressione?
Mi sembra generalmente che l'attenzione dei mappatori si concentri sugli elementi più “importanti” della mappa e che gli elementi considerati meno importanti sono mappati con meno cura o mancano completamente.
Per il cicloturista che vuole evitare strade trafficate questo ha l'effetto che le strade che lo interessano, nel caso peggiore, non sono mappati o sono mappati con più errori di geometria, connettività, diritti di accesso, barriere, superficie, larghezza.
In zone dove questi elementi sono mappati bene, gli algoritmi di routing per cicloturisti (tipo Naviki.org) funzionano a meraviglia, da noi invece spesso ti mandano nel bosco, letteralmente.
Conclusione
Sono dell'opinione che gli autori di questi problemi dovrebbero fare un tentativo di organizzare una correzione sistematica e non continuare di fare nuovi import o mappatura con gli stessi difetti.
Documenti di riferimento
Nella pagina wiki Import/Catalogue c'è un link a Veneto Import che porta a una pagina senza contenuto.
Dalla pagina Veneto si trova via Veneto/Guide e documentazione
la Guida per Import dalla CTRN5000/10000 a OSM con SHP-to-OSM
Altri documenti di riferimento: