Il giorno 14 dicembre 2017 12:24, Aury88 <spacedrive...@gmail.com> ha scritto:
> quoto tutto e aggiungo il mio dubbio: dove ci potrebbe portare decidere di > mappare con una relazione per paura dei disallineamenti? sono decine i casi > in cui si potrebbero verificare disallineamenti...che dire di tutti quegli > elementi gestiti dallo stesso operator, o che commerciano lo stesso brand o > che appartengono alla stessa catena....tutti casi in cui tra l'altro, vista > la maggior distribuzione spaziale, è molto più facile che i singoli > elementi > vengano mappati da mappatori differenti con value, che dovrebbero essere > comuni, più o meno diversi tra loro... > 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". Più lasciamo che i dati siano non-normalizzati, più li gettiamo nel caos. Vale anche per l'operator e per il brand, sia chiaro! Al momento il caso d'uso più problematico sono i civici; il secondo più problematico sono i CAP e i Comuni di appartenenza. Oggi, per sapere se un certo numero civico sta a Vercelli o a Borgovercelli stiamo guardando se ha la maglia rossa :) > qui non stiamo parlando di qualche elemento più o meno esotico e raro che > quindi può essere gestito mappato unicamente da un elite di mappatori > esperti, ma di un dato maledettamente comune e che deve essere > necessariamente frutto anche del contributo dei meno esperti... il > trascurare questo aspetto per paura di disallineamenti o per avere query di > ricerca sensate e semplici mi sembra onestamente un po' assurdo. e come uno > inesperto non può sapere che o come deve cercare gli addr:street può > benissimo non sapere nulla delle relazioni; tanto più che le relazioni e i > tag ed essi associati, sono nascosti o in secondo piano in un po' tutti > gli editor, specialmente in quelli usati da meno esperti, rispetto i tag > dell'elemento. > 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. 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. 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. 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! 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ì". Ciao, Simone
_______________________________________________ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
