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

[Catonano]

Il giorno 15 dicembre 2017 10:42, Aury88 <spacedriver88 a gmail.com> ha
scritto:

> Catonano wrote
> > Il giorno 14 dicembre 2017 23:59, Aury88 <
>
> > spacedriver88@
>
> > > ha
> > scritto:
> >
> >> Catonano wrote
> >> > Il giorno 14 dicembre 2017 18:40, Aury88 <
> >>
> >> > spacedriver88@
> >>
> >> > > ha
> >> > scritto:
> >> >
> >> >> Simone Saviolo wrote
> >> >> > Il giorno 14 dicembre 2017 12:24, Aury88 <
> >> >>
> >> >> > spacedriver88@
> >> >>
> >> >
> >> >> 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
> >>
> >>  a maggior ragione andrebbe normalizzato un tag che deve rimanere fisso!
> >> sono proprio quelli da cui si parte nei database relazionali
> >>
> >
> > non comprendo l'obiezione
>
> la normalizzazione è tanto più importante quanto diffuso (key e value
> uguali) è un tag ...idealmente è proprio dai tag più importanti, quelli
> cioè
> principali, che si dovrebbe cominciare con un processo del genere...e il
> motivo è identico a quello che utilizzate voi come argomentazione a favore
> del passaggio all'uso delle relazioni: se si deve cambiare il tag o un
> merge
> di alcune categorie di elementi allo stato attuale devi andare a pescarli
> (a
> livello globale, non locale quanto può esserlo una strada) e modificargli
> il
> tag (key e/o value) di ciascuno (e in quasi tutti i casi parliamo di
> migliaiai di elementi) con la relazione basterebbe selezionarla e spostarne
> tutti i membri nella relazione corretta (quando si tratta di merge) o
> modificare quella errata modificando unna volta sola il tag...
>
>
> > e invece no
> > Puoi tenere entrambi gli schemi, per un periodo di transizione
> > Facoltativamente
>
>  hai presente quanto è lungo un periodo di transizione se si lascia la
> possibilità di avere entrambi i metodi? il tag amenity=fitness_center è
> rimasto in circolo per anni pur essendo chiaramente nnon conforme agli std
> OSM ed erano poche migliaia di casi con in più la segnalazione di
> errore...nel caso di addr:street la situazione sarebbe peggiore con i nuovi
> inserimenti fatti da neomappatori, ma anche da altri non opportunamente
> informati, che probabilmente usando come riferimento la mappatura già
> presente e largamente più evidente  su qualsiasi editor finirebbero per
> continuare a mappare come hanno sempre fatto senza accorgersi neanche della
> presenza della relazione
>
>
> > Ovviamente quello della relazione
> >  Che siccome deve essere manuteuto una volta sole per tutti i civici si
> > suppone essere corretto
>
>  lo supponi tu, io suppondo invece che il tag addr:street venga modificato
> meno frequentemente, essendo meno evidente, e che di conseguenza i
> neomappatori che non conoscono le regole di stile su osm (es. i nomi non
> abbreviati) apporteranno cambiamenti scorretti sul nome della strada (
> quindi sul riferimento della relazione sostitutiva di addr:street). con gli
> addr:street un errore di distrazione non si perde il nome della strada ne
> il
> nome viene cambiato su tutti i nodi =>posso trovarlo e correggerlo...sulla
> relazione via ferdinando d'aragona che diventa via aragosta rimane via
> aragosta...e tu che non conosci quella via non puoi neache accorgertene ed
> eventualmente segnalarla ad un mappatore locale
>
>
questa idea che errori sui nodi si trovano ed errori sulle relazioni non si
trovano davvero non capisco da dove arrivi

Forse manca un tool per le relazioni

Ma la disponibilità di tool non qualifica la bontà degli schemi

Come dire che siccome manca il tool per le basi dati relazionali ci
accontentiamo del file csv

E comunque anche senza tool gli errori si trovano

