<div dir="ltr">Il giorno 15 dicembre 2017 10:42, 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">Catonano wrote<br>
> Il giorno 14 dicembre 2017 23:59, Aury88 &lt;<br>
<span class=""><br>
> spacedriver88@<br>
<br>
> &gt; ha<br>
> scritto:<br>
><br>
>> Catonano wrote<br>
>> > Il giorno 14 dicembre 2017 18:40, Aury88 &lt;<br>
>><br>
>> > spacedriver88@<br>
>><br>
>> > &gt; ha<br>
>> > scritto:<br>
>> ><br>
>> >> Simone Saviolo wrote<br>
>> >> > Il giorno 14 dicembre 2017 12:24, Aury88 &lt;<br>
>> >><br>
>> >> > spacedriver88@<br>
>> >><br>
>> ><br>
>> >> ma perchè fermarci li! l'hai detto te no? dobbiamo normalizzare i<br>
>> 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>
>> >><br>
>> ><br>
>> > a questa obiezione è già stato risposto che amenity=cafe è un tag<br>
>> fisso,<br>
>> > mentre name="... è free form<br>
>> > Quindi il paragone non regge<br>
>><br>
>>  a maggior ragione andrebbe normalizzato un tag che deve rimanere fisso!<br>
>> sono proprio quelli da cui si parte nei database relazionali<br>
>><br>
><br>
> non comprendo l'obiezione<br>
<br>
</span>la normalizzazione è tanto più importante quanto diffuso (key e value<br>
uguali) è un tag ...idealmente è proprio dai tag più importanti, quelli cioè<br>
principali, che si dovrebbe cominciare con un processo del genere...e il<br>
motivo è identico a quello che utilizzate voi come argomentazione a favore<br>
del passaggio all'uso delle relazioni: se si deve cambiare il tag o un merge<br>
di alcune categorie di elementi allo stato attuale devi andare a pescarli (a<br>
livello globale, non locale quanto può esserlo una strada) e modificargli il<br>
tag (key e/o value) di ciascuno (e in quasi tutti i casi parliamo di<br>
migliaiai di elementi) con la relazione basterebbe selezionarla e spostarne<br>
tutti i membri nella relazione corretta (quando si tratta di merge) o<br>
modificare quella errata modificando unna volta sola il tag...<br>
<span class=""><br>
<br>
> e invece no<br>
> Puoi tenere entrambi gli schemi, per un periodo di transizione<br>
> Facoltativamente<br>
<br>
</span> hai presente quanto è lungo un periodo di transizione se si lascia la<br>
possibilità di avere entrambi i metodi? il tag amenity=fitness_center è<br>
rimasto in circolo per anni pur essendo chiaramente nnon conforme agli std<br>
OSM ed erano poche migliaia di casi con in più la segnalazione di<br>
errore...nel caso di addr:street la situazione sarebbe peggiore con i nuovi<br>
inserimenti fatti da neomappatori, ma anche da altri non opportunamente<br>
informati, che probabilmente usando come riferimento la mappatura già<br>
presente e largamente più evidente  su qualsiasi editor finirebbero per<br>
continuare a mappare come hanno sempre fatto senza accorgersi neanche della<br>
presenza della relazione<br>
<span class=""><br>
<br>
> Ovviamente quello della relazione<br>
>  Che siccome deve essere manuteuto una volta sole per tutti i civici si<br>
> suppone essere corretto<br>
<br>
</span> lo supponi tu, io suppondo invece che il tag addr:street venga modificato<br>
meno frequentemente, essendo meno evidente, e che di conseguenza i<br>
neomappatori che non conoscono le regole di stile su osm (es. i nomi non<br>
abbreviati) apporteranno cambiamenti scorretti sul nome della strada (<br>
quindi sul riferimento della relazione sostitutiva di addr:street). con gli<br>
addr:street un errore di distrazione non si perde il nome della strada ne il<br>
nome viene cambiato su tutti i nodi =>posso trovarlo e correggerlo...sulla<br>
relazione via ferdinando d'aragona che diventa via aragosta rimane via<br>
aragosta...e tu che non conosci quella via non puoi neache accorgertene ed<br>
eventualmente segnalarla ad un mappatore locale<br>
<span class=""><br></span></blockquote><div><br></div><div>questa idea che errori sui nodi si trovano ed errori sulle relazioni non si trovano davvero non capisco da dove arrivi<br><br></div><div>Forse manca un tool per le relazioni<br><br></div><div>Ma la disponibilità di tool non qualifica la bontà degli schemi<br><br></div><div>Come dire che siccome manca il tool per le basi dati relazionali ci accontentiamo del file csv<br><br></div><div>E comunque anche senza tool gli errori si trovano<br><br></div><div>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<br></div><div><br></div><div>Questa idea che le relazioni occultino gli errori che non emergerebbero mai più non me la spiego<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>
> è dimostrato dalle basi dati da 50 anni<br>
<br>
</span>un db non vale l'altro...il fatto che ci siano ambiti di utilizzo di<br>
database in cui il sistema relazionale apporta significativi vantaggi<br>
rispetto quelli attributivi non significa che tale logica sia vincente in<br>
tutte le tipologie di database...tanto più in progetti crowdsourced senza<br>
parametri di selezione/limitazione dei contributi basati<br>
sull'esperienza...quali sarebbero queste dimostrazioni di DB da 50? per caso<br>
sono database gestiti da gente formata o comunque non contributori casuali?<br>
bene, non centrano nulla con OSM.<br></blockquote><div><br></div><div>Bene, questo vuol dire che le applicazioni consentite da quei db non centrano nulla con quelle che saranno consentite da osm<br><br></div><div>Un mare di gente che produce montagne di dati di dubbia qualità non sono questo grande successo<br><br></div>Certo non lo era per chi studio i db relazionali <br><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">> rimane il fatto che scrrivere lo stesso attributo suu nodi diversi apre<br>
> alla possibilità di sbagliare quell'attributo su ogni nodo su cui è<br>
> scritto<br>
> La ridondanza costa<br>
> Copia incolla o no<br>
<br>
</span> apre a possibilità di sbagliare attributo su alcuni nodi o di sbagliarlo<br>
per tutti i nodi se si parte sbagliando e avrei in entrambi i casi la<br>
possibilità di fare un confronto con la strada. con la relazione apri la<br>
possibilità di dover sbagliare una volta sola allineando tutti gli indirizzo<br>
con dati sbagliati senza potersene accorgere...</blockquote><div><br></div><div>senza potersene accorgere... 🙄<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">la ridondanza costa ma è<br>
spesso proprio la ridondanza il motivo della sicurezza di moltissimi<br>
sistemi. non voli su alcun aereo che non abbia almeno ridondazia doppia per<br>
componenti critici;</blockquote><div><br></div><div>quelli critici, non ogni molecola<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> secondo te per quale motivo? per far costare di più<br>
l'aereo?<br></blockquote><div><br></div><div>vabbé<br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">> in discussione è ANCHE il caso chhe qualcuno cambi il nome della strada su<br>
> alcuni nodi erroneamente<br>
> Se i nodi sono iin una relazione può danneggiare il nome della strada una<br>
> volta sola<br>
<br>
</span> una volta sola e in maniera potenzialmente definitiva visto che nessuno se<br>
ne accorge...</blockquote><div><br></div><div>nessuno se ne accorge 🙄<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">dall'altra OSM inspector mi dice subito che li ce un problema e<br></blockquote><div><br></div><div>e allora ofrse bisognerebbe adeguare OSM inspector e chiedergli di richiamare l'attenzione quando un attributo viene editato su una relazione <br><br></div><div>La disponibilità di tool non è una condizzione naturale o una fatalità<br><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
posso contattare un mappatore locale per avvisarlo o andare nello storico e<br>
vedere come è cambiato il nome e magari determinare quale dei due sistemi di<br>
denominazione è quello corretto. i ldisallineamento non è un problema grosso<br>
in quanto facilmente identificabile e riparabile come dimostra la<br>
discussione. il fatto di basare tutti gli indirizzi sui nomi di una strada<br>
(uno degli elementi più toccati da inesperti) senza possibilità di<br>
accorgersene per me lo è eccome.<br></blockquote><div><br></div><div>senza possibilità di accorrgersene 🙄<br><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
>> 5) la soluzione è stata immediata consigliata già alla seconda risposta,<br>
>> la<br>
>> vostra proposta richiede un cambio di stile che si deve applicare<br>
>> globalmente a tutti i nodi già mappati (68 milioni)<br>
><br>
><br>
> Non tutti immediatamente, ovviamente<br>
<br>
</span> quanto tempo vorresti dare ad una transizione del genere? un mese? un anno?<br>
un milione di anni? considera che se non hai tool per la QA, il render<br>
predisposto e buona documentazione avere un periodo di transizione significa<br>
che in quel periodo si continuerà a mappare mantenendo l'attuale<br>
proprorzione tra vecchio (ogni 5 con relazione 68 con addr:street) e<br>
indovina in quanto tempo si finisce in queste condizioni? considera poi che<br>
se uno stile è usato proporzionalmente poche volte non gli si fanno ne tool<br>
ne render  in quanto troppo di nicchia, disincentivando di fatto il<br>
passaggio al nuovo stile. ecco perchè va proposto alla comunità quello che<br>
dite.<br></blockquote><div><br></div><div>proporremo alla comunità<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> ma non dannose quanto i disallineamenti<br>
<br>
</span> esatto, sono più dannose.<br></blockquote><div><br></div><div>sono _meno_ dannose. Non ai colto l'argomento tecnico, come quualcun altro ha osservato<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
> ?? Josm crea le relazioni semza problemi<br>
<br>
</span> lo so perfettamente...le relazioni sono elencati nel pannello relazioni, in<br>
cui devo poi schiacciare l'edit per aprirre il popup con editor di relazioni<br>
e  poter finalmente associare i ruoli...quando l'edit dei tag è subito a<br>
destra nel pannello etichette...e questo tralasciando il problemuccio che<br>
JOSM viene usato neanche dall' 8% degli utenti e che viene usato comunque<br>
per lo più per fare editing sui tag e non sulle relazioni (una relazione<br>
ogni 1000 tra way e nodi )<br></blockquote><div><br></div><div>Forse bisognerebbe chiedere agli autori di tool di aprrire n editor di relazione quando una rrelazione è presente<br><br></div><div>Per esempio, se un nodo ha un attrributo addr:street e c'è una relazione con nome simile, alla qual appartengono magari nodi vicini...<br><br></div><div>Non la azzeccherà nel 100% dei casi, ma sempre meglio che far ffinta che le relazioni non esistano<br> <br></div><div>Invece di considerare il panorama dei tool disponibili come una fatalità<br><br></div><div>Altrimenti quello che succede è che con l'argomento chhe i tool sono quello che sono li si incentiva a rimanere quello che sono<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> non capisco l'obiezione<br>
><br>
> Io ho usato Josm<br>
><br>
> Ho creato la relazione a manina e ci ho messo i civici, sempre a manina<br>
<br>
</span> nostalgia del periodo egizio vedo xD<br></blockquote><div><br></div><div>ha parlato quello del copia e incolla<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
non è il problema creare la relazione, ma il trascinarci dentro magari<br>
centinaia di nodi a manina, </blockquote><div><br></div><div>beh a manina si fanno tante cose. A cominciare dall'inserire i civici tout court<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">uno ad uno </blockquote><div><br></div><div>magari a gruppi ? Magarrri non tutti in una volta ?<br></div><div>10 oggi e 5 domani ?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(perchè se sei contrario al Ctrl+F e<br>
all'addr:street , per coerenza, non dovresti neache usarlo per selezionare i<br>
nodi da aggiungere alla relazione) </blockquote><div><br></div><div>Ctrrl-F lo uso più volentieri per realizzre una souzione che prometta di non doverlo riutilizzare in futuro<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">o trovare nodi che ci si scorda di<br>
inserire nella relazione<br></blockquote><div><br></div><div>Senza relazioni evidentemente non ci si scorda niente<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> Cos'ha Josm che non va ?<br>
<br>
</span>JOSM non ha nulla che non va...non è però ne immediato per gran parte dei<br>
mappatori (il 92%) ne l'editing di reazioni è immediato quanto lo è<br>
l'editing dei tag...</blockquote><div><br></div><div>Ok, mancano i tool.  <br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">quindi il costringere ad usare editor relazioni<br>
all'interno dell'editor JOSM per un elemento diffussimo e capillare,  il<br>
tutto per avere vantaggi irrilevanti in caso di eventi di per se rari </blockquote><div><br></div><div>"irrrrilevanti" e "rari" secondo quali misure ?<br><br></div><div>Di nuovo, ti sfugge l'aspetto tecnico<br><br></div><div>Qualcun altro ha osservato che l'evento non è così raro come dici tu<br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">e il<br>
tutto perdendo la possibilità di identificare l'errore e correggerlo dato<br>
dalla ridondanza non lo trovo furbo.<br></blockquote><div><br></div><div>Perdendo la possibilità 🙄 <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
> si pò fare gradualmente con gli strmenti che ci sono<br>
> Del resto la relazione associatedStreet è approvata, mi pare<br>
><br>
> Gli strumenti verranno col tempo<br>
><br>
> Questa ossessione che la cosa debba essere immediata e massiva da dove<br>
> arriva ?<br>
><br>
> Cosa, in osm, è stato fatto immediatamente e in massa ?<br>
<br>
</span> la spiegazione te l'ho già data portandoti il caso del<br>
amenity=fitness_center palesemente errato eppure diffusissimo finche non ci<br>
siamo messi a fare edit meccanico "di massa". e parlavamo di sole poche<br>
migliaia di casi che però continuavano a generare confusione e a indurre<br>
molti mappatori a continuare ad usare lo stile errato. tu stai proponendo un<br>
cambiamento che in tutti gli editor rimane nascosto, </blockquote><div><br></div><div>Il problema sono gli editor, non lo stile<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">che ha una diffusione<br>
irrisoria </blockquote><div><br></div><div>che rimarrà tale, se l'atteggiamento è questo<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">sperando che questo stato di transizione si sistemi da se con il<br>
tempo...se conoscessi le meccaniche dei contributi di osm sapresti che una<br>
cosa del genere significa semplicemente ritrovarci tra 10 anni con ancora<br>
l'attuale proporzione di civici  mappati nei vari modi e di conseguenza<br>
senza che si sia reso necessario fare strumenti ed editor adatti per l'edit<br>
di uno stile di nicchia.<br></blockquote><div><br></div><div>Per cui non poviamoci nemmeno. Se la vedrà chi dovrà processare ogni nome <br><br>È chiaro che le relazioni sono un'opzione; ma mi colpisce l'atteggiamento<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">> Per creare relazioni e aggiungervi elementi c'è gia tutto 🙄<br>
><br>
> Tranne la buona volontà<br>
<br>
</span> no è la buona volontà il problema, ma la volontà di fare le cose fatte in<br>
maniera errata...tu proponi qui un cambiamento radicale nello stile di<br>
mappatura di OSM con lo spostamento da uno stile attributivo ad uno<br>
relazionale su un elemento diffusissimo e globale sperando che la situazioni<br>
si sistemi da se con il tempo perchè ne hai diiscusso nella<br>
ML-Italiana...</blockquote><div><br></div><div>No, perchhé è così chhe si organizano i dati<br><br></div><div>Ogni soluzione ondata su dati con la giusta densità informativa costerà meno<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">quello che succederà te l'ho già spiegato ed è terribile.<br>
facevano casino poche migliaia di elementi taggati male (cioè no, non male,<br>
nulla impediva di usare anche quel tag, semplicemente il problema era la<br>
presenza di un altro tag rispetto quello concordato) figuriamoci questo.<br>
ripeto si vada a discuterne nella sede opportuna per poter agire<br>
correttamente.<br></blockquote><div><br></div><div>Discuteremo<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">> come giá scritto, non sarebbe un grande danno<br>
<br>
</span> come già scritto lo sarebbe eccome visto che determina fasi di transizione<br>
di fatto infiniti e che per interrompere necessiterebbe di meccanical edit<br>
"massivi" se non si parte già con una base ampia e strumenti e tool adeguati<br></blockquote><div><br></div><div>le relazioni sono già una opzione disponibile<br></div><div>La transizione è già in corso. <br></div><div>Osteggiata<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="">> forse perche non è lo strumento giusto ?<br>
<br>
</span> ma apunto tu cosa usi per trovare strade con nome errato nelle relazioni?<br></blockquote><div><br></div><div>Josm. Apro la relazione e la guardo<br><br></div><div>Oppure un instradatore. Gli chiedo di essere instradato verso un indirizo di na strada fatta con una relaione e vedo che succede<br><br></div><div>Poi ho già proposto una integrazione da chiedere a questo OSM inspector e un'altra per altri editor<br><br></div><div>Non è che senza OSM inspector non si possano fare basi dati geografiche<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">> Se non conosci i luoghi il problema non sono le relazioni<br>
><br>
> Comunque io editerei solo la relazione.<br>
><br>
> Anche se sbagli chi ti correggerà dovra farlo na volta sola 🙄<br>
<br>
</span>che strano, anche io edito una volta sola selezionando tutti gli elementi<br>
con il tag errato<br></blockquote><div><br></div><div>Allora chi ha inventato le basi dati relazionali non ha capito una fava <br></div><div>Complimenti <br></div><div><br><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>
> e il lavoro per mantenerli questi 68 milioni di nodi ?<br>
><br>
> Forse con lo stesso lavoro si potrebbe fare di più ?<br>
<br>
</span> non saprei...onestamente finchè non so qual'è l'incidenza dei<br>
disallineamenti a seguito di cambi nomi sulle strade non posso dirlo...</blockquote><div><br></div><div>a me pare che la sottostimi, come ha osservato qualcun altro<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">posso<br>
dire però che di sicuro il passaggio al nuovo stile il lavoro comprenderà<br>
almeno il cambiamento su 68 milioni di nodi e che anche così non si potrà<br>
evitare i cambi errati del tag name sulla strada<br></blockquote><div><br></div><div>il requisito che il passaggio debba essere immediato lo hai inventato tu ed è arbitrario<br></div><div>Le relazioni sono già una opzione, siamo già nel coso di na "transizione"<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
posto che, salvo editwar, il nome delle strade non cabia spesso, </blockquote><div><br></div><div>il problema, come osservato, non è solo che una strada cambi nome<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">perchè il<br>
passaggio al nuovo stile sia vantaggioso rispetto al mantenimento<br>
bisognerebbe avere allo stato attuale il 50% delle strade con nome errato o<br>
non allineato con gli addr:street<br></blockquote><div><br></div><div>Ti sfugge il lavoro fatto per il mantenimento chhe potrebbe essere fatto su altro<br></div><div>Il vantaggio del passaggio alla normalizzazione è evidente, le misure e gli studi furono fatti all'epoca loro<br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> dovendo ripetere gli stessi edits su molti nodi si è più esposti al<br>
> rischio<br>
> di errore, oltrre al rrischhio di diver riparare più volte gli stessi nodi<br>
> o lo stesso nome di strada<br>
<br>
</span> attualmente per i cambiamenti in caso di cambio nome l'edit è uno solo ed è<br>
applicato sull'intero gruppo che viene estratto grazie al nome non<br></blockquote><div><br></div><div>il cambio nome NON è il nostro caso <br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
aggiornato (quindi due passaggi per gruppo di nodi), mentre per la relazione<br>
è una selezione della strada (quindi un solo passaggio per gruppo di nodi)<br>
<br>
 nel caso di nuovi inserimenti l'edit è sui soli civici (se decidi di fare<br>
