[Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
Aury88
spacedriver88 a gmail.com
Gio 14 Dic 2017 17:40:09 UTC
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
Maggiori informazioni sulla lista
Talk-it