Chiedi di essere instradato ad un indirizzo su via erdinando D'Aragona, ti
accorgi che via d'aragona non esiste e vai a guardare la relazione. oaprri
un bug, o scrivi in n forum, o su twitter

Questa idea che le relazioni occultino gli errori che non emergerebbero mai
più non me la spiego


>
>
> > è dimostrato dalle basi dati da 50 anni
>
> un db non vale l'altro...il fatto che ci siano ambiti di utilizzo di
> database in cui il sistema relazionale apporta significativi vantaggi
> rispetto quelli attributivi non significa che tale logica sia vincente in
> tutte le tipologie di database...tanto più in progetti crowdsourced senza
> parametri di selezione/limitazione dei contributi basati
> sull'esperienza...quali sarebbero queste dimostrazioni di DB da 50? per
> caso
> sono database gestiti da gente formata o comunque non contributori casuali?
> bene, non centrano nulla con OSM.
>

Bene, questo vuol dire che le applicazioni consentite da quei db non
centrano nulla con quelle che saranno consentite da osm

Un mare di gente che produce montagne di dati di dubbia qualità non sono
questo grande successo

Certo non lo era per chi studio i db relazionali

> rimane il fatto che scrrivere lo stesso attributo suu nodi diversi apre
> > alla possibilità di sbagliare quell'attributo su ogni nodo su cui è
> > scritto
> > La ridondanza costa
> > Copia incolla o no
>
>  apre a possibilità di sbagliare attributo su alcuni nodi o di sbagliarlo
> per tutti i nodi se si parte sbagliando e avrei in entrambi i casi la
> possibilità di fare un confronto con la strada. con la relazione apri la
> possibilità di dover sbagliare una volta sola allineando tutti gli
> indirizzo
> con dati sbagliati senza potersene accorgere...


senza potersene accorgere... 🙄


> la ridondanza costa ma è
> spesso proprio la ridondanza il motivo della sicurezza di moltissimi
> sistemi. non voli su alcun aereo che non abbia almeno ridondazia doppia per
> componenti critici;


quelli critici, non ogni molecola


> secondo te per quale motivo? per far costare di più
> l'aereo?
>

vabbé



> > in discussione è ANCHE il caso chhe qualcuno cambi il nome della strada
> su
> > alcuni nodi erroneamente
> > Se i nodi sono iin una relazione può danneggiare il nome della strada una
> > volta sola
>
>  una volta sola e in maniera potenzialmente definitiva visto che nessuno se
> ne accorge...


nessuno se ne accorge 🙄

dall'altra OSM inspector mi dice subito che li ce un problema e
>

e allora ofrse bisognerebbe adeguare OSM inspector e chiedergli di
richiamare l'attenzione quando un attributo viene editato su una relazione

La disponibilità di tool non è una condizzione naturale o una fatalità


posso contattare un mappatore locale per avvisarlo o andare nello storico e
> vedere come è cambiato il nome e magari determinare quale dei due sistemi
> di
> denominazione è quello corretto. i ldisallineamento non è un problema
> grosso
> in quanto facilmente identificabile e riparabile come dimostra la
> discussione. il fatto di basare tutti gli indirizzi sui nomi di una strada
> (uno degli elementi più toccati da inesperti) senza possibilità di
> accorgersene per me lo è eccome.
>

senza possibilità di accorrgersene 🙄



>
> >> 5) la soluzione è stata immediata consigliata già alla seconda risposta,
> >> la
> >> vostra proposta richiede un cambio di stile che si deve applicare
> >> globalmente a tutti i nodi già mappati (68 milioni)
> >
> >
> > Non tutti immediatamente, ovviamente
>
>  quanto tempo vorresti dare ad una transizione del genere? un mese? un
> anno?
> un milione di anni? considera che se non hai tool per la QA, il render
> predisposto e buona documentazione avere un periodo di transizione
> significa
> che in quel periodo si continuerà a mappare mantenendo l'attuale
> proprorzione tra vecchio (ogni 5 con relazione 68 con addr:street) e
> indovina in quanto tempo si finisce in queste condizioni? considera poi che
> se uno stile è usato proporzionalmente poche volte non gli si fanno ne tool
> ne render  in quanto troppo di nicchia, disincentivando di fatto il
> passaggio al nuovo stile. ecco perchè va proposto alla comunità quello che
> dite.
>

