[Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
Aury88
spacedriver88 a gmail.com
Ven 15 Dic 2017 09:42:49 UTC
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
> è 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.
> 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...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; secondo te per quale motivo? per far costare di più
l'aereo?
>> 2) il copia incolla si usa per fare aggiunte non cambi tag a seguito di
>> cambio nome dello highway di riferimento che mi sembra il caso in
>> discussione, quindi non capisco perchè lo tiri in ballo
>>
>
> 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...dall'altra OSM inspector mi dice subito che li ce un problema e
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.
>> 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.
> ma non dannose quanto i disallineamenti
esatto, sono più dannose.
>
> lui chi ?
l'hai letta la discussione? hai letto il quote a cui era riferita la mia
risposta che tu hai quotato ?
> ?? 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 )
> 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
non è il problema creare la relazione, ma il trascinarci dentro magari
centinaia di nodi a manina, uno ad uno (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) o trovare nodi che ci si scorda di
inserire nella relazione
> 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...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 e il
tutto perdendo la possibilità di identificare l'errore e correggerlo dato
dalla ridondanza non lo trovo furbo.
> 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, che ha una diffusione
irrisoria 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 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...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.
> 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
> forse perche non è lo strumento giusto ?
ma apunto tu cosa usi per trovare strade con nome errato nelle relazioni?
> 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
> 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...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
posto che, salvo editwar, il nome delle strade non cabia spesso, 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
> 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
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)
>> 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. 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
> 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. 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.
> 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.
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. il
99% dei casi tutti i nodi presentano lo stesso errore e si corregge in 10
secondi
> l'errroe non evidenziabile non esiste
devo usarla anche io questa cosa...la polvere sotto il tappeto non esiste
xD
> 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
> 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
> 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..
> 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
> 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...
> 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...
> 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....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
> 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.
> 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...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
> 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
>>
>> > 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.
>> > 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
>>
>> > 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?...non credo sia vincente
come strategia...non ho mai provato, google mi costringe a fare cose tipo le
relazioni per i civici?
>> 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
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.
-----
Ciao,
Aury
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
Maggiori informazioni sulla lista
Talk-it