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