proporremo alla comunità


>
>
> > ma non dannose quanto i disallineamenti
>
>  esatto, sono più dannose.
>

sono _meno_ dannose. Non ai colto l'argomento tecnico, come quualcun altro
ha osservato


>
>
> > ?? Josm crea le relazioni semza problemi
>
>  lo so perfettamente...le relazioni sono elencati nel pannello relazioni,
> in
> cui devo poi schiacciare l'edit per aprirre il popup con editor di
> relazioni
> e  poter finalmente associare i ruoli...quando l'edit dei tag è subito a
> destra nel pannello etichette...e questo tralasciando il problemuccio che
> JOSM viene usato neanche dall' 8% degli utenti e che viene usato comunque
> per lo più per fare editing sui tag e non sulle relazioni (una relazione
> ogni 1000 tra way e nodi )
>

Forse bisognerebbe chiedere agli autori di tool di aprrire n editor di
relazione quando una rrelazione è presente

Per esempio, se un nodo ha un attrributo addr:street e c'è una relazione
con nome simile, alla qual appartengono magari nodi vicini...

Non la azzeccherà nel 100% dei casi, ma sempre meglio che far ffinta che le
relazioni non esistano

Invece di considerare il panorama dei tool disponibili come una fatalità

Altrimenti quello che succede è che con l'argomento chhe i tool sono quello
che sono li si incentiva a rimanere quello che sono


>
> > non capisco l'obiezione
> >
> > Io ho usato Josm
> >
> > Ho creato la relazione a manina e ci ho messo i civici, sempre a manina
>
>  nostalgia del periodo egizio vedo xD
>

ha parlato quello del copia e incolla


> non è il problema creare la relazione, ma il trascinarci dentro magari
> centinaia di nodi a manina,


beh a manina si fanno tante cose. A cominciare dall'inserire i civici tout
court


> uno ad uno


magari a gruppi ? Magarrri non tutti in una volta ?
10 oggi e 5 domani ?


> (perchè se sei contrario al Ctrl+F e
> all'addr:street , per coerenza, non dovresti neache usarlo per selezionare
> i
> nodi da aggiungere alla relazione)


Ctrrl-F lo uso più volentieri per realizzre una souzione che prometta di
non doverlo riutilizzare in futuro


> o trovare nodi che ci si scorda di
> inserire nella relazione
>

Senza relazioni evidentemente non ci si scorda niente


>
>
> > Cos'ha Josm che non va ?
>
> JOSM non ha nulla che non va...non è però ne immediato per gran parte dei
> mappatori (il 92%) ne l'editing di reazioni è immediato quanto lo è
> l'editing dei tag...


Ok, mancano i tool.


> quindi il costringere ad usare editor relazioni
> all'interno dell'editor JOSM per un elemento diffussimo e capillare,  il
> tutto per avere vantaggi irrilevanti in caso di eventi di per se rari


"irrrrilevanti" e "rari" secondo quali misure ?

Di nuovo, ti sfugge l'aspetto tecnico

Qualcun altro ha osservato che l'evento non è così raro come dici tu



> e il
> tutto perdendo la possibilità di identificare l'errore e correggerlo dato
> dalla ridondanza non lo trovo furbo.
>

Perdendo la possibilità 🙄


>
> > si pò fare gradualmente con gli strmenti che ci sono
> > Del resto la relazione associatedStreet è approvata, mi pare
> >
> > Gli strumenti verranno col tempo
> >
> > Questa ossessione che la cosa debba essere immediata e massiva da dove
> > arriva ?
> >
> > Cosa, in osm, è stato fatto immediatamente e in massa ?
>
>  la spiegazione te l'ho già data portandoti il caso del
> amenity=fitness_center palesemente errato eppure diffusissimo finche non ci
> siamo messi a fare edit meccanico "di massa". e parlavamo di sole poche
> migliaia di casi che però continuavano a generare confusione e a indurre
> molti mappatori a continuare ad usare lo stile errato. tu stai proponendo
> un
> cambiamento che in tutti gli editor rimane nascosto,