copia incolla) o comunque presuppone un due edit  per nodo(civico e street<br>
quindi due passaggi per nodo) contro, nel caso delle relazioni, di un edit<br>
(civico) e di un aggiunta con associazione di ruolo alla relazione (quindi<br>
di fatto 3 passaggi per nodo)<br></blockquote><div><br></div><div>Che ne risparmieranno chissà quanti in futuro<br><br></div><div>un editor può sempre essere migliorato in modo che rrichhieda 2 passaggi anche per usare una relazzione<br><br></div><div>Gli strumenti si fanno sopo aver deffinito i concetti, non il contrario<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>> questa frase non meriterebbe neanche una risposta (tanto più che ho già<br>
>> risposto in proposito a quanto per me sia complicata la relazione (a<br>
>> proposito quale delle due) per gli indirizzi) vai a fare il corso a chi<br>
>> serve veramente cioè ai nuovi arrivati......io mi godrò la caduta nella<br>
>> curva dei contributi<br>
><br>
><br>
> che ne so. Tutti a dire che l'accessibiltà è importante, che le relzioni<br>
> la<br>
> abbassano 🙄<br>
<br>
</span> anche questa tua risposta la dice lunga...u<br>
ti basta che uno, nel considerare il fatto che la maggior parte dei<br>
mappatori non sono esperti e non lo diventeranno mai (visto il grado di<br>
ritenzione), cerchi di far portare avanti una discussione che tenga in<br>
considerazione i neomappatori perchè debba essere anche lui  per forza di<br>
cose un neomappatore? il fatto che tu non lo sappia non ti obbliga a<br>
supporre ne ti esime dall'utilizzare, prima di parlare magari a vanvera, uno<br>
dei tanti ed ampiamente conosciuti strumenti che ci sono nella comunità osm<br>
per sapere anche con chi si sta parlando. </blockquote><div><br></div><div>Siamo al tu non sai chi sono io<br><br></div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">e sì, proprio perchè non sono un<br>
neomappatore so che l'accessibilità è importante e so che la relazione<br>
abbassano questa accessibilità come tutte le statistiche dimostrano<br></blockquote><div><br></div><div>peccato che "l'accessibilità" abbassi la qualitá dei dati, come dice la teoria consolidata<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> Non tutto è un fallimento<br>
> Ma secondo voi lo sono solo le relazioni<br>
<br>
</span> e chi lo avrebbe detto? noi no di certo, mentre tu parli di esperienza<br>
fallimentare viste le conseguenze che sarebbero arrivate dall'avere<br>
addr:street duplicati. io ho detto al massimo che è potenziamente<br>
fallimentare il tentare di far diventare osm un database professionale e<br>
relazionale quest'ultimo punto specialmente se applicato per elementi<br>
diffusi come i civici che già adesso soffrono di penuria di contributi.  </blockquote><div><br></div><div>Ecco questo mi pare un punto centrale<br></div><div><br></div><div>Se Osm deve ben gardarsi dal diventare una base dati "professionale" allora dobbiamo intenderci su che genere di basi dati è<br></div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ma<br>
in realta mi sono limitato a dire che semplicemente la proposta va fatta<br>
nella sede opportuna perchè non diventi un fallimento con la fase di<br>
transizione.<br></blockquote><div><br></div><div>e va bene, messaggio ricevuto<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<span class=""><br>
> come è stato già scritto se una strada si chiama "via Cavour" non si puó<br>
> dire che sia sbagliata<br>
><br>
> Se OSMinspector ti segnala che su altri nodi si chiama "via Camillo Benso<br>
> Conte Di Cavor" quell'errore succede SOLO perche l'attributo è ripetuto<br>
> inutilmente<br>
><br>
> Se ci fosse una relazione col nome della strada "via Cavour" nessuno<br>
> strumento rrileverebbe nessun errore perche non c'é nessun errore<br>
><br>
> Invece con strumenti come OSMinspector troverete tanti "errori" quanti<br>
> differenze nel nome della strada su ogni nodo<br>
><br>
> Lavoro sprecato 🙄<br>
><br>
> Però molto accesibile<br>
><br>
> Molti degli errori che rilevate con OSMinspector non sono errori, sono<br>
> generati dal vostro stile apprezzzatissimo<br>
<br>
</span> no, il problema è se scrivi cavuor invece di cavour sulla strada con la<br>
relazione...buon divertimento ad identificarlo.<br></blockquote><div><br>🙄 <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OSM inspector usa una ridondanza (lo stile apprezzatissimo) per avere una<br>
base da normalizzare e usare come media/moda per trovare gli scostamenti.<br></blockquote><div><br></div><div>AAhhhh ma se questa è la premessa allora siamo daccordo.<br><br></div><div>Cioè chi usa i dati deve sapere che dovrá farsi carico della normalizzazione <br><br></div><div>Devo dire che avevo capito una cosa diversa<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
non è il fatto di avere lo stile "apprezzzatissimo" ad essere un errore<br>
tanto è vero che se il name della strada e il value addr:street dei 10<br>
milioni di civici ad esso associati corrisponde non ti segnala niente.</blockquote><div><br></div><div>con 10 milioni di civici qualcuno prima o poi si accorgerà di qualcosa 😀<br><br></div><div>Non riuscirà a farsi instradare, non troverà il suo bar preferito o casa sua...<br></div><div>E dai, su. OSM inspector non è l'unico mezo al mondo<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> il<br>
99% dei casi tutti i nodi presentano lo stesso errore e si corregge in 10<br>
secondi<br></blockquote><div><br></div><div>Il 99% ? Siamo sicuri ? 😀<br><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>
> l'errroe non evidenziabile non esiste<br>
<br>
</span> devo usarla anche io questa cosa...la polvere sotto il tappeto non esiste<br>
xD<br></blockquote><div><br></div><div>Confermi che gli aspetti tecnici ti sfuggono<br> <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> con OSMinspectorr lo trovate perche duplicate i dati inutilmente<br>
<br>
</span>"si trova" "inutilmente"...beh, almeno per una cosa è utile e permette di<br>
identificare sia molti errori sia i disallineamenti<br></blockquote><div><br></div><div>molti dei quali non sono errrori. I disallineamenti non esisterebbero<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> Se il nome della strada fosse presente una volta sola, nella relazione,<br>
> non<br>
> ci sarebbe nessun errore.<br>
<br>
</span>salvo nome errato in quel caso sarebbe un errore non rilevabile che per te<br>
equivale a dire non avere l'errore xD<br></blockquote><div><br></div><div>non rilevabile 🙄<br><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> E tu sei sicuro di comprendere il senso di ciò che OSMinspector ti segnala<br>
> ?<br>
<br>
</span> io abbastanza, a questo punto  il mio sospetto è che sia tu a non<br>
conoscerlo o saperlo usare..<br></blockquote><div><br></div><div>Io non l'hho mai usato e da come lo avete descritto direi che non ne vale la pena.<br>È evidentemente no strumento ffondato su concetti deboli o pensati per altri casi<br><br></div><div>Che tu lo abbia usato molto è un problema tuo<br></div><div>E di Osm<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>
> La teoria delle basi dati esiste per una ragione<br>
<br>
</span> come anche la statistica, il calcolo del rischio  e della reliability su<br>
sistemi in parallelo e in serie...così come è previsto quando non hai una<br>
ridondanza nel dato di avere database ridondanti per poter trovare<br>
errori...da me non si va da nessuna parte e si rischia addirittura il<br>
carcere se le cose non sono salvate in almeno triplice copia<br></blockquote><div><br></div><div>Va bene, se mi garantisci chhe ogni nome viene scritto solo tre volte mi sta bene 😀 <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>
> Ma a prescindere dall'analisi, reiterrare lo stesso dato moltiplica la<br>
> possibilità d'errore<br>
<br>
</span> la possibilità di errore determinata da reiterazione non è data da una<br>
moltiplicazione, ma da un esponente...<br></blockquote><div><br></div><div>a maggior ragione andrebbe evitata<br><br></div><div>comunque l'esponenziazione cos'è ? <br></div>una moltiplicazione reiterata<br></div><div class="gmail_quote"><br><br> <br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> Oltre al fatto che vengono considerati "errate" versioni del nome della<br>
> strada solo perchhe difformi da quelle di altri nodi, mentrre se il nome<br>
> dlela strada fosse scritto una vlta sola nella relazzione, quello che<br>
> viene<br>
> segnalato come errore da OSMinspector sarebbe perfettamente valido<br>
<br>
</span> xD non avrei saputo scriverlo meglio...<br></blockquote><div><br></div><div>ecco appunto.<br><br></div><div>Correggi errori che errori non sono e sei pure contento <br></div><div>Questo mi conferma che Osm serve a offrire un giochino agli entsiasti<br> <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> Il problema non sono gli strumenti, sono le idee<br>
<br>
</span>sono d'accordo.<br></blockquote><div><br></div><div>🙄 <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">> già.<br>
><br>
> Invece la mia proposta è evidentemente vantaggiosa<br>
> Il fatto che associatedStreet sia approvata dovrebbe suggerirti qualcosa<br>
<br>
</span>come anche il fatto che sia semisconosciuto e praticamente usato solo per<br>
poche migliaia di strade dovrebbe suggerire a te qualcosa, così come le<br>
statistiche di contributo, di utilizzo degli editor, di diffusione di<br>
tipologie di elementi o i precedenti nei casi di cambi di tag....</blockquote><div><br></div><div>mi suuggerisce la mancanza di consapevolezza della comunità Osm<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">così come<br>
dovrebbe  suggerirti qualcosa la qualità della proposta che parte con un<br>
errore stilistico già dal value del type per finire che non mi sembra sia<br>
stata approvata ("associatedStreet relations have been used by some mappers<br>
as an alternative to addr:*-Tags" = qualcuno ha cominciato semplicemente ad<br>
usarlo) ma semplicemente non deprecata (per 5 voti di scarto e nascondendo<br>
la votazione dentro la pagina di discussione della voce medesima...tutto<br>
assolutamente irregolare)...si in effetti suggerisce molte cose...ed è anche<br>
questo il motivo per cui preferisco la relazione street<br></blockquote><div><br></div><div>Ah la preferisco pure io !<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> ma a quale costo ?<br>
> Al costo di lavoro evitabile ?<br>
><br>
> Cosi scoprirono gli inventorii dei database, inutilmente, anni fa<br>
<br>
</span> ci sono ambiti dove la velocità di inserimento è fondamentale, altri dove<br>
lo è l'organizzaizone, altri dove lo è la ridondanza ed altri dove lo è<br>
l'inclusività... continui con la storia di un database vale l'altro.<br></blockquote><div><br>in effetti è possibile che abbia frainteso cosa sia Osm<br><br></div><br><span class=""></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
> bisognerebbe vedere quanto lavoro è costato<br>
<br>
</span> mi è costato meno di quanto lo sarebbe stato creare una relazione per<br>
strada e trascinarci a mano ogni singolo civico...</blockquote><div><br></div><div>quanto lavorro è costat il MANTENIMENTO fino ad oggi, non la creaione 🙄<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">allo stato attuale il<br>
passaggio al nuovo stile sarebbe molto veloce perchè potrei sfruttare gli<br>
addr:street per selezionarli e trascinarceli in blocco...e gli addr:street<br>
li ho avuti a gratis tranne il primo civico di ogni strada<br></blockquote><div><br></div><div>vedi ?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">> Quanti errori segnalati da OSMinspector sono stati corrretti che non<br>
> sarebbero esistiti per nulla se i nomi delle strade non ofssero stati<br>
> inutilmente ripetuti ?<br>
<br>
</span> tutti visto che con il nuovo stile OSM inspector non trova errori anche<br>
palesi sul tag name...<br>
<span class=""><br>
<br>
>><br>
>> > Se voi continuare a mappare non puoi pretendere di continuare a farlo,<br>
>> > negli anni, da "neomappatore"<br>
>><br>
>>  grazie per avermi aperto gli occhi...da domani mi mettero a mappare in<br>
>> maniera inutilmente complessa per dimostrare la mia esperienza...<br>
>><br>
><br>
> l'utilità della mia proposta è stranota ed è probabilmente la ragione per<br>
> la quale esiste associatedSteet<br>
<br>
</span> wow...esiste anche la pagina su gli addr:* ripetuti cosa fai? due pesi e<br>
due misure?<br>
<span class=""><br>
<br>
<br>
> io sto sostenendo na tesi consolidata dalgi anni 60<br>
<br>
</span> su che tipologia di database, con che genere di inseritori ed<br>
utilizzatori...un database non vale l'altro<br></blockquote><div><br></div><div>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<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
<br>
<br>
<br>
>><br>
>> > Insomma ti devi far carico della qualità dei dati !<br>
>> ><br>
>> > Non puoi pretendere di continuare a mappare per anni da "neomappatore"<br>
>> e<br>
>> > riempire la mappa di civici ognuno con una versione leggermente diversa<br>
>> > del<br>
>> > nome della strada a cui appartiene 😀<br>
>> > Facciamo così: scegli una strada.<br>
>> ><br>
>> > Fissiamo un appuntamento e facciamo un Google Hangout in cui ti mostro<br>
>> > come<br>
>> > e perché si usano le relazioni per le strade !<br>
>><br>
>>  veramente...in estremo imbarazzo...<br>
>><br>
><br>
> è reciproco<br>
<br>
</span> mi fa piacere sapere che sai riconoscere di aver fatto una figuraccia e<br>
provi imbarazzo per questo. non ti preoccupare, non me la sono presa.<br></blockquote><div><br></div><div>vabbé<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
<br>
<br>
>> > ripeto: e quindi ? Facciamo una mappa con 10.000 ersioni del nome di<br>
>> una<br>
>> > strada su ogni civico di quella strada ?<br>
>><br>
>> addirittura ogni nodo aveva un nome differente?<br>
><br>
><br>
> 10.000 versioni del nome differente. La strada di civici potrebbe averne<br>
> 15.000 o di più 🙄<br>
<br>
</span>wow, e ricordiamocelo, tutto con un semplice copia incolla che a quanto pare<br>
da te incolla sempre qualcosa di diverso xD<br></blockquote><div><br></div><div>no vabbé<br></div><div>Il copia e incolla contro la normalizazione 😞 <br></div><div> <br><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>
>> > Apertura non può voler dire abbassamento della qualità 😕<br>
>><br>
>> mai detto e infatti abbiamo un ottima mappa già adesso...<br>
><br>
><br>
><br>
> non con la stessa estensione di Goole Maps<br>
><br>
> Forse perchhe si lavora su cose non indispensabili ?<br>
> Magari anche ?<br>
<br>
</span> non si lavora, si contribuisce. e per molte zone la mappa osm ha maggiore<br>
copertura della mappa google che, notiziona, è fatta per buona parte non da<br>
inserimenti diretti ma da import di db fatti da altri con decenni di<br>
anticipo sull'uscita di queste mappe online....certo poi non vorrai dare la<br>
colpa agli addr:street se siamo con una mappa meno estesa (ma dubito di<br>
questo punto)....è un problema che tu vorresti risolvere come? aggiungendo<br>
un livello (per quanto piccolo) di difficoltà anche per l'inserimento di una<br>
cosa banale come un nodo con associati due tag?</blockquote><div><br></div><div>confermi che ti sfugge il problema tecnico.<br></div><div>Il problema è il mantenimento<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...non credo sia vincente<br>
come strategia...non ho mai provato, google mi costringe a fare cose tipo le<br>
relazioni per i civici?<br></blockquote><div><br></div><div>Quello che fa Google coi suoi dati lo sa Google<br></div><div>Probabilmente usa qualchhe rete neurale per farle normalizzare i dati di Osm<br></div><div>Perchè è Google<br></div><div>Gli altri si dovranno accontentare<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
>> fatto che sei disposto a fargli i corsi e che Google map  sarà sempre<br>
>> superiore ma che non deve essere necessariamente così anche se rimaniamo<br>
>> aperti...e magari informati sull'interlocutore prima di proporti di<br>
>> fargli<br>
>> un corso sulle relazioni...non sia mai che ne abbia realizzate magari un<br>
>> due<br>
>> ordini di grandezza più di te X°D<br>
>><br>
><br>
> ma magari semza capire a che servono 🙄<br>
<br>
</span>ahahah...questa era carina, mi è proprio piaciuta xD<br></blockquote><div><br></div><div>eh 🙄<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
comunque stiamo entrando in loop, io chiudo qui.<br>
fai un fiscio appena fai la proposta, non voterò (per la relazione street,<br>
per l'associatedStreet il voto negativo potrebbe scapparmi :-P ) ma la<br>
seguirò con attenzione.<br></blockquote><div><br></div><div>associatedStreet non piace neanche a me<br></div><div>L'ho citata solo perchhe mi pareva fosse più accettata<br>è evidente che gli attributi di una strada non sono solo i civici<br></div><div> <br><br><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
-----<br>
Ciao,<br>
Aury<br>
--<br>
Sent from: <a href="http://gis.19327.n8.nabble.com/Italy-General-f5324174.html" rel="noreferrer" target="_blank">http://gis.19327.n8.nabble.<wbr>com/Italy-General-f5324174.<wbr>html</a><br>
<br>
______________________________<wbr>_________________<br>
Talk-it mailing list<br>
<a href="mailto:Talk-it@openstreetmap.org">Talk-it@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-it" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-it</a><br>
</div></div></blockquote></div><br></div></div>