[Talk-it] Import numeri civici Trento

Andrea Musuruane musuruan a gmail.com
Mer 4 Ott 2017 17:44:19 UTC


Ciao Maurizio,

2017-10-04 10:08 GMT+02:00 Maurizio Napolitano <napoogle at gmail.com>:

> Ciao Andrea
> scusa il ritardo
> Fra week-end, guasto al monitor del portatile, scadenze e Daniele che
> è tornato a scuola
> non ho avuto modo di rispondere.
>

Nessun problema. Abbiamo tutti altri impegni :)


> > Vi consiglio di seguire il seguente template perché contiene molte delle
> > cose che devono essere discusse per un import.
> > https://wiki.openstreetmap.org/wiki/Import/Plan_Outline
>
> Grazie
> Questo proprio mi era sfuggito
>
> >> L'idea è avere un account dal nome trento_import.
> >> In effetti questo Daniele non lo ha scritto.
> >
> >
> > OK. Servirebbe anche un elenco di persone che partecipa all'import.
>
> con questo intendi poi le persone che vanno a fare ulteriori verifiche
> post import?
>

Nella ML di import verificano che chi vuole fare un import abbia la
necessaria esperienza (quanti changeset, ecc).

Ogni tanto capita (a me è capitato) che facciano anche pelo e contropelo su
questioni importanti ma non ben evidenziate nelle guidelines (tipo
verificare che il proprietario degli open data abbia effettivamente il
diritto di distribuire quel data set con quella licenza e non stia
distribuendo dati di terzi senza autorizzazione).

L'uso di un account di import (collegato in genere a un account esistente,
come user e user-import) serve sia per contattare il mapper, sia per
identificare subito il changeset come changeset di import.


> >> appena arriva l'ok lancia lo script
> >>
> >> > E' possibile vedere i dati che verranno importati
> >> > (già trasformati)?
> >>
> >> Lo script il cui codice è stato reso pubblico usa le API di OSM.
> >> Se serve convertirlo in .osm allora si può fare
> >
> >
> > Sarebbe meglio per verificare il risultato della trasformazione.
>
> Sto aspettando Daniele.
> Di fatto è tutto ricostruibile dai suoi script.
> Aspetto però il suo file.
>

OK.


> >> > Come verrà fatta la fase di QA?
> >>
> >> è già stata fatta tutta una analisi - documentata su github (che poi
> >> era il lavoro di stage di Daniele) - di confronto fra i dati erogati
> >> [...]
> >
> >
> > No, non mi è sfuggito. Tralasciando il modus operandi (che è
> interessante e
> > vorrei analizzarlo meglio appena ho tempo), il modo migliore per
> valutare la
> > bontà dei dati è analizzare il file OSM risultante.
>
> Tu intendi vedere di output in overlay sulla mappa osm?
>

Serve il file OSM risultato della trasformazione poterlo analizzare dentro
a JOSM, non in overlay sulla mappa. In questo modo si può verificare, per
esempio, come sono stati impostati i tag, come vanno a inserirsi nel
contesto dei dati esistenti, se la conflation è stata fatta correttamente,
ecc.


> > Inoltre, è altamente improbabile che questo sia il primo import che non
> > necessiti di una fase di QA successiva, perché tutto è stato importato
> > benissimo, i dati sorgente non contenevano errori e anche i dati
> > precedentemente inseriti in OSM erano perfetti.
>
> In realtà abbiamo riscontrato degli errori.
> Si tratta di alcune banalità come i nomi delle vie non espansi (es. Via G.
> Mazzini) o scritti in maiuscolo/minuscolo (es. "via" vs "Via") o male
> interpretati
> (es. Piazza di Fiera vs Piazza Fiera) o con errori di battitura.
>

Questo è assolutamente normale :-) La fase di QA serve anche per eliminare
questi errori (e avere una certa coerenza nella mappa).


> > Alcuni dei problemi che possono capitare sono: strade mancanti in OSM (ma
> > ricavabili dai civici e dalle foto satellitari), strade scritte con nomi
> > differenti nei civici e nella strada (già oggi ce ne sono molti a
> Trento),
>
> Sono andato a guardare per capire a cosa facevi riferimento.
> Daniele ha usato un po' di algoritmi di comparazione dei nomi delle vie.
> Il Comune usa i nomi scritti in maiuscolo e spesso mette il nome abbreviato
> (es. sui nomi di personaggi storici inserisce l'iniziale del nome e il
> cognome
> intero).
> Per fare questo ha prima usato la libreria libpostal di Mapzen che
> normalizza
> i nomi (es. "via XXIV Maggio" diventa "Via 24 Maggio"), poi ha usato la
> distanza
> Levenshtein fra stringhe (che da un indicatore percentuale di quanto
> due stringhe
> si assomigliano e qui ha verificato quelle sotto l'80% di similarità)
> e, infine, ha verificato
> che l'ultima stringa sia uguale.
> Esempio
> nel caso "VIA G. MAZZINI" e "Via Giuseppe Mazzini"
> una volta che ha applicato libpostal e visto che la distanza
> Levenshtein aveva un valore
> alto, è andato a verificato che la parola "Mazzini" fosse presente in
> entrambi i dataset.
>
> Sono andato comunque a guardare il tool di geofabrik per la verifica
> dei civici che hai
> poi segnalato.
> Premesso che i dati presenti sono tutti quelli inseriti
> precedentemente in OSM, i problemi
> di "nomi differenti dei civici e nella strada", di fatto c'erano ma si
> limitano a situazioni con
> un livello di similarità molto alto visto che si tratta di: nomi non
> espansi, "via" scritto con
> la "v" minuscola (questi la maggior parte) o di troppa abbreviazione
> (es. Piazza di Fiera
> contro Piazza Fiera).
>
> Di fatto tutti quelli che, quanto esposto sopra, sono stati ignorati
> per rispetto del lavoro
> fatto dalla comunità.
>

Ho il massimo rispetto per il lavoro che tutti facciamo quotidianamente su
OSM, il problema è che spesso ci dimentichiamo di essere una comunità. Mi
spiego meglio. Spesso dimentichiamo che non siamo gli unici a inserire dati
e che questi devono convivere "bene" con quelli già inseriti da altri e con
quelli che altri inseriranno in futuro. Se un mapper scrive "piazza di
Fiera", un altro "Piazza di Fiera" e un altro ancora  "Piazza Fiera", non
stiamo interagendo bene tra di noi (oltre a non fare un bel lavoro).

Per l'import dei civici in Provincia di Biella, andiamo a sanare questa
situazione, anche se pre-esistente all'import. Il risultato è quello di
avere dati migliori in OSM. E speriamo di riuscirci :-)