Il problema sono gli editor, non lo stile



> che ha una diffusione
> irrisoria


che rimarrà tale, se l'atteggiamento è questo


> sperando che questo stato di transizione si sistemi da se con il
> tempo...se conoscessi le meccaniche dei contributi di osm sapresti che una
> cosa del genere significa semplicemente ritrovarci tra 10 anni con ancora
> l'attuale proporzione di civici  mappati nei vari modi e di conseguenza
> senza che si sia reso necessario fare strumenti ed editor adatti per l'edit
> di uno stile di nicchia.
>

Per cui non poviamoci nemmeno. Se la vedrà chi dovrà processare ogni nome

È chiaro che le relazioni sono un'opzione; ma mi colpisce l'atteggiamento

> Per creare relazioni e aggiungervi elementi c'è gia tutto 🙄
> >
> > Tranne la buona volontà
>
>  no è la buona volontà il problema, ma la volontà di fare le cose fatte in
> maniera errata...tu proponi qui un cambiamento radicale nello stile di
> mappatura di OSM con lo spostamento da uno stile attributivo ad uno
> relazionale su un elemento diffusissimo e globale sperando che la
> situazioni
> si sistemi da se con il tempo perchè ne hai diiscusso nella
> ML-Italiana...


No, perchhé è così chhe si organizano i dati

Ogni soluzione ondata su dati con la giusta densità informativa costerà meno

quello che succederà te l'ho già spiegato ed è terribile.
> facevano casino poche migliaia di elementi taggati male (cioè no, non male,
> nulla impediva di usare anche quel tag, semplicemente il problema era la
> presenza di un altro tag rispetto quello concordato) figuriamoci questo.
> ripeto si vada a discuterne nella sede opportuna per poter agire
> correttamente.
>

Discuteremo


> > come giá scritto, non sarebbe un grande danno
>
>  come già scritto lo sarebbe eccome visto che determina fasi di transizione
> di fatto infiniti e che per interrompere necessiterebbe di meccanical edit
> "massivi" se non si parte già con una base ampia e strumenti e tool
> adeguati
>

le relazioni sono già una opzione disponibile
La transizione è già in corso.
Osteggiata



> > forse perche non è lo strumento giusto ?
>
>  ma apunto tu cosa usi per trovare strade con nome errato nelle relazioni?
>

Josm. Apro la relazione e la guardo

Oppure un instradatore. Gli chiedo di essere instradato verso un indirizo
di na strada fatta con una relaione e vedo che succede

Poi ho già proposto una integrazione da chiedere a questo OSM inspector e
un'altra per altri editor

Non è che senza OSM inspector non si possano fare basi dati geografiche


> > Se non conosci i luoghi il problema non sono le relazioni
> >
> > Comunque io editerei solo la relazione.
> >
> > Anche se sbagli chi ti correggerà dovra farlo na volta sola 🙄
>
> che strano, anche io edito una volta sola selezionando tutti gli elementi
> con il tag errato
>

Allora chi ha inventato le basi dati relazionali non ha capito una fava
Complimenti



>
>
> > e il lavoro per mantenerli questi 68 milioni di nodi ?
> >
> > Forse con lo stesso lavoro si potrebbe fare di più ?
>
>  non saprei...onestamente finchè non so qual'è l'incidenza dei
> disallineamenti a seguito di cambi nomi sulle strade non posso dirlo...


a me pare che la sottostimi, come ha osservato qualcun altro


> posso
> dire però che di sicuro il passaggio al nuovo stile il lavoro comprenderà
> almeno il cambiamento su 68 milioni di nodi e che anche così non si potrà
> evitare i cambi errati del tag name sulla strada
>

il requisito che il passaggio debba essere immediato lo hai inventato tu ed
è arbitrario
Le relazioni sono già una opzione, siamo già nel coso di na "transizione"


