Il giorno 14 dicembre 2017 18:40, Aury88 <spacedrive...@gmail.com> ha scritto:
> Simone Saviolo wrote > > Il giorno 14 dicembre 2017 12:24, Aury88 < > > > spacedriver88@ > > > > ha > > scritto: > > > > Dove ci potrebbe mai portare il decidere di identificare le persone con > un > > codice alfanumerico? Ogni persona ha un nome: non è più semplice scrivere > > il suo nome su tutte le cose che la riguardano? > > > > Fu così che il signor Walter faticò a prendere la pensione, perché i suoi > > contributi erano stati registrati a Valter. Fu così che la povera Jose > > dovette farsi riconoscere in tribunale l'accesso all'università, visto > che > > sul diploma di maturità c'era scritto Iose. E fu così che mio nonno > faceva > > Bosso di cognome mentre tutti i suoi fratelli erano Bossi. > > > > Non lo dico io: da quando esistono i database, anzi, diciamo da un mese > > dopo :) , ci si è resi conto che i dati vanno normalizzati. Le relazioni > > tra entità diverse non possono essere identificate da dati che possono > > cambiare. Se mi taglio i capelli, o se mi vesto di verde invece che di > > rosso, mia moglie o i miei colleghi capiscono che sono ancora io, perché > > non mi cercano come "quello con la maglia rossa". > > ma perchè fermarci li! l'hai detto te no? dobbiamo normalizzare i dati. > creiamo una relazione al posto del tag amenity=bar e un altro al posto > dell'amenity=restaurant e in questo ricordiamoci la relazione per la > a questa obiezione è già stato risposto che amenity=cafe è un tag fisso, mentre name="... è free form Quindi il paragone non regge > cuisine=italian... e continuiamo così per tutti gli altri tag. > non stiamo parlando di dati identificati solo dal loro tag, come può > esserlo > il nome del povero Walter o della signorina Jose o di tuo nonno Bossi, ma > di > dati che hanno una posizione geografica. di conseguenza te li trovi > comunque > a differenza della pensione del signor walter o il diploma della signorina > Jose o del sig. Bossi, tanto è vero che c'è un tool fatto apposta per > scovare errori del genere.... > il nodo che dovrebbe essere associato alla via Mario Rossi puoi metterci > anche via Carlo Conti e, con il tool appropriato, scopri subito che c'è > l'errore e con un altrettanto immediato Ctrl+F trovi gli elementi a cui > puoi > così sostituire il value errato a tutti contemporaneamente... quello che > succederà invece con quello che proponi, se non ben gestito in maniera > comunitaria (non locale), che vuol dire non locale ? > sarà ritrovarti con il value in una relazione e > probabilmente l'aggiunta da parte di qualcun'altro dei tag addr:street ai > nodi da cui l'avevi cancellato... > che vengano applicati de schemi diversi non è necessariamente un errore. Ogni software può seguire uno schema solo o un mix dei due E comunque di errori ce ne sono a milioni Ripetere la stessa informazioni su decine di nodi e poi consentire alla gente di modifficarla sul singolo nodo CERTAMENTE introduce più errori di quanti ne introdurrebbero le relazioni Del resto questo thread è stato aperto appunto per segnalare una situaione di uan strada con decine di errori dovuti a questo schema evidentemente inadeguato. Il copia incolla in questo caso non ha funzionato !! > > > > > Questo è di nuovo un problema dell'editor. Se esiste uno strumento (le > > relazioni) che permette di normalizzare i dati *e quindi migliorarne la > > qualità*, devo usarlo. Se è complicato usarlo nell'editor, l'editor va > > modificato. Se l'editor rimane così, meglio cercarne un altro. > > allora modificalo e fai la proposta forte di un editor in grado di gestire > facilmente il cambiamento che vuoi introdurre... e non desideri nient'altro ? > fino ad allora tutti gli > editor non riconosceranno il tuo metodo o peggio lo classificheranno come > errore (manca l'addr:street al nodo) gli editor non sono la legge. Molti editor sono fatti male. Questo non vuol dire che bisogna mappare male > e temo sia questo il motivo per cui i > casi di utilizzo della relazione ne ho visti parecchi errati o usati in > maniera ridondante (contemporaneità dei metodi di mappatura) con alcuni > casi > disallineati tra quanto indicato sugli indirizzi e quanto indicato nella > relazione > certo. Mantenere cento copie della stessa informazione, come dimostra questo thread, è difficile Per forza che poi ci sono i disallineamenti E questo thread segnala solo UN caso del genere. Chissá quanti altri ce ne sono E comunque se i dati della relazione sono corretti il disallineamento fra i quei dati e quelli sui singoli nodi conta fino a un certo punto perchè un software decente potrà leggere solo quelli nella relazione (che richhiedendo meno lavoro sono pi`affidabili, come testimonia questo thread) e trascurare quegli altri Gli antichi egizi hanno costruito le piramidi con le mani, poi è stata inventata la meccanizzazione > > > Immagina di essere il classico magazziniere in un'azienda privata. Ti > > dicono "da oggi, invece di scrivere un numero sui colli col pennarello, > > devi metterci un codice a barre e poi leggere quello". Tu protesti perché > > disegnare il codice a barre col pennarello è una cosa improponibile, e > > leggerlo è complicato. Cosa fa un'azienda sana? Ti mette a disposizione > > una > > stampante di codici a barre e un lettore ottico, e pure un sistema che sa > > gestire l'associazione codice a barre - prodotto. E a quel punto voglio > > vedere se scrivi ancora un numero a caso con il pennarello! > > > > Beh, in questo caso, l'azienda privata sei tu mappatore, tu sviluppatore, > > tu contributore del progetto OSM. > > e no...qui mi sembra tanto che sia il magazziniere (uno dei cinquanta) che > dice "voglio usare il codice a barre" e poi pretenda che l'azienda o il > collega magaziniere gli procuri il lettore....e che pretenda tutto questo > in > un magazzino in cui è già facile trovare i colli e in cui la (rara) > facile non è, come dimostra questo thread > problematica che verrebbe evitata con il codice a barre può essere > facilmente risolta con il sistema già presente ed utilizzato dagli altri 49 > magazinieri compresi i 5 neoassunti. > sistema che non funziona, come dimostra questo thread > > > Mi sembra che stiamo volutamente tirando > > il freno a mano. D'accordo, open culture, open source, community, tutto > > bello. Ma prima diciamo che vogliamo fare "il miglior database > > geografico", > > poi, invece di fare un database come se fosse un bell'archivio ordinato e > > referenziato, facciamo in realtà una lista di bigliettini, anzi, di > > etichette (tag), e le appiccichiamo sul muro. > > a me sembra il tuo un freno a mano tanto più che la questione è > sistemabile > con un banalissimo Ctrl+F quello che si fa con un banalissimo Ctrl+F è solo un gran casino, come dimostra quest thread > e la tua proposta di fatto serve unicamente ad > evitare l'eventuale problema di disallineamento in caso di eventuale > cambio > nome della strada. No. Si evita anche che la gente scriva un nome della strada diverso su ogni numero civico > cioè per un eventualità, che se interessa un 1% delle > strade è già tanto, ci sono strade molto grosse, con molti numeri civici. Un solo caso può comportare decine di ore di lavoro Tutto per non imparare come funzionano le relazioni > io dovrei modificare il 100% di strade rimappando con > un sistema più pulito Non tutte di botto. Si può cominciare con alcune Quelle che conosci meglio, o a cui tieni di più Quelle con più versioni del nome su ogni civico Man mano, nel tempo, se ne potranno correggere diverse > (per te, io avrei qualcosa da ridire sul trovare parte > di un indirizzo direttamente sull'elemento e l'altra parte su una specifica > relazione a cui appartiene quell'elemento o sul nome dato ad uno specifico > altro elemento della specifica relazione a cui appartiene l'elemento di cui > vuoi l'indirizzo) abitudini > ma più complicato per quasi tutti quelli che contribuicono > alla mappa > Questo denuncia su quanto è complicato è francamente imbarazzante 🙄 Non è complicato affatto. Organizziamo un workshop ? Mapping avanzato: come e perchè si usano le relazioni. Rigorosamente con Josm e Vespucci Ve lo spiego io > > La meniamo sempre che noi siamo meglio di un fornitore commerciale che > > aggiorna o visualizza i dati in base a logiche commerciali. Peccato che > > poi > > noi i dati li inseriamo e li aggiorniamo sulla base di logiche come "se > > uno > > non capisce come fare una cosa, non la si fa". Potremmo scoprire (esempio > > a > > caso) che in Italia ci sono solo una ventina di "Carrefour Market", > perché > > gli altri "GS" ce li siamo persi (magari perché erano scritti "Gs") e non > > abbiamo fatto CTRL+F su quelli! > > e poi magari scoprire che per una simile dimenticanza a quella del Ctrl+F, > uno delle migliaia di mappatori che ha già mappato negli anni alcuni dei 68 > milioni di nodi con tag addr:street o abituato a vedere questi, si è > scordato di controllare che il nodo che non ha addr:street non appartenga > ad > una relazione per l'indirizzo al momento usata si e no in 4 milioni di > indirizzi. > Se se lo è dimenticato lui, se ne accorgerà qualcun altro La gente non sbaglia solo con le relazioni, sbaglia con tutto > inoltre la tua frase è scorretta; il problema non è tanto che "se uno non > capisce come fare una cosa, non la si fa" ma è " tra due metodi dei quali > uno diffuso ed immediato ed uno stilisticamente ineccepibile ma più > complesso, sconosciuto ai più, che apporta miglioramenti in situazioni > anomale e abbastanza rare come dimostra questo thread 🙄 questo thread dimosta che replicare il nome di una strada su molti nodi porta ad un gran casino Il routing da e verso quella stada NON FUNIONERÀ Quello di Google Maps si Altro che diffuso ed immediato > e attualmente utilizzato in maniera spesso > scorretta e parallelamente al vecchio metodo" molti propendono per la > prima. > la "scorrettezza" con cui verrebbero usate le relazioni fa certamente meno danni del replicare i dati col copia e incolla, come dimostra questo thread e comunque, ripeto, che vengano usati due schemi contemporaneamente non è un grave danno > > > > Inoltre, i mappatori meno esperti dovrebbero in seguito diventare > esperti. > > Quando hai fatto la prima lezione di scuola guida non sapevi che dovevi > > accendere le quattro frecce se c'è una coda inattesa... ma l'istruttore > > non > > ha mica detto "tieni, questa è la tua patente, per evitarti difficoltà > ora > > deprechiamo le quattro frecce e siamo a posto così". > > ma qui non stiamo deprecando le quattro frecce...stiamo decidendo di > lasciare il pulsante bello rosso, grosso e al centro del cruscotto perchè > rimanga intuitivo nell'utilizzo e non nascosto nei comandi della leva che > usi solitamente per mettere le frecce (dove starebbe stilisticamente > meglio). e ti faccio notare che > 1) se non impari ad usare le frecce non ti prendi la patente, su osm dal > giorno 0 puoi mappare senza alcun genere di assistenza o limitazione > si peró poi le conseguenze arrivano, come dimostra questo thread > 2) a differenza che nel caso della guida dove la maggior parte dei > neopatentati continuerà ad usare la macchina nei successivi anni, da noi la > maggior parte dei mappatori abbandona dopo il primo anno; > quindi ? facciamo una mappa mediocre così rimangono tutti ? > 3) mentre per la guida c'è una scuola che devi frequentare, per osm non c'è > alcun obbligo e le guide per neomappatori non si addentrano certo nella > questione relazioni (anche perchè sono decine, tutte con logiche diverse e > solo per la questione indirizzi ce ne sono due: la relazione street e la > relazione associatedStreet) > Ripeto: l'obbligo non c'é. Ma questo comporta delle conseguenze: dati mediocri Se voi continuare a mappare non puoi pretendere di continuare a farlo, negli anni, da "neomappatore" Puoi chiedere in lista a qualcuno di crearti una relazione, se tu ti senti imbarazzato, e poi puoi limitarti ad aggiungervi i civici Insomma ti devi far carico della qualità dei dati ! Non puoi pretendere di continuare a mappare per anni da "neomappatore" e riempire la mappa di civici ognuno con una versione leggermente diversa del nome della strada a cui appartiene 😀 Facciamo così: scegli una strada. Fissiamo un appuntamento e facciamo un Google Hangout in cui ti mostro come e perché si usano le relazioni per le strade ! > e devi tenere in considerazione queste cose specialmente per elementi > diffusissimi e in cui quindi è necessaria la collaborazione di moltissimi > mappatori per raccogliere i dati... > ripeto: e quindi ? Facciamo una mappa con 10.000 ersioni del nome di una strada su ogni civico di quella strada ? Cosi non funziona il routing, Google Maps sarà sempre superiore, però noi siamo una comunità aperta Apertura non può voler dire abbassamento della qualità 😕 e stavo per scordarmi l'ultimo punto: > 4) moltissimi non mettono neanche le frecce normali quando servono ;-P > e quindi ? Vedi sopra > > la discussione che fai non è una questione banale...anche non considerando > l'importanza e la diffusione degli elementi toccati qui stai proponendo un > cambio nella logica del database. No. La relazione associatedStreet esiste già. Esiste anche street, che prevedendo i marciapiedi, consente il routing anche per i pedoni e non solo per le macchine Si potrebbero aggiungere le piste ciclabili così consentiremmo il routing anche per le biciclette > da database principalmente attributivo > (uso tag cioè identificazione e raggruppamento degli elementi in base alle > caratteristiche assegnate) a database principalmente relazionale (uso > relazioni, cioè identificazione degli elementi in base al gruppo di > appartenenza) > > e la cosa mi spaventa un po' tanto più che tutto si è evoluto > attorno questa logica compresi manuali ed editor (che appunto danno maggior > risalto ai tag che alle relazioni). Ho guardato il tuo profilo Google Plus. Vi leggo: "Chi ha paura muore ogni giorno, chi non ne ha muore una volta sola" E stiamo qui a discutere di quanto siamo spaventati dalle relazioni ? 😀 > per carità fai pure la proposta a chi e > luogo di dovere e dovesse venire approvata, sarò il primo a cercare di > utilizzare il nuovo metodo...ma onestamente e personalmente come proposta > non mi convince > Invece io dico: usiamo il metodo delle relazioni perché è evidentemente superiore ! Da 4 milioni facciamole salire a 4,2 ! Sarà un ottimo argomento per quando e come qualcuno farà la proposta !
_______________________________________________ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
