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 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), 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... > 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...fino ad allora tutti gli editor non riconosceranno il tuo metodo o peggio lo classificheranno come errore (manca l'addr:street al nodo) 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 > 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) 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. > 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 e la tua proposta di fatto serve unicamente ad evitare l'eventuale problema di disallineamento in caso di eventuale cambio nome della strada. cioè per un eventualità, che se interessa un 1% delle strade è già tanto, io dovrei modificare il 100% di strade rimappando con un sistema più pulito (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) ma più complicato per quasi tutti quelli che contribuicono alla mappa > 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. 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 e attualmente utilizzato in maniera spesso scorretta e parallelamente al vecchio metodo" molti propendono per la prima. > 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 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; 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) 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... e stavo per scordarmi l'ultimo punto: 4) moltissimi non mettono neanche le frecce normali quando servono ;-P 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. 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). 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 ----- Ciao, Aury -- Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html _______________________________________________ Talk-it mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-it