> posto che, salvo editwar, il nome delle strade non cabia spesso,


il problema, come osservato, non è solo che una strada cambi nome


> perchè il
> passaggio al nuovo stile sia vantaggioso rispetto al mantenimento
> bisognerebbe avere allo stato attuale il 50% delle strade con nome errato o
> non allineato con gli addr:street
>

Ti sfugge il lavoro fatto per il mantenimento chhe potrebbe essere fatto su
altro
Il vantaggio del passaggio alla normalizzazione è evidente, le misure e gli
studi furono fatti all'epoca loro



>
>
> > dovendo ripetere gli stessi edits su molti nodi si è più esposti al
> > rischio
> > di errore, oltrre al rrischhio di diver riparare più volte gli stessi
> nodi
> > o lo stesso nome di strada
>
>  attualmente per i cambiamenti in caso di cambio nome l'edit è uno solo ed
> è
> applicato sull'intero gruppo che viene estratto grazie al nome non
>

il cambio nome NON è il nostro caso



> aggiornato (quindi due passaggi per gruppo di nodi), mentre per la
> relazione
> è una selezione della strada (quindi un solo passaggio per gruppo di nodi)
>
>  nel caso di nuovi inserimenti l'edit è sui soli civici (se decidi di fare
> copia incolla) o comunque presuppone un due edit  per nodo(civico e street
> quindi due passaggi per nodo) contro, nel caso delle relazioni, di un edit
> (civico) e di un aggiunta con associazione di ruolo alla relazione (quindi
> di fatto 3 passaggi per nodo)
>

Che ne risparmieranno chissà quanti in futuro

un editor può sempre essere migliorato in modo che rrichhieda 2 passaggi
anche per usare una relazzione

Gli strumenti si fanno sopo aver deffinito i concetti, non il contrario


>
> >> questa frase non meriterebbe neanche una risposta (tanto più che ho già
> >> risposto in proposito a quanto per me sia complicata la relazione (a
> >> proposito quale delle due) per gli indirizzi) vai a fare il corso a chi
> >> serve veramente cioè ai nuovi arrivati......io mi godrò la caduta nella
> >> curva dei contributi
> >
> >
> > che ne so. Tutti a dire che l'accessibiltà è importante, che le relzioni
> > la
> > abbassano 🙄
>
>  anche questa tua risposta la dice lunga...u
> ti basta che uno, nel considerare il fatto che la maggior parte dei
> mappatori non sono esperti e non lo diventeranno mai (visto il grado di
> ritenzione), cerchi di far portare avanti una discussione che tenga in
> considerazione i neomappatori perchè debba essere anche lui  per forza di
> cose un neomappatore? il fatto che tu non lo sappia non ti obbliga a
> supporre ne ti esime dall'utilizzare, prima di parlare magari a vanvera,
> uno
> dei tanti ed ampiamente conosciuti strumenti che ci sono nella comunità osm
> per sapere anche con chi si sta parlando.


Siamo al tu non sai chi sono io


>
> e sì, proprio perchè non sono un
> neomappatore so che l'accessibilità è importante e so che la relazione
> abbassano questa accessibilità come tutte le statistiche dimostrano
>

peccato che "l'accessibilità" abbassi la qualitá dei dati, come dice la
teoria consolidata


>
>
> > Non tutto è un fallimento
> > Ma secondo voi lo sono solo le relazioni
>
>  e chi lo avrebbe detto? noi no di certo, mentre tu parli di esperienza
> fallimentare viste le conseguenze che sarebbero arrivate dall'avere
> addr:street duplicati. io ho detto al massimo che è potenziamente
> fallimentare il tentare di far diventare osm un database professionale e
> relazionale quest'ultimo punto specialmente se applicato per elementi
> diffusi come i civici che già adesso soffrono di penuria di contributi.


Ecco questo mi pare un punto centrale

Se Osm deve ben gardarsi dal diventare una base dati "professionale" allora
dobbiamo intenderci su che genere di basi dati è