> > civici duplicati,
>
> qui il problema è che spesso ci sono civici che non vengono dalla
> georeferenziazione
> dell'etichetta ma dall'attività commerciale.
> Della serie:
> un utente ha inserito il civico visto sulla casa
> un altro utente ha inserito un negozio ed ha assegnato il civico al POI.
> Qui come ci si comporta?
>

In generale il civico è associato all'accesso. Se il POI non ha un civico
specifico per il suo ingresso, IMHO questo non dovrebbe avere i tag addr:*.


> Mentre da un lato capisco l'utilità di avere il POI completo di
> indirizzo, dall'altra ci sono
> attività commerciali che chiudono e - quando chiudono - il risultato è
> che qualche utente
> cancella il POi e, di conseguenza, anche il civico che invece potrebbe
> avere ancora
> la sua utilità.
>

Personalmente se POI e civico coincidono nell'accesso li metto sempre
insieme. Sono geograficamente nello stesso punto.

Se un utente cancella tutte le informazioni dal nodo è errato.


> > civici formalmente corretti (ovvero associati a una strada
> > esistente) ma molto distanti da questa,
>
> Su questo ci andrei un po' piano in quanto, ci sono civici che sono
> distanti dalla via
> principale, ma poi esiste una percorso privato che arriva fino a lì.
> Nella maggior parte vedo che si tratta di edifici.
>

Intendevo un caso come questo (reale, ben esplicativo, trovato a Milano):
https://s1.postimg.org/2apsh4kqf3/Senza_nome.png



> Rimane poi la questione dell'edificio su più vie dove, un lato è più
> vicino ad una strada,
> ma l'ingresso principale è più vicino a quella ufficiale ma, per via
> di percorsi privati appare
> separato dalla via.
> È vero che si possono disegnare i percorsi privati.
> In tal caso bisogna assegnare anche il nome della via al vialetto privato?
>

Direi di no.


> > civici associati a un edificio
> > mentre in Italia sono sempre associati a un'entrata (a Trento ce ne sono
> > diversi come si vede dalla seguente query overpass o tramite osm
> inspector)
>
> In questo caso come proponi di risolvere la questione?
> Aggiungere l'ingresso?
> Sulla questione ingresso principale e secondario?
> Nel senso:
> il Comune mette spesso, come ingresso principale, il cancello ( = il
> primo ingresso
> dell'abitazione) che non è necessariamente detto che sia la porta di
> ingresso.
> Pertanto come agire? Levare il civico dall'edificio e spostarlo sul
> cancello?
>

Esatto, spostare il civico dal building e metterlo sull'accesso (cancello,
porta, ecc).


> > http://tools.geofabrik.de/osmi/?view=addresses&lon=8.10563&
> lat=45.56110&zoom=10&overlays=street_not_found
>
> Qui ho trovato dei problemi su alcune piazze
> Come agire su questa zona?
>

Riesci a farmi un caso più specifico. L'area è un po' ampia e mi sembra ci
siano spesso piazze mappate come parcheggi (caso che riprendi qui sotto).


> http://tools.geofabrik.de/osmi/?view=addresses&lon=11.12688&
> lat=46.07124&zoom=18&overlays=street_not_found
> Il tool dichiara che i civici sono associati ad una via non presente,
> in realtà la via è presente: si tratta di una piazza.
> Il problema è che la piazza è taggata come parcheggio.
>

Personalmente mi sembra che sia mappato tutto correttamente. Non sempre
esiste una highway a cui si può dare il nome della piazza e che passa
attraverso questa.


> In un altro caso
> http://tools.geofabrik.de/osmi/?view=addresses&lon=11.12206&
> lat=46.06687&zoom=18&overlays=street_not_found
> la piazza esiste come relation
>

Idem.

> Prova a vedere quali strumenti sono stati usati per gli altri import (es:
> > osm inspector, no name map, ecc).
>
> Ok
> Attendo Daniele.
> Ora ha finito lo stage ed è tornato a scuola ma so che vuole
> completare il lavoro.
> Come già detto: abbiamo guadagnato un mapper :)
>

:)

Ciao,

Andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-it/attachments/20171004/4531c393/attachment-0001.html>


Maggiori informazioni sulla lista Talk-it