Ciao Maurizio, 2017-10-04 10:08 GMT+02:00 Maurizio Napolitano <napoo...@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
_______________________________________________ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