> ma
> in realta mi sono limitato a dire che semplicemente la proposta va fatta
> nella sede opportuna perchè non diventi un fallimento con la fase di
> transizione.
>

e va bene, messaggio ricevuto


>
>
> > come è stato già scritto se una strada si chiama "via Cavour" non si puó
> > dire che sia sbagliata
> >
> > Se OSMinspector ti segnala che su altri nodi si chiama "via Camillo Benso
> > Conte Di Cavor" quell'errore succede SOLO perche l'attributo è ripetuto
> > inutilmente
> >
> > Se ci fosse una relazione col nome della strada "via Cavour" nessuno
> > strumento rrileverebbe nessun errore perche non c'é nessun errore
> >
> > Invece con strumenti come OSMinspector troverete tanti "errori" quanti
> > differenze nel nome della strada su ogni nodo
> >
> > Lavoro sprecato 🙄
> >
> > Però molto accesibile
> >
> > Molti degli errori che rilevate con OSMinspector non sono errori, sono
> > generati dal vostro stile apprezzzatissimo
>
>  no, il problema è se scrivi cavuor invece di cavour sulla strada con la
> relazione...buon divertimento ad identificarlo.
>

🙄

OSM inspector usa una ridondanza (lo stile apprezzatissimo) per avere una
> base da normalizzare e usare come media/moda per trovare gli scostamenti.
>

AAhhhh ma se questa è la premessa allora siamo daccordo.

Cioè chi usa i dati deve sapere che dovrá farsi carico della
normalizzazione

Devo dire che avevo capito una cosa diversa


> non è il fatto di avere lo stile "apprezzzatissimo" ad essere un errore
> tanto è vero che se il name della strada e il value addr:street dei 10
> milioni di civici ad esso associati corrisponde non ti segnala niente.


con 10 milioni di civici qualcuno prima o poi si accorgerà di qualcosa 😀

Non riuscirà a farsi instradare, non troverà il suo bar preferito o casa
sua...
E dai, su. OSM inspector non è l'unico mezo al mondo

il
> 99% dei casi tutti i nodi presentano lo stesso errore e si corregge in 10
> secondi
>

Il 99% ? Siamo sicuri ? 😀


>
>
> > l'errroe non evidenziabile non esiste
>
>  devo usarla anche io questa cosa...la polvere sotto il tappeto non esiste
> xD
>

Confermi che gli aspetti tecnici ti sfuggono



> > con OSMinspectorr lo trovate perche duplicate i dati inutilmente
>
> "si trova" "inutilmente"...beh, almeno per una cosa è utile e permette di
> identificare sia molti errori sia i disallineamenti
>

molti dei quali non sono errrori. I disallineamenti non esisterebbero


>
>
> > Se il nome della strada fosse presente una volta sola, nella relazione,
> > non
> > ci sarebbe nessun errore.
>
> salvo nome errato in quel caso sarebbe un errore non rilevabile che per te
> equivale a dire non avere l'errore xD
>

non rilevabile 🙄



> > E tu sei sicuro di comprendere il senso di ciò che OSMinspector ti
> segnala
> > ?
>
>  io abbastanza, a questo punto  il mio sospetto è che sia tu a non
> conoscerlo o saperlo usare..
>

Io non l'hho mai usato e da come lo avete descritto direi che non ne vale
la pena.
È evidentemente no strumento ffondato su concetti deboli o pensati per
altri casi

Che tu lo abbia usato molto è un problema tuo
E di Osm


>
>
> > La teoria delle basi dati esiste per una ragione
>
>  come anche la statistica, il calcolo del rischio  e della reliability su
> sistemi in parallelo e in serie...così come è previsto quando non hai una
> ridondanza nel dato di avere database ridondanti per poter trovare
> errori...da me non si va da nessuna parte e si rischia addirittura il
> carcere se le cose non sono salvate in almeno triplice copia
>

Va bene, se mi garantisci chhe ogni nome viene scritto solo tre volte mi
sta bene 😀

