[Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici

[Catonano]

Il giorno 14 dicembre 2017 18:40, Aury88 <spacedriver88 a 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 !
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.openstreetmap.org/pipermail/talk-it/attachments/20171214/e43eb25b/attachment-0001.html>