>
>
>
> > Ma a prescindere dall'analisi, reiterrare lo stesso dato moltiplica la
> > possibilità d'errore
>
>  la possibilità di errore determinata da reiterazione non è data da una
> moltiplicazione, ma da un esponente...
>

a maggior ragione andrebbe evitata

comunque l'esponenziazione cos'è ?
una moltiplicazione reiterata




>
>
> > Oltre al fatto che vengono considerati "errate" versioni del nome della
> > strada solo perchhe difformi da quelle di altri nodi, mentrre se il nome
> > dlela strada fosse scritto una vlta sola nella relazzione, quello che
> > viene
> > segnalato come errore da OSMinspector sarebbe perfettamente valido
>
>  xD non avrei saputo scriverlo meglio...
>

ecco appunto.

Correggi errori che errori non sono e sei pure contento
Questo mi conferma che Osm serve a offrire un giochino agli entsiasti



>
> > Il problema non sono gli strumenti, sono le idee
>
> sono d'accordo.
>

🙄

> già.
> >
> > Invece la mia proposta è evidentemente vantaggiosa
> > Il fatto che associatedStreet sia approvata dovrebbe suggerirti qualcosa
>
> come anche il fatto che sia semisconosciuto e praticamente usato solo per
> poche migliaia di strade dovrebbe suggerire a te qualcosa, così come le
> statistiche di contributo, di utilizzo degli editor, di diffusione di
> tipologie di elementi o i precedenti nei casi di cambi di tag....


mi suuggerisce la mancanza di consapevolezza della comunità Osm


> così come
> dovrebbe  suggerirti qualcosa la qualità della proposta che parte con un
> errore stilistico già dal value del type per finire che non mi sembra sia
> stata approvata ("associatedStreet relations have been used by some mappers
> as an alternative to addr:*-Tags" = qualcuno ha cominciato semplicemente ad
> usarlo) ma semplicemente non deprecata (per 5 voti di scarto e nascondendo
> la votazione dentro la pagina di discussione della voce medesima...tutto
> assolutamente irregolare)...si in effetti suggerisce molte cose...ed è
> anche
> questo il motivo per cui preferisco la relazione street
>

Ah la preferisco pure io !


>
>
> > ma a quale costo ?
> > Al costo di lavoro evitabile ?
> >
> > Cosi scoprirono gli inventorii dei database, inutilmente, anni fa
>
>  ci sono ambiti dove la velocità di inserimento è fondamentale, altri dove
> lo è l'organizzaizone, altri dove lo è la ridondanza ed altri dove lo è
> l'inclusività... continui con la storia di un database vale l'altro.
>

in effetti è possibile che abbia frainteso cosa sia Osm



>
> > bisognerebbe vedere quanto lavoro è costato
>
>  mi è costato meno di quanto lo sarebbe stato creare una relazione per
> strada e trascinarci a mano ogni singolo civico...


quanto lavorro è costat il MANTENIMENTO fino ad oggi, non la creaione 🙄


> allo stato attuale il
> passaggio al nuovo stile sarebbe molto veloce perchè potrei sfruttare gli
> addr:street per selezionarli e trascinarceli in blocco...e gli addr:street
> li ho avuti a gratis tranne il primo civico di ogni strada
>

vedi ?


> > Quanti errori segnalati da OSMinspector sono stati corrretti che non
> > sarebbero esistiti per nulla se i nomi delle strade non ofssero stati
> > inutilmente ripetuti ?
>
>  tutti visto che con il nuovo stile OSM inspector non trova errori anche
> palesi sul tag name...
>
>
> >>
> >> > Se voi continuare a mappare non puoi pretendere di continuare a farlo,
> >> > negli anni, da "neomappatore"
> >>
> >>  grazie per avermi aperto gli occhi...da domani mi mettero a mappare in
> >> maniera inutilmente complessa per dimostrare la mia esperienza...
> >>
> >
> > l'utilità della mia proposta è stranota ed è probabilmente la ragione per
> > la quale esiste associatedSteet
>
>  wow...esiste anche la pagina su gli addr:* ripetuti cosa fai? due pesi e
> due misure?
>
>
>
> > io sto sostenendo na tesi consolidata dalgi anni 60
>
>  su che tipologia di database, con che genere di inseritori ed
> utilizzatori...un database non vale l'altro
>

se la condizione di utilizzo dei dati di Osm è di sapere che lo standaard
viene abbassato per consentire agli entusiasti di giocare bisognerebbe
dirlo con un po più di evidenza



>
>
>
>
>
> >>
> >> > 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 !
> >>
> >>  veramente...in estremo imbarazzo...
> >>
> >
> > è reciproco
>
>  mi fa piacere sapere che sai riconoscere di aver fatto una figuraccia e
> provi imbarazzo per questo. non ti preoccupare, non me la sono presa.
>

vabbé



>
>
>
>
> >> > ripeto: e quindi ? Facciamo una mappa con 10.000 ersioni del nome di
> >> una
> >> > strada su ogni civico di quella strada ?
> >>
> >> addirittura ogni nodo aveva un nome differente?
> >
> >
> > 10.000 versioni del nome differente. La strada di civici potrebbe averne
> > 15.000 o di più 🙄
>
> wow, e ricordiamocelo, tutto con un semplice copia incolla che a quanto
> pare
> da te incolla sempre qualcosa di diverso xD
>

no vabbé
Il copia e incolla contro la normalizazione 😞



>
> >>
> >> > Apertura non può voler dire abbassamento della qualità 😕
> >>
> >> mai detto e infatti abbiamo un ottima mappa già adesso...
> >
> >
> >
> > non con la stessa estensione di Goole Maps
> >
> > Forse perchhe si lavora su cose non indispensabili ?
> > Magari anche ?
>
>  non si lavora, si contribuisce. e per molte zone la mappa osm ha maggiore
> copertura della mappa google che, notiziona, è fatta per buona parte non da
> inserimenti diretti ma da import di db fatti da altri con decenni di
> anticipo sull'uscita di queste mappe online....certo poi non vorrai dare la
> colpa agli addr:street se siamo con una mappa meno estesa (ma dubito di
> questo punto)....è un problema che tu vorresti risolvere come? aggiungendo
> un livello (per quanto piccolo) di difficoltà anche per l'inserimento di
> una
> cosa banale come un nodo con associati due tag?


confermi che ti sfugge il problema tecnico.
Il problema è il mantenimento


> ...non credo sia vincente
> come strategia...non ho mai provato, google mi costringe a fare cose tipo
> le
> relazioni per i civici?
>

Quello che fa Google coi suoi dati lo sa Google
Probabilmente usa qualchhe rete neurale per farle normalizzare i dati di Osm
Perchè è Google
Gli altri si dovranno accontentare


>
>
> >> fatto che sei disposto a fargli i corsi e che Google map  sarà sempre
> >> superiore ma che non deve essere necessariamente così anche se rimaniamo
> >> aperti...e magari informati sull'interlocutore prima di proporti di
> >> fargli
> >> un corso sulle relazioni...non sia mai che ne abbia realizzate magari un
> >> due
> >> ordini di grandezza più di te X°D
> >>
> >
> > ma magari semza capire a che servono 🙄
>
> ahahah...questa era carina, mi è proprio piaciuta xD
>

eh 🙄


>
>
> comunque stiamo entrando in loop, io chiudo qui.
> fai un fiscio appena fai la proposta, non voterò (per la relazione street,
> per l'associatedStreet il voto negativo potrebbe scapparmi :-P ) ma la
> seguirò con attenzione.
>

associatedStreet non piace neanche a me
L'ho citata solo perchhe mi pareva fosse più accettata
è evidente che gli attributi di una strada non sono solo i civici





>
>
> -----
> Ciao,
> Aury
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> _______________________________________________
> Talk-it mailing list
> Talk-it a openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.openstreetmap.org/pipermail/talk-it/attachments/20180109/5045e6f0/attachment-0001.html>