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

[Martin Koppenhoefer]

ricordo che non è obbligatorio rispondere e commentare ogni frase, al 
contrario, cerchiamo di comprimere le nostre comunicazioni in lista pubblica e 
accorgiamo le citazioni al minimo necessario.

Grazie,
Martin 



___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Catonano]

Il giorno 15 dicembre 2017 08:43, Federico Cortese 
ha scritto:

> 2017-12-15 1:43 GMT+01:00 Catonano :
> >
> > Federico
> > io ho guardato sulla mia zona ma se devo dire il vero il mio problema
> sono gli edifici che hai importato tu
> > Infatti, hai unificato ogni isolato in un unico edificio
>
> Caro Adriano, mi dispiace e mi stupisce l'atteggiamento con cui ti
> stai ponendo in questa discussione.
> Credo che chi ha appena iniziato a lavorare su OSM dovrebbe avere un
> approccio un pochino più modesto e non scagliarsi contro tutti i
> mappatori un po' più esperti, pretendendo di portare le verità
> assolute.
> Fatta questa premessa io non ho assolutamente unito tutti gli edifici,
> ma ho importato una CTR 1:5.000 che riportava gli edifici in quel
> modo.
> Lo consideravo un miglioramento rispetto al nulla assoluto, ma anche
> rispetto a ricalcare i fabbricati uno ad uno.
> Le sagome che ci sono ora sono molto buone, non resta che dividerle,
> quindi se vuoi farlo puoi metterti all'opera e ringraziare chi ti ha
> semplificato il lavoro di qualche ordine di grandezza ;)
>
> > Ma invece spesso gli isolati sono molti edifici, ognuno col suo civico,
> col suo numero di piani
> > Per cui aggiungere i civici e altri attributi con Vespucci mentre
> passeggio non è immediato
>
> Dovresti vedere come era immediato quando c'era il vuoto.
> Quello che proponi (divisione fabbricati ed aggiunta piani) è proprio
> quello che faccio sempre dopo aver inserito i civici sul posto e
> raccolto informazioni su numero piani ecc.
> Dai un'occhiata a Lecce o a Tricase:
> http://www.openstreetmap.org/way/299719900
> http://www.openstreetmap.org/way/379547100
> Che puoi meglio apprezzare con la visuale 3D:
> http://demo.f4map.com/#lat=40.3543852=18.1794130=
> 18=53.308=-14.61
>
> > L'idea del numero di piani come attributo degli edifici me l'avete fatta
> venire tu e un altror interlocutore quando ho chiesto a proposito della
> relazzione di via di Palma. Perche io manco lo sapevo che si dovesse
> inserire ancheh questo attrributo.
> > Ricordi ? Invece di pensare alle relazioni ci sono tanti attributi che
> puoi inserire prima, mi diceste.
> > Naturalmente per inserire i piani gli edifici devono essere separati.
> Spesso ci sono palazzzi dell'iizio del 900 accanto a palazzi anni 70
> > Ho provato a dividere i tracciati di nuovo, a mano, ma non mi riesce, ci
> metto troppo tempo, spesso le foto sono sgranate e non allineate
> > Probabilmente sarebbe stato meglio mantenere l'articolazione degli
> edifici importati dalle carte tecniche della regione
>
> Quali? Io ho importato proprio quelli. Hai mai aperto gli shapefile
> della regione?
> Adriano prima di sparare cavolate documentati per favore.
> Sulla CTR c'è un altro layer lineare, con alcune divisioni interne dei
> fabbricati, ma sono poche e non così precise: se fossero state buone
> avrebbero diviso i fabbricati invece che lasciare i cassoni.
> Ad ogni modo se c'è una base dati più precisa per Taranto puoi
> impostare un nuovo import, io ci ho messo un anno prima di poterlo
> fare, non perchè non lo sapessi fare tecnicamente, ma perchè non avevo
> l'esperienza e la conoscenza di OSM sufficiente per potermici
> cimentare.
> Se ci metti molto tempo a dividere gli edifici è perchè non hai
> pratica, come non ne avevo io tre anni fa! Ora ci metto pochissimo.
> Inizia a farlo e ne riparliamo tra tre anni ;)
>

Va bene questa cosa l'abbiamo chiarita in privato


> > Avevo anchhe ipotizzato di chhiedere alla comunità aiuto nell'eliminare
> alcune delle tue importazioni, magari suu un'area ristretta
> > Ma l'andamento di questa discssione è stato estremamente scoraggiante
> > Se per una banalità come la normalizzazione dei dati siamo dovuti
> arrivare agli insulti, credo che questa comunità sia tossica e non ho molta
> voglia di averci troppo a che fare
> > Mi dispiace, perche sarei stato entusiasta di lavorare sulla mia zona,
> visto che su questa zona ci sei solo tu e poco altro
> > Ma siete davvero bravissimi a scoraggiare i nuovi, specie se hanno
> rudimenti di basi dati
>
> Mi spiace davvero che tu mi risponda in questo modo, visto che io non
> ti ho mai attaccato, anzi ti ho più volte elogiato.
>

Nessun attacco
Avevo capito che l'appiattimento degli edifici lo avevi fatto tu e lo stavo
riportando

Esattamente come hai atto tu nell'esprimere l'idea che le relazioni non
portano a nulla di più

Avevo capito male sull'appiattimento degli edifici.

Chiedo scusa


> A questo punto dovresti solo porti qualche domanda sul fatto se sia la
> comunità ad essere tossica o se sia il tuo modo di porti a suscitare
> certe reazioni.
>

Le mie reazioni sono aspre
Del resto che il copia e incolla sia vantaggioso rispetto alla
normalizzazione è una cosa che non si può sentire


>
> > Considerato che hai scritto che non vedi cosa aggiunga una relazione per
> una strada, direi che non le conosci abbastanza bene
>
> Ti faccio i miei complimenti visto che 

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

[Catonano]

Il giorno 15 dicembre 2017 10:42, Aury88  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 

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

[Catonano]

Il giorno 15 dicembre 2017 08:57, Lorenzo "Beba" Beltrami <
lorenzo.b...@gmail.com> ha scritto:

> Ciao a tutti,
> anch'io ho la mia esperienza coi civici e anch'io ho a che fare con utenti
> alle prime armi (e che non rispondono ai messaggi) nella mia zona.
> E mi occupo anche di basi di dati (non sono la mia specializzazione, ma
> per lavoro ho a che fare con i database tutti i giorni) e quindi di
> normalizzazione.
>
> L'esperienza però mi porta a dire che è ha ragione tanto chi è per
> l'utilizzo delle relazioni per diminuire la ridondanza ecc. ecc. che chi è
> per la duplicazione per aumentare la facilità di accesso dei dati ecc. ecc..
> Per il semplice fatto che tutte e due le modalità hanno dei lati positivi
> unici, ovvero che l'altra modalità non ha o che al momento non riesce ad
> avere.
> Non c'è una soluzione più giusta dell'altra. E quindi? Come la mettiamo?
>
> Siccome, come si ricordava giustamente, nessuna delle due modalità è
> vietata invece che fare guerra "di trincea" o "di religione" (perché alla
> fin fine è lì che stiamo scivolando) cerchiamo di trovare un modo che possa
> far coesistere le due cose?
> Ad esempio cerchiamo di fare una lista di pro e contro da cui partire a
> ragionare. Oppure una lista di proposte/richieste/aiuti da fare a chi
> sviluppa i software di editing (grazie a dio non sono migliaia) per
> migliorare l'utilizzo delle due metodologie e risolvere i lati deboli.
> Solo alla fine (non all'inizio) si vedrà se dichiarare una delle due
> impraticabile o desueta (si potrebbe dire anche "deprecabile" perché nella
> discussione ci sta, ma ha un altro significato :P).
>

Amen

però mi preoccupa l'idea che la partecipazione larga che crea una montagna
di dati non normalizzati sia considerata un successo

Per me il successo sono le applicazioni
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Catonano]

Il giorno 15 dicembre 2017 09:37, Simone Saviolo 
ha scritto:

> Il giorno 14 dicembre 2017 23:02, Martin Koppenhoefer <
> dieterdre...@gmail.com> ha scritto:
>
>> > On 14. Dec 2017, at 16:24, Simone Saviolo 
>> wrote:
>> >
>> > Inoltre, fare una categoria "scuole di Roma" è sbagliato: se vuoi tutte
>> le scuole di Roma, fai una query. Creare una categoria (con una relazione o
>> in qualsiasi altro modo) sarebbe una sorta di cache dei risultati della
>> query, e sarebbe invalidata tre secondi dopo che l'hai fatta.
>>
>> per ottenere tutti i civici di una strada potresti anche fare una query,
>> nei 99% dei casi non servirebbe nemmeno un tag addr:street, la vicinanza
>> alla strada e le sequenza dei numeri è quasi sempre sufficiente per capire
>> a quale strada appartiene un civico.
>
>
> No, Martin: le relazione "il civico appartiene alla strada" non è
> riducibile ad una query geografica: ci sono troppi casi limite, vicino agli
> incroci, oppure quando un edificio è molto "all'interno" dell'isolato.
> "Scuole di Roma" significa "scuole" (informazione fissa) "la cui posizione
> è all'interno del poligono del Comune di Roma" (query geografica); "civici
> di via Cavour" dovrebbe essere "civici che hanno un collegamento alla
> strada chiamata via Cavour", non, come è adesso, "civici il cui addr:street
> è via Cavour".
>
> Commento anche un altro punto, senza citare, perché in questa discussione
> chilometrica mi sto pure un po' perdendo. "Il nome della strada cambia
> molto raramente". Il vero nome della strada cambia molto raramente, perché
> è raro che via Cavour diventi via Nuovo Nome, ma noi non stiamo parlando
> del nome della strada... stiamo parlando del valore del tag name. È molto
> diverso. Più di una volta abbiamo corretto "via IV Novembre": prima in "via
> IV novembre" (mesi minuscoli), poi in "via 4 novembre" (numeri arabi). E
> poi magari qualcuno ha letto sulla targa "VIA IV NOVEMBRE - GIORNATA
> DELL'UNITÀ NAZIONALE E DELLE FORZE ARMATE" e ha voluto scrivere quello. E
> qualcun altro tre giorni dopo l'ha corretto di nuovo.
>
> Il riassunto è molto semplice: il tag name serve per metterci il nome
> della strada (o la sua migliore approssimazione disponibile). Non possiamo
> dargli ANCHE il compito di tenere i riferimenti: che siano riferimenti ai
> civici o ai marciapiedi o a qualsiasi altra cosa.
>
> Capisco che l'argomento possa non essere chiaro a tutti, ma, dal punto di
> vista dell'integrità dei dati, ripeto, usare il nome come chiave è un
> errore. Lo è stato dai tempi di Talete: il teorema di Pitagora parla di
> cateti e di ipotenuse, non di "lato AB" e "lato BC".
>
> Alcuni, in questa discussione, stanno dicendo "comprendo il problema
> tecnico, ma è meglio (per vari motivi) che le cose rimangano così". Io
> rispetto questo punto di vista: è una decisione, una scelta sulla direzione
> del progetto, una posizione "politica". Una posizione che non condivido, ma
> di fronte al fatto che sono in minoranza non posso che accettarla.
>
> Quello di cui ho paura è che molti invece non abbiano capito il problema
> tecnico. Nella lista dei pro e dei contro richiesta da Lorenzo, io nei pro
> della mappatura piatta (coi soli tag e senza relazioni) metto soltanto che
> può farla anche una scimmia [1]. Se OSM fosse un progetto solo mio (e meno
> male che non lo è! :) ), sarebbe l'approccio che consentirei i primi dieci
> giorni, mentre ho fatto il sistema di base ma non ho ancora offerto uno
> strumento migliore per supportare il lavoro dei contributori. Purtroppo,
> supportare i contributori *perché mappino bene* non è sempre tra le
> priorità di OSM - ripeto, scelta politica alla quale non posso che
> adeguarmi... ma non riesco a non oppormici, soprattutto quando mostra i
> suoi limiti.
>
>
questo significa che i dati non normalizzati raccolti in osm devono essere
processati per poter essere usati in applicazioni un po pou elaborati

Ad esempio un software potrebbe cercare le strade con gli attrbuti ripetuti
su ogni punto e farne una
Se si vuiole occupare meno spazio, ad esempio, o diminuire la possibilità
di disallineamenti

Con conseguenti costi aggiuntivi

Quindi il fatto che la contribuzione sia "semplificata" comporta che
l'utilità dei dati sia diminuita.

E che invece di offrire alternative a soluzioni commerciali concentrate, si
offra un giochino ai mappatori "inesperti"
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Federico Cortese]

2017-12-15 0:23 GMT+01:00 Aury88 :
> questo stando a neis-one...mi ricordo ci fossero altri siti da cui ottenere
> statistiche al riguardo, ma non me li ricordo :-/
>

Puoi usare una query overpass su addr:housenumber=* aggiungendo user:*.
Chiaramente così non restituisce quelli che hai creato, ma tutti
quelli che hai toccato per ultimo, quindi è sempre indicativo.

Ciao,
Federico

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Aury88]

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
> 

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

[Simone Saviolo]

Il giorno 14 dicembre 2017 23:02, Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> > On 14. Dec 2017, at 16:24, Simone Saviolo 
> wrote:
> >
> > Inoltre, fare una categoria "scuole di Roma" è sbagliato: se vuoi tutte
> le scuole di Roma, fai una query. Creare una categoria (con una relazione o
> in qualsiasi altro modo) sarebbe una sorta di cache dei risultati della
> query, e sarebbe invalidata tre secondi dopo che l'hai fatta.
>
> per ottenere tutti i civici di una strada potresti anche fare una query,
> nei 99% dei casi non servirebbe nemmeno un tag addr:street, la vicinanza
> alla strada e le sequenza dei numeri è quasi sempre sufficiente per capire
> a quale strada appartiene un civico.


No, Martin: le relazione "il civico appartiene alla strada" non è
riducibile ad una query geografica: ci sono troppi casi limite, vicino agli
incroci, oppure quando un edificio è molto "all'interno" dell'isolato.
"Scuole di Roma" significa "scuole" (informazione fissa) "la cui posizione
è all'interno del poligono del Comune di Roma" (query geografica); "civici
di via Cavour" dovrebbe essere "civici che hanno un collegamento alla
strada chiamata via Cavour", non, come è adesso, "civici il cui addr:street
è via Cavour".

Commento anche un altro punto, senza citare, perché in questa discussione
chilometrica mi sto pure un po' perdendo. "Il nome della strada cambia
molto raramente". Il vero nome della strada cambia molto raramente, perché
è raro che via Cavour diventi via Nuovo Nome, ma noi non stiamo parlando
del nome della strada... stiamo parlando del valore del tag name. È molto
diverso. Più di una volta abbiamo corretto "via IV Novembre": prima in "via
IV novembre" (mesi minuscoli), poi in "via 4 novembre" (numeri arabi). E
poi magari qualcuno ha letto sulla targa "VIA IV NOVEMBRE - GIORNATA
DELL'UNITÀ NAZIONALE E DELLE FORZE ARMATE" e ha voluto scrivere quello. E
qualcun altro tre giorni dopo l'ha corretto di nuovo.

Il riassunto è molto semplice: il tag name serve per metterci il nome della
strada (o la sua migliore approssimazione disponibile). Non possiamo dargli
ANCHE il compito di tenere i riferimenti: che siano riferimenti ai civici o
ai marciapiedi o a qualsiasi altra cosa.

Capisco che l'argomento possa non essere chiaro a tutti, ma, dal punto di
vista dell'integrità dei dati, ripeto, usare il nome come chiave è un
errore. Lo è stato dai tempi di Talete: il teorema di Pitagora parla di
cateti e di ipotenuse, non di "lato AB" e "lato BC".

Alcuni, in questa discussione, stanno dicendo "comprendo il problema
tecnico, ma è meglio (per vari motivi) che le cose rimangano così". Io
rispetto questo punto di vista: è una decisione, una scelta sulla direzione
del progetto, una posizione "politica". Una posizione che non condivido, ma
di fronte al fatto che sono in minoranza non posso che accettarla.

Quello di cui ho paura è che molti invece non abbiano capito il problema
tecnico. Nella lista dei pro e dei contro richiesta da Lorenzo, io nei pro
della mappatura piatta (coi soli tag e senza relazioni) metto soltanto che
può farla anche una scimmia [1]. Se OSM fosse un progetto solo mio (e meno
male che non lo è! :) ), sarebbe l'approccio che consentirei i primi dieci
giorni, mentre ho fatto il sistema di base ma non ho ancora offerto uno
strumento migliore per supportare il lavoro dei contributori. Purtroppo,
supportare i contributori *perché mappino bene* non è sempre tra le
priorità di OSM - ripeto, scelta politica alla quale non posso che
adeguarmi... ma non riesco a non oppormici, soprattutto quando mostra i
suoi limiti.

Ciao,

Simone

[1] Consentitemi l'espressione colorita e ricordatevi le basi
dell'implicazione logica: "può farla anche una scimmia" non significa che
chi lo fa è una scimmia.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Federico Cortese]

2017-12-15 8:57 GMT+01:00 Lorenzo "Beba" Beltrami :
> Non c'è una soluzione più giusta dell'altra. E quindi? Come la mettiamo?
>
> Siccome, come si ricordava giustamente, nessuna delle due modalità è vietata
> invece che fare guerra "di trincea" o "di religione" (perché alla fin fine è
> lì che stiamo scivolando) cerchiamo di trovare un modo che possa far
> coesistere le due cose?
> Ad esempio cerchiamo di fare una lista di pro e contro da cui partire a
> ragionare. Oppure una lista di proposte/richieste/aiuti da fare a chi
> sviluppa i software di editing (grazie a dio non sono migliaia) per
> migliorare l'utilizzo delle due metodologie e risolvere i lati deboli.
> Solo alla fine (non all'inizio) si vedrà se dichiarare una delle due
> impraticabile o desueta (si potrebbe dire anche "deprecabile" perché nella
> discussione ci sta, ma ha un altro significato :P).
>

Ti ringrazio Lorenzo, condivido le tue considerazioni e mi piace molto
il tuo approccio.

Ciao,
Federico

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Lorenzo "Beba" Beltrami]

Ciao a tutti,
anch'io ho la mia esperienza coi civici e anch'io ho a che fare con utenti
alle prime armi (e che non rispondono ai messaggi) nella mia zona.
E mi occupo anche di basi di dati (non sono la mia specializzazione, ma per
lavoro ho a che fare con i database tutti i giorni) e quindi di
normalizzazione.

L'esperienza però mi porta a dire che è ha ragione tanto chi è per
l'utilizzo delle relazioni per diminuire la ridondanza ecc. ecc. che chi è
per la duplicazione per aumentare la facilità di accesso dei dati ecc. ecc..
Per il semplice fatto che tutte e due le modalità hanno dei lati positivi
unici, ovvero che l'altra modalità non ha o che al momento non riesce ad
avere.
Non c'è una soluzione più giusta dell'altra. E quindi? Come la mettiamo?

Siccome, come si ricordava giustamente, nessuna delle due modalità è
vietata invece che fare guerra "di trincea" o "di religione" (perché alla
fin fine è lì che stiamo scivolando) cerchiamo di trovare un modo che possa
far coesistere le due cose?
Ad esempio cerchiamo di fare una lista di pro e contro da cui partire a
ragionare. Oppure una lista di proposte/richieste/aiuti da fare a chi
sviluppa i software di editing (grazie a dio non sono migliaia) per
migliorare l'utilizzo delle due metodologie e risolvere i lati deboli.
Solo alla fine (non all'inizio) si vedrà se dichiarare una delle due
impraticabile o desueta (si potrebbe dire anche "deprecabile" perché nella
discussione ci sta, ma ha un altro significato :P).

My 2 cents.
Lorenzo

P.s.: Cerchiamo di tenere da parte l'esperienza OSMica come fattore. Senza
dubbio c'è chi mappa più di altri o da più tempo, ma questa esperienza
porta alla discussione più casi d'esempio e memoria storica, non più
"uguaglianza degli altri"[1] ;P
[1] https://it.wikiquote.org/wiki/George_Orwell#Comandamenti
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Federico Cortese]

2017-12-15 1:43 GMT+01:00 Catonano :
>
> Federico
> io ho guardato sulla mia zona ma se devo dire il vero il mio problema sono 
> gli edifici che hai importato tu
> Infatti, hai unificato ogni isolato in un unico edificio

Caro Adriano, mi dispiace e mi stupisce l'atteggiamento con cui ti
stai ponendo in questa discussione.
Credo che chi ha appena iniziato a lavorare su OSM dovrebbe avere un
approccio un pochino più modesto e non scagliarsi contro tutti i
mappatori un po' più esperti, pretendendo di portare le verità
assolute.
Fatta questa premessa io non ho assolutamente unito tutti gli edifici,
ma ho importato una CTR 1:5.000 che riportava gli edifici in quel
modo.
Lo consideravo un miglioramento rispetto al nulla assoluto, ma anche
rispetto a ricalcare i fabbricati uno ad uno.
Le sagome che ci sono ora sono molto buone, non resta che dividerle,
quindi se vuoi farlo puoi metterti all'opera e ringraziare chi ti ha
semplificato il lavoro di qualche ordine di grandezza ;)

> Ma invece spesso gli isolati sono molti edifici, ognuno col suo civico, col 
> suo numero di piani
> Per cui aggiungere i civici e altri attributi con Vespucci mentre passeggio 
> non è immediato

Dovresti vedere come era immediato quando c'era il vuoto.
Quello che proponi (divisione fabbricati ed aggiunta piani) è proprio
quello che faccio sempre dopo aver inserito i civici sul posto e
raccolto informazioni su numero piani ecc.
Dai un'occhiata a Lecce o a Tricase:
http://www.openstreetmap.org/way/299719900
http://www.openstreetmap.org/way/379547100
Che puoi meglio apprezzare con la visuale 3D:
http://demo.f4map.com/#lat=40.3543852=18.1794130=18=53.308=-14.61

> L'idea del numero di piani come attributo degli edifici me l'avete fatta 
> venire tu e un altror interlocutore quando ho chiesto a proposito della 
> relazzione di via di Palma. Perche io manco lo sapevo che si dovesse inserire 
> ancheh questo attrributo.
> Ricordi ? Invece di pensare alle relazioni ci sono tanti attributi che puoi 
> inserire prima, mi diceste.
> Naturalmente per inserire i piani gli edifici devono essere separati. Spesso 
> ci sono palazzzi dell'iizio del 900 accanto a palazzi anni 70
> Ho provato a dividere i tracciati di nuovo, a mano, ma non mi riesce, ci 
> metto troppo tempo, spesso le foto sono sgranate e non allineate
> Probabilmente sarebbe stato meglio mantenere l'articolazione degli edifici 
> importati dalle carte tecniche della regione

Quali? Io ho importato proprio quelli. Hai mai aperto gli shapefile
della regione?
Adriano prima di sparare cavolate documentati per favore.
Sulla CTR c'è un altro layer lineare, con alcune divisioni interne dei
fabbricati, ma sono poche e non così precise: se fossero state buone
avrebbero diviso i fabbricati invece che lasciare i cassoni.
Ad ogni modo se c'è una base dati più precisa per Taranto puoi
impostare un nuovo import, io ci ho messo un anno prima di poterlo
fare, non perchè non lo sapessi fare tecnicamente, ma perchè non avevo
l'esperienza e la conoscenza di OSM sufficiente per potermici
cimentare.
Se ci metti molto tempo a dividere gli edifici è perchè non hai
pratica, come non ne avevo io tre anni fa! Ora ci metto pochissimo.
Inizia a farlo e ne riparliamo tra tre anni ;)

> Avevo anchhe ipotizzato di chhiedere alla comunità aiuto nell'eliminare 
> alcune delle tue importazioni, magari suu un'area ristretta
> Ma l'andamento di questa discssione è stato estremamente scoraggiante
> Se per una banalità come la normalizzazione dei dati siamo dovuti arrivare 
> agli insulti, credo che questa comunità sia tossica e non ho molta voglia di 
> averci troppo a che fare
> Mi dispiace, perche sarei stato entusiasta di lavorare sulla mia zona, visto 
> che su questa zona ci sei solo tu e poco altro
> Ma siete davvero bravissimi a scoraggiare i nuovi, specie se hanno rudimenti 
> di basi dati

Mi spiace davvero che tu mi risponda in questo modo, visto che io non
ti ho mai attaccato, anzi ti ho più volte elogiato.
A questo punto dovresti solo porti qualche domanda sul fatto se sia la
comunità ad essere tossica o se sia il tuo modo di porti a suscitare
certe reazioni.

> Considerato che hai scritto che non vedi cosa aggiunga una relazione per una 
> strada, direi che non le conosci abbastanza bene

Ti faccio i miei complimenti visto che con soli 298 changeset e soli
2807 cambiamenti conosci OSM meglio di tutti quelli che partecipano a
questa discussione.

> però se mi offro di aiutare raccolgo reazioni indignate e ferite

Più che di aiutare ti sei offerto di risolvere tutti i problemi di
mappatura dei civici.

>> di mapping perfetto (copia di tag/geometrie versus relazioni, ecc.),
>> ma a mio avviso la cosa più importante è contribuire mappando sul
>> posto, quindi raccogliendo informazioni che nessun altro può avere da
>> remoto!
>
>
> sono daccordo
>

ne sono contento :)

> È chiaro che non voglio impedire nulla a nessuno
> Stavo cercando di illustrare i vantaggi per tutti della normalizzazione 

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

[Catonano]

Il giorno 14 dicembre 2017 23:09, Federico Cortese 
ha scritto:

> Provocazione: dei partecipanti a questa discussione quanti mappano
> frequentemente numeri civici sul posto?
> Io ne ho inseriti quasi 3.000, sempre copiando i tag su ogni nodo,
> quindi senza usare le relazioni.
>

Federico

io ho guardato sulla mia zona ma se devo dire il vero il mio problema sono
gli edifici che hai importato tu

Infatti, hai unificato ogni isolato in un unico edificio

Ma invece spesso gli isolati sono molti edifici, ognuno col suo civico, col
suo numero di piani

Per cui aggiungere i civici e altri attributi con Vespucci mentre passeggio
non è immediato 

L'idea del numero di piani come attributo degli edifici me l'avete fatta
venire tu e un altror interlocutore quando ho chiesto a proposito della
relazzione di via di Palma. Perche io manco lo sapevo che si dovesse
inserire ancheh questo attrributo.

Ricordi ? Invece di pensare alle relazioni ci sono tanti attributi che puoi
inserire prima, mi diceste.

Naturalmente per inserire i piani gli edifici devono essere separati.
Spesso ci sono palazzzi dell'iizio del 900 accanto a palazzi anni 70

Ho provato a dividere i tracciati di nuovo, a mano, ma non mi riesce, ci
metto troppo tempo, spesso le foto sono sgranate e non allineate

Probabilmente sarebbe stato meglio mantenere l'articolazione degli edifici
importati dalle carte tecniche della regione

Avevo anchhe ipotizzato di chhiedere alla comunità aiuto nell'eliminare
alcune delle tue importazioni, magari suu un'area ristretta

Ma l'andamento di questa discssione è stato estremamente scoraggiante

Se per una banalità come la normalizzazione dei dati siamo dovuti arrivare
agli insulti, credo che questa comunità sia tossica e non ho molta voglia
di averci troppo a che fare

Mi dispiace, perche sarei stato entusiasta di lavorare sulla mia zona,
visto che su questa zona ci sei solo tu e poco altro

Ma siete davvero bravissimi a scoraggiare i nuovi, specie se hanno
rudimenti di basi dati 

Premetto che le relazioni le conosco abbastanza bene, considerato che
> quando ho iniziato a mappare usavo relazioni per qualunque cosa, pur
> di non tracciare linee sovrapposte.
>

Considerato che hai scritto che non vedi cosa aggiunga una relazione per
una strada, direi che non le conosci abbastanza bene

E considera che abbiamo parlato (tentato di parlare) solo dell'aspetto
della gestione dei dati (alcuni errori di OSMinspector non sarebbero tali
se il nome della strada fosse scritto una volta sola)

E non, ad esempio, del routing per i pedoni, che la relazione street, coi
marciapiedi, consente ai software (le way e altre soluzioni sono inferiori)

Ricordo con certezza di aver letto di almeno un software chhe legge le
relazioni street per questa cosa. Adesso sono stanco ma se sei curioso ti
cerco questa cosa

In questi 3 anni però, oltre a fornire i miei contributi, ho tenuto
> sotto controllo tutto quello che avviene nelle tre provincie a me
> vicine, quindi ho un'idea molto chiara delle modifiche che vengono
> apportate alla mappa da nuovi e vecchi mappatori.
> Questa esperienza mi ha portato a capire come sia ostico per molti
> l'uso delle relazioni,


però se mi offro di aiutare raccolgo reazioni indignate e ferite


> ma anche che la cosa più importante non è la
> perfezione geometrica (per quanto io la insegua) o trovare il metodo
>

con gli edifici ne sarebbe servita un po di piú 


> di mapping perfetto (copia di tag/geometrie versus relazioni, ecc.),
> ma a mio avviso la cosa più importante è contribuire mappando sul
> posto, quindi raccogliendo informazioni che nessun altro può avere da
> remoto!
>

sono daccordo



> Mi spiace che persone in gamba come Catonano possano essere
> scoraggiate o contrariate da non poter ottenere la perfezione che
> cercano da uno strumento come OSM, ma è un tratto comune a chi magari
> ha molta dimestichezza coi database o con i GIS ed è abituato ad
> utilizzarli per scopi professionali; essendo uno strumento
> collaborativo però bisogna in primo luogo adattarsi ad avere
> contributi di diverso livello (la cosa fondamentale è che siano
> contributi genuini), in secondo luogo permettere a chi vuole
> contribuire di farlo con semplicità.
>

È chiaro che non voglio impedire nulla a nessuno

Stavo cercando di illustrare i vantaggi per tutti della normalizzazione dei
dati

Devo dire che sono sorpreso della resistenza incontrata su una questione
banale come la norrmalizzazione in una comunità che mantiene una grossa
base dati 


>
> Ciao,
> Federico
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Catonano]

Il giorno 14 dicembre 2017 21:26, Aury88  ha
scritto:

> Catonano wrote
> > e se io mi devo aspettare di farmi rovinare il lavoro da "inesperti" non
> > lo
> > faccio dall'inizio
> >
> > Per questo se ne discute qui
> >
> > Invece di pretendere di conservare la caratterizzaione di "inesperto"
> > dovreste imparare a usare le relazioni ed essere cosìi un po'meno
> > inesperti
>
>  non pretendo di conservare alcunchè  e (grazie) so usare perfettamente le
> relazioni (quelle ben documentate) e le uso quando servono e sono
> necessarie.personalmente  non pretendo nulla, ma mi aspetto in un progetto
> come osm che quando si fanno delle scelte/proposte si facciano tenendo in
> considerazione chi effettivamente inserisce i dati che, mi spiace dirlo,
> nella maggior parte dei casi non sono ne esperti ne lo vogliono diventare.
> questa è la situazione ed è dovuta al fatto che OSM è nato così e senza
> imporre criteri di accesso/contributo basati su sperienza/conoscenza.
> Grazie a questo fatto ci sono dei vantaggi come il numero di contribui e la
> loro diffusione più o meno capillare sul territorio che permettono
> generalmente veloci aggiornamenti, dall'altro ha svantaggi come la qualità
> del singolo contributo. non ti piace la situazione? proponi la questione
> nella sede adatta.
>

e non è questa la sede adatta ?


> dove ti avrei detto di farlo dopo l'esserti "fatto rovinare il lavoro da
> non
> inesperti"?...ti ho consigliato di fare la proposta  nella sede opportuna
> che per il tag addr:street dovrebbe essere la mailing list che copre questi
> territori [1]. nientaltro...mi sembrava implicito nel termine proposta il
> fatto che si faccia prima di fare alcunchè.
>

e non è questa la mailing list che copre quei territori ?
Non mi risulta chhe ci sia una mailing list pugliese


>
> > ...inoltre se non vado errato la cosa
> > dovrebbe comportare l'eliminazione del tag name dalla way ( o
> rischiereste
> > il disallineamento tra il tag della way e il tag della relazione)
>
>
> > un sofftware ben fatt non considera il nome sulla way se questa
> appartiene
> > a una relazione
>
> quindi? hai un software ben fatto sotto mano da proporci? hai già istruito
> anche agli altri sviluppatori su come si faccia un buon software?
>

No, non ho un sw sotto mano

Ma se le relazioni non si creano un sw così non esisterà mai e la gestione
di osm sarà più faticosa e farraginosa di quanto servorebbe
Come ho già scritto: na profezia che si autoavvera


>
>
> > Il render si può aggiornare
> > ci sono librerie che fanno il rendering in locale, nel browser
> >
> > Le cose non sono scritte nelle tavole della legge
>
> Lo hai già fatto? è già adottato da osm? c'è già qualcosa o dobbiamo
> sperare
>

lo ha fatto mapbox. Ne avrai sentito parlare


> che tra il momento dell'introduzione del nuovo stile e il momento
> dell'introduzione del nuovo render (se mai il nuovo stile diventi
> abbastanza
> diffuso da richiederlo)


se le relazioni non si useranno non sarà mai abbastanza difffuso
Com'era ? La proffezia che si autoavvera
A discapito della qualità dei dati


> nessuno si decida a modificare quello che a tutti
> gli effetti attualmente  apparirebbe erroneamente come un errore e non
> decida di inserire il vecchio tag apportando una ridondanza questa si
> inutile e disallineata?
> È anche  per questo che suggerisco di parlarne nella sede opportuna invece
> che in una mailinglist che non può decidere sullo stile di mappatura usato
> a
> livello globale.
>

su questo ti do ragione. Avevo capito che la sede competente fosse questa


> nessuno ha mai detto che non si possono cambiare...ma c'è un modo
> intelligente, organizzato di farlo e c'è il modo estremamente dannoso...il
> primo richiede necessariamente una discussione  ed una generale
> approvazione
> nella sede appropriata
>

ripeto: pensavo di essere nella sede appropriata


>
> >>
> >> > A me sembra assurdo il contrario
> >> >
> >> > Che si debba essere lenti a correggere i dati e farlo con maggior
> >> fatica
> >> > del necessario per scelta.
> >>
> >> quindi fammi capire bene. nell'eventualità che qualcuno si scordi di
> >> modificare il tag addr:street nell'eventualità di un cambio del name di
> >> una
> >> strada (dovuto ad errore o a cambio di denominazione) io dovrei ogni
> >> volta
> >> realizzare una relazione per ogni strada
> >
> >
> > le strade non cambiano nome a gruppi, di solito
>
> rileggi bene, l'eventualità è che qualche strada abbia nomi errati, la tua
> soluzione è cambiare stile di mappatura per tutte le strade, o sbaglio?
>

Sbagli

Non è necessario cambiarle tutte di botto

Come ho già scritto, puoi cominciare da quelle a cui tieni di più, per
qualche ragione
Quelle che hanno più civici, che quindi sono più esposte al riscio di
disallineamenti nel nome della strada
Oppure quelle che conosci meglio

Ho scritto forse da qualche parte che dovrebbe essere fatto di botto ?
Non mi pare, mi pare di aver scritto il contrario, questa è giá la 

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

[Catonano]

Il giorno 14 dicembre 2017 23:59, Aury88  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


>
>
> >> cuisine=italian... e continuiamo  così per tutti gli altri tag.
> >> non stiamo parlando di dati identificati solo dal loro tag, come può
> >> esserlo
> >> il nome del povero Walter o della signorina Jose o di tuo nonno Bossi,
> ma
> >> di
> >> dati che hanno una posizione geografica. di conseguenza te li trovi
> >> comunque
> >> a differenza della pensione del signor walter o il diploma della
> >> signorina
> >> Jose o del sig. Bossi, tanto è vero che c'è un tool fatto apposta per
> >> scovare errori del genere
> >> il nodo che dovrebbe essere associato alla via Mario Rossi puoi metterci
> >> anche via Carlo Conti e, con il tool appropriato, scopri subito che c'è
> >> l'errore e con un altrettanto immediato Ctrl+F trovi gli elementi a cui
> >> puoi
> >> così sostituire il value errato a tutti contemporaneamente...  quello
> che
> >> succederà invece con quello che proponi, se non ben gestito in maniera
> >> comunitaria (non locale),
> >
> >
> > che vuol dire non locale ?
>
>  ML-Italia = italiana. addr:street=
> https://taginfo.openstreetmap.org/keys/addr%3Astreet#map


grazie, guarderò


>
>
> >> sarà ritrovarti con il value in una relazione e
> >> probabilmente l'aggiunta da parte di qualcun'altro dei tag addr:street
> ai
> >> nodi  da cui l'avevi cancellato...
> >>
> >
> > che vengano applicati de schemi diversi non è necessariamente un errore.
> > Ogni software può seguire uno schema solo o un mix dei due
>
>  e nonon mi puoi portare avanti la questione del non ripetere lo stesso
> value su più elementi e poi dire di usare uno schema contemporaneamente a
> quello che richiede di ripetere lo stesso value su più elementi. o
> "normalizzi" o non lo fai...


e invece no
Puoi tenere entrambi gli schemi, per un periodo di transizione
Facoltativamente


> non puoi fare entrambi tanto più che i due
> schemi potrebbero generare disallineamenti pericolosi (in caso di errore
> tieni buono quello degli addr:street o quello che viene detto dalla
> relazione?)
>

Ovviamente quello della relazione
 Che siccome deve essere manuteuto una volta sole per tutti i civici si
suppone essere corretto


> > E comunque di errori ce ne sono a milioni
>
>  non è un buon motivo per aggiungerne altri ...fosse veramente utile, ma
> non
> mi sembra lo si sia dimostrato
>

è dimostrato dalle basi dati da 50 anni




>
> > Ripetere la stessa informazioni su decine di nodi e poi consentire alla
> > gente di modifficarla sul singolo nodo CERTAMENTE introduce più errori di
> > quanti ne introdurrebbero le relazioni
> >
> > Del resto questo thread è stato aperto appunto per segnalare una
> situaione
> > di uan strada con decine di errori dovuti a questo schema evidentemente
> > inadeguato. Il copia incolla in questo caso non ha funzionato !!
>
> 1) il copia incolla è quello che faccio io...li non so cosa si sia usato..
> per quanto ne sappia potrebbero anche essere nodi frutto di un import.
>

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


> 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


> 3) il copia incolla non ti cambia il value di un tag che era il caso
> specifico in questione...quindi ripeto  non capisco perchè lo tiri in ballo
> come prova di non efficacia in questo caso.
> 4) qui il problema era probabilmente che i nodi avevano l'addr:street che
> non è stato aggiornato con il cambio del nome della strada. non centra
> nulla
> il copia incolla xD
>

vabbè 


> 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


> e fino 

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

[Aury88]

Federico Cortese wrote
> Provocazione: dei partecipanti a questa discussione quanti mappano
> frequentemente numeri civici sul posto?
> Io ne ho inseriti quasi 3.000, sempre copiando i tag su ogni nodo,
> quindi senza usare le relazioni.
> 
> ___
> Talk-it mailing list

> Talk-it@

> https://lists.openstreetmap.org/listinfo/talk-it

quoto tutto.
per quanto riguarda le statistiche io ho un 6247 addr* creati (sono quasi
tutti con addr:housenumber) e ne ho modificati altri 10253...tutti inseriti
a mano a seguito di sopralluoghi o di ricerche in rete con associata
identificazione del posto da foto aeree in OSM...nessuno di essi in una
relazione.
questo stando a neis-one...mi ricordo ci fossero altri siti da cui ottenere
statistiche al riguardo, ma non me li ricordo :-/

Per l'Italia avevo calcolato in maniera spannometrica ( facendo ipotesi temo
alquanto azzardate) che ogni utente iscritto dovrebbe inserire mediamente
1 civici per avere una copertura completa di tutti i civici di
italia...direi un risultato estremamente inaffidabile x.D



-
Ciao,
Aury
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Aury88]

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 


>> cuisine=italian... e continuiamo  così per tutti gli altri tag.
>> non stiamo parlando di dati identificati solo dal loro tag, come può
>> esserlo
>> il nome del povero Walter o della signorina Jose o di tuo nonno Bossi, ma
>> di
>> dati che hanno una posizione geografica. di conseguenza te li trovi
>> comunque
>> a differenza della pensione del signor walter o il diploma della
>> signorina
>> Jose o del sig. Bossi, tanto è vero che c'è un tool fatto apposta per
>> scovare errori del genere
>> il nodo che dovrebbe essere associato alla via Mario Rossi puoi metterci
>> anche via Carlo Conti e, con il tool appropriato, scopri subito che c'è
>> l'errore e con un altrettanto immediato Ctrl+F trovi gli elementi a cui
>> puoi
>> così sostituire il value errato a tutti contemporaneamente...  quello che
>> succederà invece con quello che proponi, se non ben gestito in maniera
>> comunitaria (non locale),
> 
> 
> che vuol dire non locale ?

 ML-Italia = italiana. addr:street=
https://taginfo.openstreetmap.org/keys/addr%3Astreet#map

>> sarà ritrovarti con il value in una relazione e
>> probabilmente l'aggiunta da parte di qualcun'altro dei tag addr:street ai
>> nodi  da cui l'avevi cancellato...
>>
> 
> che vengano applicati de schemi diversi non è necessariamente un errore.
> Ogni software può seguire uno schema solo o un mix dei due

 e nonon mi puoi portare avanti la questione del non ripetere lo stesso
value su più elementi e poi dire di usare uno schema contemporaneamente a
quello che richiede di ripetere lo stesso value su più elementi. o
"normalizzi" o non lo fai...non puoi fare entrambi tanto più che i due
schemi potrebbero generare disallineamenti pericolosi (in caso di errore
tieni buono quello degli addr:street o quello che viene detto dalla
relazione?) 

> E comunque di errori ce ne sono a milioni

 non è un buon motivo per aggiungerne altri ...fosse veramente utile, ma non
mi sembra lo si sia dimostrato


> Ripetere la stessa informazioni su decine di nodi e poi consentire alla
> gente di modifficarla sul singolo nodo CERTAMENTE introduce più errori di
> quanti ne introdurrebbero le relazioni
> 
> Del resto questo thread è stato aperto appunto per segnalare una situaione
> di uan strada con decine di errori dovuti a questo schema evidentemente
> inadeguato. Il copia incolla in questo caso non ha funzionato !!

1) il copia incolla è quello che faccio io...li non so cosa si sia usato..
per quanto ne sappia potrebbero anche essere nodi frutto di un import.
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
3) il copia incolla non ti cambia il value di un tag che era il caso
specifico in questione...quindi ripeto  non capisco perchè lo tiri in ballo
come prova di non efficacia in questo caso.
4) qui il problema era probabilmente che i nodi avevano l'addr:street che
non è stato aggiornato con il cambio del nome della strada. non centra nulla
il copia incolla xD

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) e fino ad adesso quello
che ho visto dell'applicazione dello stile mi è sembrata un accozzaglia di
errori o ridondanze tra vecchio e nuovo assolutamente inutili...sarò stato
sfigato io nel guardare la zona della spagna dove è male applicato...ma sarà
quello che succederà se la proposta non viene ben discussa e documentata
nella sede opportuna


>> > Questo è di nuovo un problema dell'editor. Se esiste uno strumento (le
>> > relazioni) che permette di normalizzare i dati *e quindi migliorarne la
>> > qualità*, devo usarlo. Se è complicato usarlo nell'editor, l'editor va
>> > modificato. Se l'editor rimane così, meglio cercarne un altro.
>>
>> allora modificalo e fai la proposta forte di un editor in grado di
>> gestire
>> facilmente il cambiamento che vuoi introdurre...
> 
> 
> e non desideri nient'altro ?

non vi leggete? è stato lui a dire che va modificato l'editor...bene! visto
che dite che lo stile attualmente usato non va bene e visto che gli editor
quello gestiscono scusami tanto se sono io a chiedervi dove sarebbe 

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

[Catonano]

Il giorno 14 dicembre 2017 21:00, Davide Sandona' 
ha scritto:

> Mai usato OSMInspector. Ma non è necessaio conoscere OSMinspector per
>> sapere come si gestisce una base dati
>>
>
> Un'affermazione abbastanza pretenziosa, non trovi?
>

Sto facendo riferimento alla teoria e alla pratica delle basi dati
relazionali

Per discutere di come si gestisce una base dati conoscere uno strumento
specifico non serve

È come dire che per studiare il moto del proietile ci vuole il tipo di
carta a cuui sei abituato tu

Quindi direi che no, non è pretenzzioso affatto.


> Certo, questo dipende esclusivamente dalla tua definizione di gestione.
> Per esempio, la mia definizione di "gestione di una base dati" comprende
> anche il controllo della qualità dei dati. Probabilmente la tua definizione
> è diversa, magari il tuo approccio non necessita di un controllo, o forse
> te ne freghi della correttezza dei dati.
>

In tutto quetso thread ho discuusso solo di qualità dei dati in rapporto
alla quantità di lavoro che serve a mantenerla

Solo di questo ho parlato, in tutto il thread

Allora o non mi ai letto oppure non hai capito

In entrambi i casi sono sconfortato



>
> Il modo esiste. Per esempio cercare un tragitto con destinazzione nella
>> strada in questione. Se non trovi la strada, il nome è sbagliato
>> Guardi la relazione e ti accorgi che il nome è sbagliato
>>
>
> Ti invito a sviluppare un tool che dimostri il tuo approccio! Non mi
> dispacerebbe affatto vedere una demo.
>

Ti ripeto che la questione non dipende dallo specifico tool

Il tool esiste, si chiama Josm.
Un altro si chiama Vespucci


>
> La ridondanza dei dati é sbagliata, costinge a fare più lavoro e occupa
>> più spazio nel db
>>
>
> Finché non svilupperai il suddetto tool, resto convinto che in un database
> crowdsourced quale OSM la ridondanza di dati critici quali gli addr:street
> sulla numerazione civica è di vitale importanza per garantire che
> incompetenti a caso vadano ad inserire errori che non potranno essere
> trovati sulle relazioni.
>

Che non potranno essere trovati CON IL TUO STRUMENTO
Altrimenti potranno essere trovati benissimo


>
> Ripetere la stessa informazioni su decine di nodi e poi consentire alla
>> gente di modifficarla sul singolo nodo CERTAMENTE introduce più errori di
>> quanti ne introdurrebbero le relazioni
>>
>
> Dipende da come conti gli errori. Se l'incompetente di turno decide che la
> relazione di nome A debba avere il nome errato B, questo errore viene
> trasmesso a tutti gli oggetti contenuti nella relazione. In questo caso, se
> N è il numero di elementi della relazione, ci saranno N+1 errori (compresa
> la relazione stessa). Inoltre, tu che non abiti in quella via e mai ci
> passerai, non avrai alcun modo per affermare se il nome B è corretto o
> sbagliato. Invece, con l'approccio attuale, se lo stesso incompetente
> decide che l'highway di nome A debba avere il nome errato B, e non tocca
> alcun nodo dei civici (proprio perché è un'incompetente), io che da casa
> mia controllo un'area distante centinaia di chilometri (e sono l'unico che
> la controlla), magari riesco anche ad affermare che tale edit è un errore.
> Inoltre, in tal caso avrò solo da sistemare le highway che si spera siano
> in numero inferiore rispetto ai civici associati.
>

Se un incompetente cambia  il nome di una relazione la cosa coinvolgerà
molti civici

Ma per rimettere le cose a posto servirà UN SOLO EDIT, sulla relazione per
rimetterla come stava

Invece col tuo metodo serviranno DIVERSI edit a seconda di quanti ne avrà
fatti l'incompetente in questione

Quindi io misura la quantità di tempo che serve a correggere gli errori,
non il numero di nodi coinvolti

Perche il rapporto ffra numero di nodi coinvolti e la quuantità di temp che
serve a correggere NON E' LINEARE


>
> Del resto questo thread è stato aperto appunto per segnalare una situaione
>> di uan strada con decine di errori dovuti a questo schema evidentemente
>> inadeguato. Il copia incolla in questo caso non ha funzionato !!
>
>
> Questo thread è stato aperto per correggere evidenti problemi relativi ad
> un vecchio import. Ma non puoi assolutamente affermare che il tuo approccio
> sarebbe privo di errori
>

Non hho MAI MAI MAI sostenuto quetsa cosa

Ho sostenuto che il mio approccio richiederebbe meno tempo per mantenere la
base dati in ordine


> . Comunque, l'unico modo che abbiamo per confrontare i due metodi è il
> seguente. Ti prendi un paese che ti piace (ovviamente che abbia i numeri
> civici), lo correggi col tuo metodo, ci scrivi qui in mailing list il nome
> del paese e noi andremo a risolverci tutti i dubbi che chiaramente non
> riusciamo ad esplicare via mail.
>

Si può fare


>
> la "scorrettezza" con cui verrebbero usate le relazioni fa certamente meno
>> danni del replicare i dati col copia e incolla, come dimostra questo thread
>>
>
> la scorrettezza con cui verrebbero usate le relazioni dipende dal livello
> di esperienza 

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

[Federico Cortese]

Provocazione: dei partecipanti a questa discussione quanti mappano
frequentemente numeri civici sul posto?
Io ne ho inseriti quasi 3.000, sempre copiando i tag su ogni nodo,
quindi senza usare le relazioni.
Premetto che le relazioni le conosco abbastanza bene, considerato che
quando ho iniziato a mappare usavo relazioni per qualunque cosa, pur
di non tracciare linee sovrapposte.
In questi 3 anni però, oltre a fornire i miei contributi, ho tenuto
sotto controllo tutto quello che avviene nelle tre provincie a me
vicine, quindi ho un'idea molto chiara delle modifiche che vengono
apportate alla mappa da nuovi e vecchi mappatori.
Questa esperienza mi ha portato a capire come sia ostico per molti
l'uso delle relazioni, ma anche che la cosa più importante non è la
perfezione geometrica (per quanto io la insegua) o trovare il metodo
di mapping perfetto (copia di tag/geometrie versus relazioni, ecc.),
ma a mio avviso la cosa più importante è contribuire mappando sul
posto, quindi raccogliendo informazioni che nessun altro può avere da
remoto!
Mi spiace che persone in gamba come Catonano possano essere
scoraggiate o contrariate da non poter ottenere la perfezione che
cercano da uno strumento come OSM, ma è un tratto comune a chi magari
ha molta dimestichezza coi database o con i GIS ed è abituato ad
utilizzarli per scopi professionali; essendo uno strumento
collaborativo però bisogna in primo luogo adattarsi ad avere
contributi di diverso livello (la cosa fondamentale è che siano
contributi genuini), in secondo luogo permettere a chi vuole
contribuire di farlo con semplicità.

Ciao,
Federico

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Martin Koppenhoefer]

sent from a phone

> On 14. Dec 2017, at 16:24, Simone Saviolo  wrote:
> 
> Inoltre, fare una categoria "scuole di Roma" è sbagliato: se vuoi tutte le 
> scuole di Roma, fai una query. Creare una categoria (con una relazione o in 
> qualsiasi altro modo) sarebbe una sorta di cache dei risultati della query, e 
> sarebbe invalidata tre secondi dopo che l'hai fatta. 


per ottenere tutti i civici di una strada potresti anche fare una query, nei 
99% dei casi non servirebbe nemmeno un tag addr:street, la vicinanza alla 
strada e le sequenza dei numeri è quasi sempre sufficiente per capire a quale 
strada appartiene un civico.

Ciao, Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Aury88]

Catonano wrote
> e se io mi devo aspettare di farmi rovinare il lavoro da "inesperti" non
> lo
> faccio dall'inizio
> 
> Per questo se ne discute qui
> 
> Invece di pretendere di conservare la caratterizzaione di "inesperto"
> dovreste imparare a usare le relazioni ed essere cosìi un po'meno
> inesperti

 non pretendo di conservare alcunchè  e (grazie) so usare perfettamente le
relazioni (quelle ben documentate) e le uso quando servono e sono
necessarie. l'unica cosa che mi apetto (io non pretendo nulla), in un
progetto come osm o wikipedia, è che quando si fanno delle scelte/proposte
si facciano tenendo in considerazione chi effettivamente inserisce i dati
che, mi spiace dirlo, nella maggior parte dei casi non sono ne esperti ne lo
vogliono diventare. questa è la situazione ed è dovuta al fatto che OSM è
nato così e senza imporre criteri di accesso/contributo basati su
sperienza/conoscenza. 
Grazie a questo fatto ci sono dei vantaggi come il numero di contribui e la
loro diffusione più o meno capillare sul territorio che permettono
generalmente veloci aggiornamenti, dall'altro ha svantaggi come la qualità
del singolo contributo. non ti piace la situazione? proponi la questione
nella sede adatta e non ti ho mai detto di farlo dopo l'esserti "fatto
rovinare il lavoro da inesperti"...ti ho consigliato di fare la proposta 
nella sede opportuna che per il tag addr:street dovrebbe essere la mailing
list che copre questi territori [1]...che una proposta venga prima
dell'azione mi sembrava onestamente implicito nel termine "proposta" 


> ...inoltre se non vado errato la cosa
> dovrebbe comportare l'eliminazione del tag name dalla way ( o rischiereste
> il disallineamento tra il tag della way e il tag della relazione)


> un sofftware ben fatt non considera il nome sulla way se questa appartiene
> a una relazione

quindi? hai un software ben fatto sotto mano da proporci?


> Il render si può aggiornare
> ci sono librerie che fanno il rendering in locale, nel browser
> 
> Le cose non sono scritte nelle tavole della legge

Lo hai già fatto? c'è già qualcosa o dobbiamo sperare che tra il momento
dell'introduzione del nuovo stile e il momento dell'introduzione del nuovo
render (se mai il nuovo stile diventi abbastanza diffuso da richiederlo)
nessuno si decida a modificare quello che a tutti gli effetti appare
erroneamente come un errore e non decida di reintrodurre il vecchio tag
apportando una ridondanza questa si dannosa. 
e per questo che suggerisco di parlarne nella sede opportuna invece di stare
a perdere tempo in una mailinglist che non può decidere sullo stile di
mappatura usato a livello globale.  
scusami, dove avrei detto che le cose non possono essere cambiate? io ho
detto che per un cambiamento del genere è opportuna una discussione in una
ML appropriata e non nella ML italiana

>>
>> > A me sembra assurdo il contrario
>> >
>> > Che si debba essere lenti a correggere i dati e farlo con maggior
>> fatica
>> > del necessario per scelta.
>>
>> quindi fammi capire bene. nell'eventualità che qualcuno si scordi di
>> modificare il tag addr:street nell'eventualità di un cambio del name di
>> una
>> strada (dovuto ad errore o a cambio di denominazione) io dovrei ogni
>> volta
>> realizzare una relazione per ogni strada
> 
> 
> le strade non cambiano nome a gruppi, di solito
>> rileggi bene, l'eventualità è che qualche strada abbia nomi errati, la
>> tua soluzione è cambiare stile di mappatura per tutte le strade, o
>> sbaglio? be...le strade le devi cambiare tutte allora...che abbiano un
>> cambiamento del nome o meno
 e  ricordarmi di inserirci ogni
 singolo elemento che ha come indirizzo l'appartenenza a quella
 strada...

>>> 
>>> Nossignore
>>> Se la relazione esiste già, basta cambiarle il nome. I civici dovrebbero
>>> appartenerle già
>>> 
>>> Se non appartenggono già alla relazione bisogna aggiungerli
>>> 
>>> Del resto se la strada ha cambiato nome li dovresti editare tutti
>>> comunque
>> continui a concentrarti sul cambio nome che è un evento raro (da me
>> l'ultimo avvenuto 3-4 anni fa per l'unione di due comuni). ma anche così
>> ripeto Ctrl+F e li edito tutti. tempo al cronometro? 10 secondi.
>>  io parlavo del caso di aggiungere un nuovo civico. allo stato attuale è
>> un ctrl+c di uno già esistente ctrl+v +modifica del civico. nel tuo caso
>> è gli stessi identici passaggi+ apertura della relazione (se esiste già,
>> altrimenti crearla)+ aggiunta elemento come membro + aggiunta ruolo 
>>> Se mappi un solo civico basta aggiungerlo alla relazione
>>> 
>>> E'un edit in più
>>  se non c'era la relazione devo crearla e anche se ci fosse già dovrei
>> aggiungere anche il ruolo...veloce ma direi assolutamente equivalente
>> all'aggiungere il tag addr:street=nome della via
>>>  la strada cambierà nome e hhai la relazione popolata, dovrai cambiarre
>>> solo la relazione
>>> 
>>> Altrimenti dovrai cambiare tutti i civici. Molto velocemente, immagino
>>  non solo molto veloce, quasi quanto 

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

[Aury88]

Catonano wrote
> e se io mi devo aspettare di farmi rovinare il lavoro da "inesperti" non
> lo
> faccio dall'inizio
> 
> Per questo se ne discute qui
> 
> Invece di pretendere di conservare la caratterizzaione di "inesperto"
> dovreste imparare a usare le relazioni ed essere cosìi un po'meno
> inesperti

 non pretendo di conservare alcunchè  e (grazie) so usare perfettamente le
relazioni (quelle ben documentate) e le uso quando servono e sono
necessarie.personalmente  non pretendo nulla, ma mi aspetto in un progetto
come osm che quando si fanno delle scelte/proposte si facciano tenendo in
considerazione chi effettivamente inserisce i dati che, mi spiace dirlo,
nella maggior parte dei casi non sono ne esperti ne lo vogliono diventare.
questa è la situazione ed è dovuta al fatto che OSM è nato così e senza
imporre criteri di accesso/contributo basati su sperienza/conoscenza. 
Grazie a questo fatto ci sono dei vantaggi come il numero di contribui e la
loro diffusione più o meno capillare sul territorio che permettono
generalmente veloci aggiornamenti, dall'altro ha svantaggi come la qualità
del singolo contributo. non ti piace la situazione? proponi la questione
nella sede adatta.
dove ti avrei detto di farlo dopo l'esserti "fatto rovinare il lavoro da non
inesperti"?...ti ho consigliato di fare la proposta  nella sede opportuna
che per il tag addr:street dovrebbe essere la mailing list che copre questi
territori [1]. nientaltro...mi sembrava implicito nel termine proposta il
fatto che si faccia prima di fare alcunchè.

> ...inoltre se non vado errato la cosa
> dovrebbe comportare l'eliminazione del tag name dalla way ( o rischiereste
> il disallineamento tra il tag della way e il tag della relazione)


> un sofftware ben fatt non considera il nome sulla way se questa appartiene
> a una relazione

quindi? hai un software ben fatto sotto mano da proporci? hai già istruito
anche agli altri sviluppatori su come si faccia un buon software?


> Il render si può aggiornare
> ci sono librerie che fanno il rendering in locale, nel browser
> 
> Le cose non sono scritte nelle tavole della legge

Lo hai già fatto? è già adottato da osm? c'è già qualcosa o dobbiamo sperare
che tra il momento dell'introduzione del nuovo stile e il momento
dell'introduzione del nuovo render (se mai il nuovo stile diventi abbastanza
diffuso da richiederlo) nessuno si decida a modificare quello che a tutti
gli effetti attualmente  apparirebbe erroneamente come un errore e non
decida di inserire il vecchio tag apportando una ridondanza questa si
inutile e disallineata? 
È anche  per questo che suggerisco di parlarne nella sede opportuna invece
che in una mailinglist che non può decidere sullo stile di mappatura usato a
livello globale.  
nessuno ha mai detto che non si possono cambiare...ma c'è un modo
intelligente, organizzato di farlo e c'è il modo estremamente dannoso...il
primo richiede necessariamente una discussione  ed una generale approvazione
nella sede appropriata

>>
>> > A me sembra assurdo il contrario
>> >
>> > Che si debba essere lenti a correggere i dati e farlo con maggior
>> fatica
>> > del necessario per scelta.
>>
>> quindi fammi capire bene. nell'eventualità che qualcuno si scordi di
>> modificare il tag addr:street nell'eventualità di un cambio del name di
>> una
>> strada (dovuto ad errore o a cambio di denominazione) io dovrei ogni
>> volta
>> realizzare una relazione per ogni strada
> 
> 
> le strade non cambiano nome a gruppi, di solito

rileggi bene, l'eventualità è che qualche strada abbia nomi errati, la tua
soluzione è cambiare stile di mappatura per tutte le strade, o sbaglio?
quindi le strade non cambieranno nomi a gruppi, ma di fatto il passaggio al
nuovo stile sarà fatto in maniera massiva, per tutte le strade...con nomi
cambiati o meno

>> e  ricordarmi di inserirci ogni
>> singolo elemento che ha come indirizzo l'appartenenza a quella strada...
>>
> 
> Nossignore
> Se la relazione esiste già, basta cambiarle il nome. I civici dovrebbero
> appartenerle già
> 
> Se non appartenggono già alla relazione bisogna aggiungerli
> 
> Del resto se la strada ha cambiato nome li dovresti editare tutti comunque

continui a concentrarti sul cambio nome che è un evento raro (da me l'ultimo
avvenuto 2 anni fa per l'unione di due comuni). ma anche così ripeto Ctrl+F
e li edito tutti. tempo al cronometro? 10 secondi.
 io parlavo del caso di aggiunta di un nuovo civico. allo stato attuale è un
ctrl+c di uno già esistente ctrl+v +modifica del civico. nel tuo caso
sarebbe gli stessi identici passaggi+ apertura della relazione (se esiste
già, altrimenti crearla)+ aggiunta elemento come membro + aggiunta ruolo


> Se mappi un solo civico basta aggiungerlo alla relazione
> 
> E'un edit in più

 se non c'erano altri civici non devo solo aggiungerlo alla relazione, devo
realizzare la relazione e aggiungere ai 2 membri il proprio ruolo(street e
house). se la relazione già c'è è una selezione della relazione, un'aggiunta
di un membro 

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

[Davide Sandona']

>
> Mai usato OSMInspector. Ma non è necessaio conoscere OSMinspector per
> sapere come si gestisce una base dati
>

Un'affermazione abbastanza pretenziosa, non trovi? Certo, questo dipende
esclusivamente dalla tua definizione di gestione. Per esempio, la mia
definizione di "gestione di una base dati" comprende anche il controllo
della qualità dei dati. Probabilmente la tua definizione è diversa, magari
il tuo approccio non necessita di un controllo, o forse te ne freghi della
correttezza dei dati.

Il modo esiste. Per esempio cercare un tragitto con destinazzione nella
> strada in questione. Se non trovi la strada, il nome è sbagliato
> Guardi la relazione e ti accorgi che il nome è sbagliato
>

Ti invito a sviluppare un tool che dimostri il tuo approccio! Non mi
dispacerebbe affatto vedere una demo.

La ridondanza dei dati é sbagliata, costinge a fare più lavoro e occupa più
> spazio nel db
>

Finché non svilupperai il suddetto tool, resto convinto che in un database
crowdsourced quale OSM la ridondanza di dati critici quali gli addr:street
sulla numerazione civica è di vitale importanza per garantire che
incompetenti a caso vadano ad inserire errori che non potranno essere
trovati sulle relazioni.

Ripetere la stessa informazioni su decine di nodi e poi consentire alla
> gente di modifficarla sul singolo nodo CERTAMENTE introduce più errori di
> quanti ne introdurrebbero le relazioni
>

Dipende da come conti gli errori. Se l'incompetente di turno decide che la
relazione di nome A debba avere il nome errato B, questo errore viene
trasmesso a tutti gli oggetti contenuti nella relazione. In questo caso, se
N è il numero di elementi della relazione, ci saranno N+1 errori (compresa
la relazione stessa). Inoltre, tu che non abiti in quella via e mai ci
passerai, non avrai alcun modo per affermare se il nome B è corretto o
sbagliato. Invece, con l'approccio attuale, se lo stesso incompetente
decide che l'highway di nome A debba avere il nome errato B, e non tocca
alcun nodo dei civici (proprio perché è un'incompetente), io che da casa
mia controllo un'area distante centinaia di chilometri (e sono l'unico che
la controlla), magari riesco anche ad affermare che tale edit è un errore.
Inoltre, in tal caso avrò solo da sistemare le highway che si spera siano
in numero inferiore rispetto ai civici associati.

Del resto questo thread è stato aperto appunto per segnalare una situaione
> di uan strada con decine di errori dovuti a questo schema evidentemente
> inadeguato. Il copia incolla in questo caso non ha funzionato !!


Questo thread è stato aperto per correggere evidenti problemi relativi ad
un vecchio import. Ma non puoi assolutamente affermare che il tuo approccio
sarebbe privo di errori. Comunque, l'unico modo che abbiamo per confrontare
i due metodi è il seguente. Ti prendi un paese che ti piace (ovviamente che
abbia i numeri civici), lo correggi col tuo metodo, ci scrivi qui in
mailing list il nome del paese e noi andremo a risolverci tutti i dubbi che
chiaramente non riusciamo ad esplicare via mail.

la "scorrettezza" con cui verrebbero usate le relazioni fa certamente meno
> danni del replicare i dati col copia e incolla, come dimostra questo thread
>

la scorrettezza con cui verrebbero usate le relazioni dipende dal livello
di esperienza dell'utente di turno (o del troll di turno).

Questo denuncia su quanto è complicato è francamente imbarazzante 
> Non è complicato affatto.
> Organizziamo un workshop ?
> Mapping avanzato: come e perchè si usano le relazioni. Rigorosamente con
> Josm e Vespucci
> Ve lo spiego io
>

Ti prego di organizzarlo, sarà mia premura inviarti 5-6 nomi di persone
menefreghiste rispetto al lavoro altrui che dovrai assolutamente portare al
tuo workshop. Ti faccio già un grande "in bocca al lupo", perché a me non
hanno mai risposto.
E' proprio questo il punto critico che ti ostini a non comprendere: OSM,
nel bene o nel male, è aperto a tutti. Dal principiante al professionista.
Allo stato attuale, il principiante inserisce errori facilmente
identificabili e risolvibili, con il tuo approcio, anche il principiante
riuscirà a fare danni di proporzioni epiche.

Invece io dico: usiamo il metodo delle relazioni perché è evidentemente
> superiore !
>
> Da 4 milioni facciamole salire a 4,2
>

Come ho scritto sopra, prenditi un paese a piacimento, mappalo
correttamente secondo le tue idee, a lavoro completo informaci sulla zona
mappata cosìcché noi comuni mortali possiamo risolverci ogni ombra di
dubbio e saltare felicemente nel tuo treno :) Nel frattempo, buon lavoro!


Davide.

Il giorno 14 dicembre 2017 19:21, Catonano  ha scritto:

> Il giorno 14 dicembre 2017 17:47, Simone Saviolo  > ha scritto:
>
>> Catonano, sono d'accordo con te nei contenuti, ma per favore, modera un
>> po' la forma. In alcuni punti sembri un po' troppo aggressivo: forse lo
>> sembro anch'io, nel qual caso chiedo scusa, non era mia intenzione.
>>
>
> Va bene
>
> 

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

[Martin Koppenhoefer]

sent from a phone

> On 14. Dec 2017, at 16:09, Davide Sandona'  wrote:
> 
> Evidentemente questi utenti non sono consci delle implicazioni di tali 
> modifiche


grazie per questo esempio, che illustra bene cosa anch’io incontro spesso. 

Se sono utenti singoli che lavorano con sistema ha assolutamente senso di 
scrivergli e di spiegare meglio, altrimenti combatti come Don Quixote ;-)

Ciao, Martin 


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Catonano]

Il giorno 14 dicembre 2017 18:40, Aury88  ha
scritto:

> Simone Saviolo wrote
> > Il giorno 14 dicembre 2017 12:24, Aury88 
>
> > spacedriver88@
>
> >  ha
> > scritto:
> >
> > Dove ci potrebbe mai portare il decidere di identificare le persone con
> un
> > codice alfanumerico? Ogni persona ha un nome: non è più semplice scrivere
> > il suo nome su tutte le cose che la riguardano?
> >
> > Fu così che il signor Walter faticò a prendere la pensione, perché i suoi
> > contributi erano stati registrati a Valter. Fu così che la povera Jose
> > dovette farsi riconoscere in tribunale l'accesso all'università, visto
> che
> > sul diploma di maturità c'era scritto Iose. E fu così che mio nonno
> faceva
> > Bosso di cognome mentre tutti i suoi fratelli erano Bossi.
> >
> > Non lo dico io: da quando esistono i database, anzi, diciamo da un mese
> > dopo :) , ci si è resi conto che i dati vanno normalizzati. Le relazioni
> > tra entità diverse non possono essere identificate da dati che possono
> > cambiare. Se mi taglio i capelli, o se mi vesto di verde invece che di
> > rosso, mia moglie o i miei colleghi capiscono che sono ancora io, perché
> > non mi cercano come "quello con la maglia rossa".
>
> ma perchè fermarci li! l'hai detto te no? dobbiamo normalizzare i dati.
> creiamo una relazione al posto del tag amenity=bar e un altro al posto
> dell'amenity=restaurant e in questo ricordiamoci la relazione per la
>

a questa obiezione è già stato risposto che amenity=cafe è un tag fisso,
mentre name="... è free form
Quindi il paragone non regge



> cuisine=italian... e continuiamo  così per tutti gli altri tag.
> non stiamo parlando di dati identificati solo dal loro tag, come può
> esserlo
> il nome del povero Walter o della signorina Jose o di tuo nonno Bossi, ma
> di
> dati che hanno una posizione geografica. di conseguenza te li trovi
> comunque
> a differenza della pensione del signor walter o il diploma della signorina
> Jose o del sig. Bossi, tanto è vero che c'è un tool fatto apposta per
> scovare errori del genere
> il nodo che dovrebbe essere associato alla via Mario Rossi puoi metterci
> anche via Carlo Conti e, con il tool appropriato, scopri subito che c'è
> l'errore e con un altrettanto immediato Ctrl+F trovi gli elementi a cui
> puoi
> così sostituire il value errato a tutti contemporaneamente...  quello che
> succederà invece con quello che proponi, se non ben gestito in maniera
> comunitaria (non locale),


che vuol dire non locale ?


> sarà ritrovarti con il value in una relazione e
> probabilmente l'aggiunta da parte di qualcun'altro dei tag addr:street ai
> nodi  da cui l'avevi cancellato...
>

che vengano applicati de schemi diversi non è necessariamente un errore.
Ogni software può seguire uno schema solo o un mix dei due

E comunque di errori ce ne sono a milioni

Ripetere la stessa informazioni su decine di nodi e poi consentire alla
gente di modifficarla sul singolo nodo CERTAMENTE introduce più errori di
quanti ne introdurrebbero le relazioni

Del resto questo thread è stato aperto appunto per segnalare una situaione
di uan strada con decine di errori dovuti a questo schema evidentemente
inadeguato. Il copia incolla in questo caso non ha funzionato !!


>
>
>
> > Questo è di nuovo un problema dell'editor. Se esiste uno strumento (le
> > relazioni) che permette di normalizzare i dati *e quindi migliorarne la
> > qualità*, devo usarlo. Se è complicato usarlo nell'editor, l'editor va
> > modificato. Se l'editor rimane così, meglio cercarne un altro.
>
> allora modificalo e fai la proposta forte di un editor in grado di gestire
> facilmente il cambiamento che vuoi introdurre...


e non desideri nient'altro ?


> fino ad allora tutti gli
> editor non riconosceranno il tuo metodo o peggio lo classificheranno come
> errore (manca l'addr:street al nodo)


gli editor non sono la legge. Molti editor sono fatti male. Questo non vuol
dire che bisogna mappare male


> e temo sia questo il motivo per cui i
> casi di utilizzo della relazione ne ho visti parecchi errati  o usati in
> maniera ridondante (contemporaneità dei metodi di mappatura) con alcuni
> casi
> disallineati tra quanto indicato sugli indirizzi e quanto indicato nella
> relazione
>

certo. Mantenere cento copie della stessa informazione, come dimostra
questo thread, è difficile
Per forza che poi ci sono i disallineamenti

E questo thread segnala solo UN caso del genere. Chissá quanti altri ce ne
sono

E comunque se i dati della relazione sono corretti il disallineamento fra i
quei dati e quelli sui singoli nodi conta fino a un certo punto perchè un
software decente potrà leggere solo quelli nella relazione (che
richhiedendo meno lavoro sono pi`affidabili, come testimonia questo thread)
e trascurare quegli altri

Gli antichi egizi hanno costruito le piramidi con le mani, poi è stata
inventata la meccanizzazione


>
> > Immagina di essere il classico magazziniere in un'azienda privata. Ti
> > dicono "da oggi, 

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

[Catonano]

Il giorno 14 dicembre 2017 17:47, Simone Saviolo 
ha scritto:

> Catonano, sono d'accordo con te nei contenuti, ma per favore, modera un
> po' la forma. In alcuni punti sembri un po' troppo aggressivo: forse lo
> sembro anch'io, nel qual caso chiedo scusa, non era mia intenzione.
>

Va bene

Diciamo che dover difendere concetto fondamentali di basi dati relazionali
con gente che dice che il copia e incolla è banale, mi fa innervosire.

Lo stesso dicasi per la street relation che prevede i marciapiedi e quindi
consente il routing pedonale oltre a un rendering più preciso

Della quale è stato scritto qui che non si vede a cosa serva

Mi aspettavo una comunità più consapevole

Se invece la situazione è questa, devo dire che non ho fiducia nel progetto.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Aury88]

Simone Saviolo wrote
> Il giorno 14 dicembre 2017 12:24, Aury88 

> spacedriver88@

>  ha
> scritto:
> 
> Dove ci potrebbe mai portare il decidere di identificare le persone con un
> codice alfanumerico? Ogni persona ha un nome: non è più semplice scrivere
> il suo nome su tutte le cose che la riguardano?
> 
> Fu così che il signor Walter faticò a prendere la pensione, perché i suoi
> contributi erano stati registrati a Valter. Fu così che la povera Jose
> dovette farsi riconoscere in tribunale l'accesso all'università, visto che
> sul diploma di maturità c'era scritto Iose. E fu così che mio nonno faceva
> Bosso di cognome mentre tutti i suoi fratelli erano Bossi.
> 
> Non lo dico io: da quando esistono i database, anzi, diciamo da un mese
> dopo :) , ci si è resi conto che i dati vanno normalizzati. Le relazioni
> tra entità diverse non possono essere identificate da dati che possono
> cambiare. Se mi taglio i capelli, o se mi vesto di verde invece che di
> rosso, mia moglie o i miei colleghi capiscono che sono ancora io, perché
> non mi cercano come "quello con la maglia rossa".

ma perchè fermarci li! l'hai detto te no? dobbiamo normalizzare i dati.
creiamo una relazione al posto del tag amenity=bar e un altro al posto
dell'amenity=restaurant e in questo ricordiamoci la relazione per la
cuisine=italian... e continuiamo  così per tutti gli altri tag. 
non stiamo parlando di dati identificati solo dal loro tag, come può esserlo
il nome del povero Walter o della signorina Jose o di tuo nonno Bossi, ma di
dati che hanno una posizione geografica. di conseguenza te li trovi comunque
a differenza della pensione del signor walter o il diploma della signorina
Jose o del sig. Bossi, tanto è vero che c'è un tool fatto apposta per
scovare errori del genere
il nodo che dovrebbe essere associato alla via Mario Rossi puoi metterci
anche via Carlo Conti e, con il tool appropriato, scopri subito che c'è
l'errore e con un altrettanto immediato Ctrl+F trovi gli elementi a cui puoi
così sostituire il value errato a tutti contemporaneamente...  quello che
succederà invece con quello che proponi, se non ben gestito in maniera
comunitaria (non locale), sarà ritrovarti con il value in una relazione e
probabilmente l'aggiunta da parte di qualcun'altro dei tag addr:street ai
nodi  da cui l'avevi cancellato...



> Questo è di nuovo un problema dell'editor. Se esiste uno strumento (le
> relazioni) che permette di normalizzare i dati *e quindi migliorarne la
> qualità*, devo usarlo. Se è complicato usarlo nell'editor, l'editor va
> modificato. Se l'editor rimane così, meglio cercarne un altro.

allora modificalo e fai la proposta forte di un editor in grado di gestire
facilmente il cambiamento che vuoi introdurre...fino ad allora tutti gli
editor non riconosceranno il tuo metodo o peggio lo classificheranno come
errore (manca l'addr:street al nodo) e temo sia questo il motivo per cui i
casi di utilizzo della relazione ne ho visti parecchi errati  o usati in
maniera ridondante (contemporaneità dei metodi di mappatura) con alcuni casi
disallineati tra quanto indicato sugli indirizzi e quanto indicato nella
relazione


> Immagina di essere il classico magazziniere in un'azienda privata. Ti
> dicono "da oggi, invece di scrivere un numero sui colli col pennarello,
> devi metterci un codice a barre e poi leggere quello". Tu protesti perché
> disegnare il codice a barre col pennarello è una cosa improponibile, e
> leggerlo è complicato. Cosa fa un'azienda sana? Ti mette a disposizione
> una
> stampante di codici a barre e un lettore ottico, e pure un sistema che sa
> gestire l'associazione codice a barre - prodotto. E a quel punto voglio
> vedere se scrivi ancora un numero a caso con il pennarello!
> 
> Beh, in questo caso, l'azienda privata sei tu mappatore, tu sviluppatore,
> tu contributore del progetto OSM.

e no...qui mi sembra tanto che sia il magazziniere (uno dei cinquanta) che
dice "voglio usare il codice a barre" e poi pretenda che l'azienda o il
collega magaziniere gli procuri il lettoree che pretenda tutto questo in
un magazzino in cui è già facile trovare i colli e in cui la (rara)
problematica che verrebbe evitata con il codice a barre può essere
facilmente risolta con il sistema già presente ed utilizzato dagli altri 49
magazinieri compresi i 5 neoassunti.
 
> Mi sembra che stiamo volutamente tirando
> il freno a mano. D'accordo, open culture, open source, community, tutto
> bello. Ma prima diciamo che vogliamo fare "il miglior database
> geografico",
> poi, invece di fare un database come se fosse un bell'archivio ordinato e
> referenziato, facciamo in realtà una lista di bigliettini, anzi, di
> etichette (tag), e le appiccichiamo sul muro.

 a me sembra il tuo un freno a mano tanto più che la questione è sistemabile
con un banalissimo Ctrl+F e la tua proposta di fatto serve unicamente ad
evitare l'eventuale problema di disallineamento in caso di eventuale  cambio
nome della strada. cioè per un eventualità, che 

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

[Simone Saviolo]

Catonano, sono d'accordo con te nei contenuti, ma per favore, modera un po'
la forma. In alcuni punti sembri un po' troppo aggressivo: forse lo sembro
anch'io, nel qual caso chiedo scusa, non era mia intenzione.

Aggiungo solo un breve commento alla questione "contributi dei nuovi
utenti". I progetti crowdsourced come OSM fanno spesso riferimento a
Wikipedia. So che è un paragone che regge fino ad un certo punto, ma
ascoltatemi fino in fondo. Wikipedia, la prima volta che modifichi, ti dice
"grazie che vuoi migliorare Wikipedia, qui ci sono le regole". E questo
succede su una piattaforma di puro testo, molto più semplice da controllare
di un database geografico mondiale (la quantità di modifiche è molto più
alta su Wikipedia, però). OSM invece dice "grazie che vuoi migliorare OSM,
qua ci sono delle indicazioni di massima, ma tu fai pure quello che vuoi".
Non possiamo aspettarci dati buoni con questa premessa! :D

Secondo me, gli utenti si dividono in
- contributori esperti: sanno bene come funziona il modello di dati, sanno
proporre modifiche e ragionare sugli schemi di tagging;
- contributori inesperti: conoscono le basi del tagging, non intendono
approfondire (ad esempio il discorso relazioni), ma contribuiscono in
maniera continuativa anche se non spesso;
- contributori occasionali: fanno una modifica e non tornano più.

Ora, sono tutte risorse preziose: persino un occasionale può mappare una
certa amenity che altrimenti verrebbe tralasciata, per dire. E quindi sono
assolutamente a favore del fatto che chiunque possa mappare, anche uno che
non ha capito bene cos'è una way. MA, per questo tipo di utenti, dovrebbero
esistere tool estremamente user-friendly, come ad esempio wheelmap, o
StreetComplete: roba che uno non ha neanche bisogno di sapere cos'è un tag.
Il tuo telefono ti dice "qua c'è un negozio, Pasticceria Dolci Momenti, in
via Cavour 24, è corretto? Sì, No, Correggi nome", "lì c'è un parcheggio
per biciclette, quanti posti ha?" "che superficie c'è su via Cavour? questa
(foto), questa (foto, o questa (foto)?"

Se uno vuole mappare i civici, non ha quasi neanche bisogno di sapere cos'è
JOSM: un'app come Keypad Mapper potrebbe uploadare direttamente. Keypad
Mapper no: inserisce i punti "quasi a caso", non puoi rivederli, ha dei
limiti: è uno strumento per mappatori, non per occasionali. Ma immaginate
un'app che mostra la mappa e la tua posizione: uno tocca la posizione del
civico, inserisce il numero (freeform) e *seleziona la via a cui
appartiene*. Poi conferma e il civico va su. Dov'è la difficoltà? Dov'è la
barriera all'ingresso?

Certo, un'app del genere non esiste. Mi piacerebbe farla, ma temo di non
averne il tempo - non da solo, perlomeno. Ma non dimentichiamo che il
principio fondamentale di ogni macchina è "complesso dentro, semplice
fuori": la macchina fa cose complicate ed è fatta in maniera complicata e
non saprebbero progettarla che dieci persone al mondo, ma se nasconde bene
tutta questa complessità può essere usata anche da un bambino. Oggi invece
stiamo creando un OSM che è "semplice dentro, complicato fuori", in cui i
dati devono essere semplici, e chi vuole interpretarli o inserirli deve
fare fatica.

Ciao,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Simone Saviolo]

Il giorno 14 dicembre 2017 16:49, Davide Sandona' 
ha scritto:

> Capisco, davvero. Ma spero che tu ti renda conto che è un bug che copre un
>> altro bug.
>
>
> Tu lo vedi come un bug che copre un altro bug, io la vedo come un'utile
> ridondanza per effettuare controlli sulla validità dei dati. E' possibile
> farlo con le relazioni street? Non che io ne sia a conoscenza, sentiti
> libero di fornirmi gli strumenti per effettuare validazioni anche con le
> relazioni.
>

Meglio ancora: non è necessario farlo. Questo perché:
1) le associazioni civico-strada sono automaticamente gestite dalle
relazioni. Certo, uno può togliere i civici dai membri della relazione, ma
di certo non può essere un'azione involontaria come può succedere con un
valore freeform sbagliato;
2) la correttezza dei nomi... non esiste. Questo perché i nomi sono valori
freeform. Possiamo trovare gli errori tipo "croso Cavour" con un controllo
ortografico a dizionario; quelli tipo "via Cavuor" con un controllo
ortografico per confronto, sul resto della base dati - e si può fare anche
se fossero tutte relazioni. Ma non puoi stabilire se "via Cavour" sia un
errore o corretto: qualcuno potrà dire che dovrebbe essere "via Camillo
Benso di Cavour", e qualcun altro ti dirà che c'è un atto ufficiale del
Comune che dice solo "via Cavour". A Milano esiste veramente "largo
Buonaparte". L'unico modo per trovare gli errori nei name=* (che sono campi
freeform) è... andare sul posto e leggere cosa c'è scritto.

Ciao,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Catonano]

Il giorno 14 dicembre 2017 16:50, Aury88  ha
scritto:

> Catonano wrote
> > sono tutti casi che si prestano a essere tratatti con relazioni
> > Come ci si regola ?
> >
> > Si propone una relazione e  la si vota
> >
> > E comuqnue chi vorrà mapperà come vuole
> >
> > Esattamente come con le altre feature
>
> quindi proponete la relazione e fatela votare nella discussione adatta e
> non
> in una mailing list locale. e visto che chi vuole può mappare come vuole
> non
> capisco perchè chiedere il permesso,  qui poi. mappate come volete ma poi
> non sorprendetevi se qualcuno riaggiunge i tag addr:street ai nodi che
> modificate "nascondendo" questa informazione in una relazione che quasi
> nessuno conosce o si aspetta di trovare


e se io mi devo aspettare di farmi rovinare il lavoro da "inesperti" non lo
faccio dall'inizio

Per questo se ne discute qui

Invece di pretendere di conservare la caratterizzaione di "inesperto"
dovreste imparare a usare le relazioni ed essere cosìi un po'meno inesperti



> ...inoltre se non vado errato la cosa
> dovrebbe comportare l'eliminazione del tag name dalla way ( o rischiereste
> il disallineamento tra il tag della way e il tag della relazione)


un sofftware ben fatt non considera il nome sulla way se questa appartiene
a una relazione


> ...quindi
> c'è anche la certezza che qualcuno vi modificherà le strade (nominandole
> magari in maniera diversa dalla relazione)  visto che nessun sistema
> attualmente pesca il nome della strada dalla relazione per fare il
> render...e seppur vero che non si mappa per il render è anche vero che il
> 99% della mappatura e correzioni avviene notando degli errori su di
> esso...buona fortuna
>

Il render si può aggiornare
ci sono librerie che fanno il rendering in locale, nel browser

Le cose non sono scritte nelle tavole della legge


>
>
> > A me sembra assurdo il contrario
> >
> > Che si debba essere lenti a correggere i dati e farlo con maggior fatica
> > del necessario per scelta.
>
> quindi fammi capire bene. nell'eventualità che qualcuno si scordi di
> modificare il tag addr:street nell'eventualità di un cambio del name di una
> strada (dovuto ad errore o a cambio di denominazione) io dovrei ogni volta
> realizzare una relazione per ogni strada


le strade non cambiano nome a gruppi, di solito


> e  ricordarmi di inserirci ogni
> singolo elemento che ha come indirizzo l'appartenenza a quella strada...
>

Nossignore
Se la relazione esiste già, basta cambiarle il nome. I civici dovrebbero
appartenerle già

Se non appartenggono già alla relazione bisogna aggiungerli

Del resto se la strada ha cambiato nome li dovresti editare tutti comunque


> magari è solo uno il civico che mappo e quindi dovrei fare questo per

associare due soli elementie questo secondo te sarebbe un essere veloci?
>

Se mappi un solo civico basta aggiungerlo alla relazione

E'un edit in più

Se la strada cambierà nome e hhai la relazione popolata, dovrai cambiarre
solo la relazione

Altrimenti dovrai cambiare tutti i civici. Molto velocemente, immagino



> onestamente fare un Ctrl+F sull'indirizzo errato e cambiare il tag errato
> di
> tutti gli elementi trovati non mi sembra poi tutta questa tragedia rispetto
> il prendere la relazione e farne il cambio tag...
>

buon lavoro


> a questo punto la mia domanda è, visto che con l'attuale metodo aggiungere
> centinaia di nuovi indirizzi per una strada significa fare copia incolla
> del
> primo nodo con i tag corretti e modificare sui nuovi unicamente il valore
> del civico, perchè dovrei essere più lento ad aggiungere dei civici e a
> farlo con maggior fatica?
>

Con la relazione lo fai una volta sola

Senza la relazione lo devi fare ogni volta che la strada cambia nome

Se ai la compiacena di aggiungere i civici a una relaione man mano che li
crei, quando e se la strada cambierà nome, sarrà un solo edit

Altrimenti saranno tanti edit qanti sono i civici di quella strada


> infatti con il copia incolla non copio l'appartenenza alla relazione ma
> solo
> i tag dell'elemento...quindi  con il tuo metodo dovrei fare il copia
> incolla
> modificare il civico e ricordarmi, una volta selezionata la relazione
> giusta,


oh dio, la relaione giusta. Poverino


> di aggiungerci a mano ogni singolo nodo con indirizzomolto più
> lungo e difficile...sperando di non scordarmi qualche elemento.
>

Se ti scorrdi qualcheh elemento lo aggiungerà qualcun altro

Ripet: la relazione si crea una volta sola

Caldeggiare il copia e incolla per mantenere una base dati denormalizzata
non è ragionevole


>
>
> > lo può sempre imparare
> >
> > Pure io ho avuto anni di perplessità su come si usassero le relazioni
> >
> > Semplicemente finche sono stato perplesso non le ho usate
> >
> > Non è caduto il mondo
>
> esattamente...quindi finchè pochissimi sapranno usare quella relazione
> pochissimi contribuiranno ai civici...non cade il mondo per carità! ma
> visto
> che ci sono lamentele sul fatto che siano in 

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

[Catonano]

Il giorno 14 dicembre 2017 16:49, Davide Sandona' 
ha scritto:

> Catonano, dalla tua affermazione è chiaro che non hai mai effettuato alcun
> controllo e modifiche sui numeri civici e che non hai idea del principio di
> funzionamento di OSMInspector.
>

Mai usato OSMInspector. Ma non è necessaio conoscere OSMinspector per
sapere come si gestisce una base dati



> Nella mappa che hai visto non ci sono milioni di punti da correggere, ma
> solamente poche decine di highway da correggere. Se per assurdo, tale zona
> fosse stata mappata con le relazioni e il mappatore di turno avesse
> cambiato il nome della relazione con un nome sbagliato, non esiste ALCUN
> modo di affermare che quello sia un errore,
>

Il modo esiste. Per esempio cercare un tragitto con destinazzione nella
strada in questione. Se non trovi la strada, il nome è sbagliato
Guardi la relazione e ti accorgi che il nome è sbagliato
Non esiste il odo a cui sei abituato tu.
Non esiste "alcun" modo è evidentemente sbagliato



> perché la relazione elimina la ridondanza dei dati.
>

Esatto. Lo scopo delle relazioni è esattamente eliminare la ridondanzza dei
dati

La ridondanza dei dati é sbagliata, costinge a fare più lavoro e occupa più
spazio nel db


> Il controllo degli indirizzi effettuato da OSMInspector è basato sulla
> ridondanza dei dati.
>

Male.


> Se elimini la ridondanza, elimini anche l'unico modo di controllare
> l'integrità dei dati.
>

Nossignore.


> Se voi siete a conoscenza di metodologie che permettono questo livello di
> controllo sui dati attraverso l'uso di relazioni, vi invito a condividerle
> e non tenervele segrete; se non esistono si cercherà di svilupparle. Ma per
> piacere, non spariamo boiate
>

Guarda qui se c'è qualcuno che spara boiate non sono io

Dover insistere su una cosa ocsì ovvia e banale è scoraggiante e
disincentivante alla contribuzione


>
>
>
> Davide.
>
> Il giorno 14 dicembre 2017 16:24, Simone Saviolo  > ha scritto:
>
>> Il giorno 14 dicembre 2017 16:03, Martin Koppenhoefer <
>> dieterdre...@gmail.com> ha scritto:
>>
>>> 2017-12-14 14:59 GMT+01:00 Simone Saviolo :
>>>
 Qualitativamente, no. È vero, le relazioni comportano un *piccolo*
 overhead: da una parte aggiungo un tag a un nodo/way, dall'altro aggiungo
 il nodo/way alla relazione *e* ho una relazione. Ma bada, la relazione con
 mille membri è sempre UNA relazione con mille membri, invece di essere
 mille tag. Non mi sembra che sia un impatto rilevante - ma per scoprirlo
 dovremmo avere numeri, e non li abbiamo.

>>>
>>> i numeri ci sono, non le ho io, ma ho ascoltato chi le aveva. Il "dogma"
>>> "relations are not categories" viene proprio da questo lato. Altrimenti
>>> potresti anche dire: perché scrivere amenity=school mille volte, se posso
>>> avere una relazione "scuole di Roma" dove aggiungo tutte le scuole. Per
>>> esempio.
>>>
>>
>> Infatti sono contrario anch'io alle categorie. Ma questa non è una
>> categoria: è una relazione del tipo "fa parte di", "è associato a".
>>
>> Quanto alle scuole di Roma, non c'entra. amenity=school è un tag fisso;
>> qui stiamo parlando di name=* che è un tag freeform. È sbagliato che un
>> campo freeform venga usato come chiave per una relazione.
>>
>> Inoltre, fare una categoria "scuole di Roma" è sbagliato: se vuoi tutte
>> le scuole di Roma, fai una query. Creare una categoria (con una relazione o
>> in qualsiasi altro modo) sarebbe una sorta di cache dei risultati della
>> query, e sarebbe invalidata tre secondi dopo che l'hai fatta.
>>
>> Ciao,
>>
>> Simone
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Aury88]

Catonano wrote
> sono tutti casi che si prestano a essere tratatti con relazioni
> Come ci si regola ?
> 
> Si propone una relazione e  la si vota
> 
> E comuqnue chi vorrà mapperà come vuole
> 
> Esattamente come con le altre feature

quindi proponete la relazione e fatela votare nella discussione adatta e non
in una mailing list locale. e visto che chi vuole può mappare come vuole non
capisco perchè chiedere il permesso,  qui poi. mappate come volete ma poi
non sorprendetevi se qualcuno riaggiunge i tag addr:street ai nodi che
modificate "nascondendo" questa informazione in una relazione che quasi
nessuno conosce o si aspetta di trovare...inoltre se non vado errato la cosa
dovrebbe comportare l'eliminazione del tag name dalla way ( o rischiereste
il disallineamento tra il tag della way e il tag della relazione)...quindi
c'è anche la certezza che qualcuno vi modificherà le strade (nominandole
magari in maniera diversa dalla relazione)  visto che nessun sistema
attualmente pesca il nome della strada dalla relazione per fare il
render...e seppur vero che non si mappa per il render è anche vero che il
99% della mappatura e correzioni avviene notando degli errori su di
esso...buona fortuna 


> A me sembra assurdo il contrario
> 
> Che si debba essere lenti a correggere i dati e farlo con maggior fatica
> del necessario per scelta.

quindi fammi capire bene. nell'eventualità che qualcuno si scordi di
modificare il tag addr:street nell'eventualità di un cambio del name di una
strada (dovuto ad errore o a cambio di denominazione) io dovrei ogni volta
realizzare una relazione per ogni strada e  ricordarmi di inserirci ogni
singolo elemento che ha come indirizzo l'appartenenza a quella strada...
magari è solo uno il civico che mappo e quindi dovrei fare questo per 
associare due soli elementie questo secondo te sarebbe un essere veloci?
onestamente fare un Ctrl+F sull'indirizzo errato e cambiare il tag errato di
tutti gli elementi trovati non mi sembra poi tutta questa tragedia rispetto
il prendere la relazione e farne il cambio tag...
a questo punto la mia domanda è, visto che con l'attuale metodo aggiungere
centinaia di nuovi indirizzi per una strada significa fare copia incolla del
primo nodo con i tag corretti e modificare sui nuovi unicamente il valore
del civico, perchè dovrei essere più lento ad aggiungere dei civici e a
farlo con maggior fatica?
infatti con il copia incolla non copio l'appartenenza alla relazione ma solo
i tag dell'elemento...quindi  con il tuo metodo dovrei fare il copia incolla
modificare il civico e ricordarmi, una volta selezionata la relazione
giusta, di aggiungerci a mano ogni singolo nodo con indirizzomolto più
lungo e difficile...sperando di non scordarmi qualche elemento. 


> lo può sempre imparare
> 
> Pure io ho avuto anni di perplessità su come si usassero le relazioni
> 
> Semplicemente finche sono stato perplesso non le ho usate
> 
> Non è caduto il mondo

esattamente...quindi finchè pochissimi sapranno usare quella relazione
pochissimi contribuiranno ai civici...non cade il mondo per carità! ma visto
che ci sono lamentele sul fatto che siano in pochi a contribuire alla
mappatura dei civici perchè "troppo tedioso" non lamentiamoci poi se questa
situazione peggiorerà ulteriormente aggiungendo un altro fattore di
rallentamento...
peggio ancora, seguendo il tuo ragionamento del chi vorrà mapperà come
vuole, su 68 milioni di nodi dubito fortemente che con interventi manuali di
modifica si riuscirà a rendere predominante e quindi un dato di fatto il
nuovo metodo...la situazione rimarrà con la stragrande maggioranza che usa
il vecchio e più veloce metodo di mappatura salvo pochissimi che si
accontenteranno di non vedere la proprie strade renderizzate con il nome,  i
propri civici non trovati e la propria mappatura rovinata dall'intervento
periodico di qualcuno che, non aspettandosi di trovare una relazione per
l'indirizzo, vi rimette il nome alla strada e l'addr:street ai civici. 
lo ripeto: secondo me la mailing list locale non è il posto adeguato ne
corretto per discutere una cosa del genere su un elemento del genere...e
peggio ancora fa il mappare come si vuole.

  





-
Ciao,
Aury
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Davide Sandona']

>
> Capisco, davvero. Ma spero che tu ti renda conto che è un bug che copre un
> altro bug.


Tu lo vedi come un bug che copre un altro bug, io la vedo come un'utile
ridondanza per effettuare controlli sulla validità dei dati. E' possibile
farlo con le relazioni street? Non che io ne sia a conoscenza, sentiti
libero di fornirmi gli strumenti per effettuare validazioni anche con le
relazioni.


Se fosse accaduto sulle relazioni invece di dover correggere un milione di
> punti, ne avresti dovuto correggere solo uno.
>
Se OSMInspector non considera le relazioni questa non è una ragione
> generale per non usarle.
>

Catonano, dalla tua affermazione è chiaro che non hai mai effettuato alcun
controllo e modifiche sui numeri civici e che non hai idea del principio di
funzionamento di OSMInspector. Nella mappa che hai visto non ci sono
milioni di punti da correggere, ma solamente poche decine di highway da
correggere. Se per assurdo, tale zona fosse stata mappata con le relazioni
e il mappatore di turno avesse cambiato il nome della relazione con un nome
sbagliato, non esiste ALCUN modo di affermare che quello sia un errore,
perché la relazione elimina la ridondanza dei dati. Il controllo degli
indirizzi effettuato da OSMInspector è basato sulla ridondanza dei dati. Se
elimini la ridondanza, elimini anche l'unico modo di controllare
l'integrità dei dati.
Se voi siete a conoscenza di metodologie che permettono questo livello di
controllo sui dati attraverso l'uso di relazioni, vi invito a condividerle
e non tenervele segrete; se non esistono si cercherà di svilupparle. Ma per
piacere, non spariamo boiate



Davide.

Il giorno 14 dicembre 2017 16:24, Simone Saviolo 
ha scritto:

> Il giorno 14 dicembre 2017 16:03, Martin Koppenhoefer <
> dieterdre...@gmail.com> ha scritto:
>
>> 2017-12-14 14:59 GMT+01:00 Simone Saviolo :
>>
>>> Qualitativamente, no. È vero, le relazioni comportano un *piccolo*
>>> overhead: da una parte aggiungo un tag a un nodo/way, dall'altro aggiungo
>>> il nodo/way alla relazione *e* ho una relazione. Ma bada, la relazione con
>>> mille membri è sempre UNA relazione con mille membri, invece di essere
>>> mille tag. Non mi sembra che sia un impatto rilevante - ma per scoprirlo
>>> dovremmo avere numeri, e non li abbiamo.
>>>
>>
>> i numeri ci sono, non le ho io, ma ho ascoltato chi le aveva. Il "dogma"
>> "relations are not categories" viene proprio da questo lato. Altrimenti
>> potresti anche dire: perché scrivere amenity=school mille volte, se posso
>> avere una relazione "scuole di Roma" dove aggiungo tutte le scuole. Per
>> esempio.
>>
>
> Infatti sono contrario anch'io alle categorie. Ma questa non è una
> categoria: è una relazione del tipo "fa parte di", "è associato a".
>
> Quanto alle scuole di Roma, non c'entra. amenity=school è un tag fisso;
> qui stiamo parlando di name=* che è un tag freeform. È sbagliato che un
> campo freeform venga usato come chiave per una relazione.
>
> Inoltre, fare una categoria "scuole di Roma" è sbagliato: se vuoi tutte le
> scuole di Roma, fai una query. Creare una categoria (con una relazione o in
> qualsiasi altro modo) sarebbe una sorta di cache dei risultati della query,
> e sarebbe invalidata tre secondi dopo che l'hai fatta.
>
> Ciao,
>
> Simone
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Simone Saviolo]

Il giorno 14 dicembre 2017 16:35, Catonano  ha scritto:

> Il giorno 14 dicembre 2017 16:09, Davide Sandona' <
> sandona.dav...@gmail.com> ha scritto:
>
>> Capisco le problematiche esistenti su entrambi gli approcci. Tuttavia, le
>> persone che si occupano della numerazione civica sono assai poche. Le
>> persone che si impegnano dopo un import a correggere i nomi delle vie con i
>> nomi degli nodi-indirizzi sono praticamente inesistenti. Ancor più rare
>> sono le persone che monitorano costantemente tutti gli edit di una
>> determinata area per controllare che non vengano inseriti errori.
>>
>> Da un punto di vista di database, avrebbe assolutamente senso utilizzare
>> le relazioni. Però su OSM operano un sacco di persone che di database e
>> relazioni non sanno assolutamente nulla; cosa significa questo? Qualora una
>> di queste persone vada ad inserire un errore su un nome di una relazione
>> (per ignoranza oppure per sabotaggio) è assai probabile che questo errore
>> sfugga ai controlli. Con le relazioni street, un errore sul nome ricadrebbe
>> su tutti gli oggetti di quella relazione. D'altra parte, se un utente va a
>> cambiare il nome di una highway o di un singolo nodo addr:street, se c'è
>> un'errore questo comparirà su OSMInspector.
>>
>> Voglio portarti un esempio concreto di quanto ho appena affermato. Guarda
>> la provincia di Ferrara [1]. Qualche mese fa mi sono occupato di sistemare
>> i nomi su tutta la provincia, un lavoro enorme, non ti dico quanto tempo ho
>> speso. Su OSMi i puntini rossi li contavi su una mano. Adesso invece puoi
>> notare che è tornato ad essere un campo da guerra. Qualche utente si è dato
>> un gran da fare per abbreviare nuovamente i nomi. Dico io, esiste il tag
>> short_name: se ti sta sulle balle il nome completo abbi la decenza di
>> aggiungere quel tag! Ora, mi conforta il fatto che questi utenti abbiano
>> solo cambiato il nome di un highway e non di tutti i civici. Evidentemente
>> questi utenti non sono consci delle implicazioni di tali modifiche, per
>> fortuna (altrimenti chi li trova più gli errori)  Se il fatto fosse
>> accaduto sulle relazioni, ti sfido a trovare questi problemi!
>>
>
> Se fosse accaduto sulle relazioni invece di dover correggere un milione di
> punti, ne avresti dovuto correggere solo uno.
>
> Se OSMInspector non considera le relazioni questa non è una ragione
> generale per non usarle.
>

No, dice un'altra cosa. Adesso ci sono numerosi oggetti che dovrebbero
avere lo stesso valore nel tag name, perché ad esempio la via è spezzettata
in molte way (sensi unici, obblighi di svolta, etc.). Quindi, se ce ne sono
14 che si chiamano "via Cavour" e uno che si chiama "via Cavuor"
(banalizzo) si nota subito. Invece se uno scrive "name=Via Cavuor" nella
relazione non ci sarebbe modo di accorgersene.

A parte il fatto che se invece fosse il contrario (14 sbagliate e una
giusta) bisognerebbe modificarne 14, quindi generare 14 modifiche nel
database, occupano posto nella history e generano un diff grande...
Ma comunque il controllo sull'ortografia dei nomi per confronto (uno dei
modi per trovare potenziali errori nel freeform) funzionerebbe anche con le
relazioni, solo che invece di esserci 30.000 way chiamate "piazza
Garibaldi" in Italia ci sarebbero 5.000 relazioni, di cui alcune scritte
sbagliate.

Piuttosto, nel caso segnalato da Davide, lui ha usato OSMi come quello che
non è. Guardava la correttezza dei numeri civici, e ha scoperto che
qualcuno ha cambiato i nomi delle strade. Gli serviva un change notifier, e
invece ha usato un QA checker. Incidentalmente, una somma di cattive
abitudini ha portato ad un buon risultato. C'è un termine tecnico per
questa cosa, credo di non aver bisogno di dirlo per far capire che la
prossima volta la somma di bug potrebbe invece nascondere dati pessimi :)

Ciao,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Catonano]

Il giorno 14 dicembre 2017 16:09, Davide Sandona' 
ha scritto:

> Capisco le problematiche esistenti su entrambi gli approcci. Tuttavia, le
> persone che si occupano della numerazione civica sono assai poche. Le
> persone che si impegnano dopo un import a correggere i nomi delle vie con i
> nomi degli nodi-indirizzi sono praticamente inesistenti. Ancor più rare
> sono le persone che monitorano costantemente tutti gli edit di una
> determinata area per controllare che non vengano inseriti errori.
>
> Da un punto di vista di database, avrebbe assolutamente senso utilizzare
> le relazioni. Però su OSM operano un sacco di persone che di database e
> relazioni non sanno assolutamente nulla; cosa significa questo? Qualora una
> di queste persone vada ad inserire un errore su un nome di una relazione
> (per ignoranza oppure per sabotaggio) è assai probabile che questo errore
> sfugga ai controlli. Con le relazioni street, un errore sul nome ricadrebbe
> su tutti gli oggetti di quella relazione. D'altra parte, se un utente va a
> cambiare il nome di una highway o di un singolo nodo addr:street, se c'è
> un'errore questo comparirà su OSMInspector.
>
> Voglio portarti un esempio concreto di quanto ho appena affermato. Guarda
> la provincia di Ferrara [1]. Qualche mese fa mi sono occupato di sistemare
> i nomi su tutta la provincia, un lavoro enorme, non ti dico quanto tempo ho
> speso. Su OSMi i puntini rossi li contavi su una mano. Adesso invece puoi
> notare che è tornato ad essere un campo da guerra. Qualche utente si è dato
> un gran da fare per abbreviare nuovamente i nomi. Dico io, esiste il tag
> short_name: se ti sta sulle balle il nome completo abbi la decenza di
> aggiungere quel tag! Ora, mi conforta il fatto che questi utenti abbiano
> solo cambiato il nome di un highway e non di tutti i civici. Evidentemente
> questi utenti non sono consci delle implicazioni di tali modifiche, per
> fortuna (altrimenti chi li trova più gli errori)  Se il fatto fosse
> accaduto sulle relazioni, ti sfido a trovare questi problemi!
>

Se fosse accaduto sulle relazioni invece di dover correggere un milione di
punti, ne avresti dovuto correggere solo uno.

Se OSMInspector non considera le relazioni questa non è una ragione
generale per non usarle.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Simone Saviolo]

Il giorno 14 dicembre 2017 16:03, Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> 2017-12-14 14:59 GMT+01:00 Simone Saviolo :
>
>> Qualitativamente, no. È vero, le relazioni comportano un *piccolo*
>> overhead: da una parte aggiungo un tag a un nodo/way, dall'altro aggiungo
>> il nodo/way alla relazione *e* ho una relazione. Ma bada, la relazione con
>> mille membri è sempre UNA relazione con mille membri, invece di essere
>> mille tag. Non mi sembra che sia un impatto rilevante - ma per scoprirlo
>> dovremmo avere numeri, e non li abbiamo.
>>
>
> i numeri ci sono, non le ho io, ma ho ascoltato chi le aveva. Il "dogma"
> "relations are not categories" viene proprio da questo lato. Altrimenti
> potresti anche dire: perché scrivere amenity=school mille volte, se posso
> avere una relazione "scuole di Roma" dove aggiungo tutte le scuole. Per
> esempio.
>

Infatti sono contrario anch'io alle categorie. Ma questa non è una
categoria: è una relazione del tipo "fa parte di", "è associato a".

Quanto alle scuole di Roma, non c'entra. amenity=school è un tag fisso; qui
stiamo parlando di name=* che è un tag freeform. È sbagliato che un campo
freeform venga usato come chiave per una relazione.

Inoltre, fare una categoria "scuole di Roma" è sbagliato: se vuoi tutte le
scuole di Roma, fai una query. Creare una categoria (con una relazione o in
qualsiasi altro modo) sarebbe una sorta di cache dei risultati della query,
e sarebbe invalidata tre secondi dopo che l'hai fatta.

Ciao,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Simone Saviolo]

Il giorno 14 dicembre 2017 16:09, Davide Sandona' 
ha scritto:

> Ora, mi conforta il fatto che questi utenti abbiano solo cambiato il nome
> di un highway e non di tutti i civici. Evidentemente questi utenti non sono
> consci delle implicazioni di tali modifiche, per fortuna (altrimenti chi li
> trova più gli errori)  Se il fatto fosse accaduto sulle relazioni, ti
> sfido a trovare questi problemi!
>

Capisco, davvero. Ma spero che tu ti renda conto che è un bug che copre un
altro bug.

Ciao,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Davide Sandona']

Capisco le problematiche esistenti su entrambi gli approcci. Tuttavia, le
persone che si occupano della numerazione civica sono assai poche. Le
persone che si impegnano dopo un import a correggere i nomi delle vie con i
nomi degli nodi-indirizzi sono praticamente inesistenti. Ancor più rare
sono le persone che monitorano costantemente tutti gli edit di una
determinata area per controllare che non vengano inseriti errori.

Da un punto di vista di database, avrebbe assolutamente senso utilizzare le
relazioni. Però su OSM operano un sacco di persone che di database e
relazioni non sanno assolutamente nulla; cosa significa questo? Qualora una
di queste persone vada ad inserire un errore su un nome di una relazione
(per ignoranza oppure per sabotaggio) è assai probabile che questo errore
sfugga ai controlli. Con le relazioni street, un errore sul nome ricadrebbe
su tutti gli oggetti di quella relazione. D'altra parte, se un utente va a
cambiare il nome di una highway o di un singolo nodo addr:street, se c'è
un'errore questo comparirà su OSMInspector.

Voglio portarti un esempio concreto di quanto ho appena affermato. Guarda
la provincia di Ferrara [1]. Qualche mese fa mi sono occupato di sistemare
i nomi su tutta la provincia, un lavoro enorme, non ti dico quanto tempo ho
speso. Su OSMi i puntini rossi li contavi su una mano. Adesso invece puoi
notare che è tornato ad essere un campo da guerra. Qualche utente si è dato
un gran da fare per abbreviare nuovamente i nomi. Dico io, esiste il tag
short_name: se ti sta sulle balle il nome completo abbi la decenza di
aggiungere quel tag! Ora, mi conforta il fatto che questi utenti abbiano
solo cambiato il nome di un highway e non di tutti i civici. Evidentemente
questi utenti non sono consci delle implicazioni di tali modifiche, per
fortuna (altrimenti chi li trova più gli errori)  Se il fatto fosse
accaduto sulle relazioni, ti sfido a trovare questi problemi!

[1]
http://tools.geofabrik.de/osmi/?view=addresses=11.67004=44.80572=11=buildings,buildings_with_addresses,postal_code,entrances_deprecated,entrances,street_not_found,place_not_found,nodes_with_addresses_defined,nodes_with_addresses_interpolated,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads,nearest_areas,addrx_on_nonclosed_way

Davide.

Il giorno 14 dicembre 2017 15:26, Catonano  ha scritto:

>
>
> Il giorno 14 dicembre 2017 14:53, Martin Koppenhoefer <
> dieterdre...@gmail.com> ha scritto:
>
>> 2017-12-14 12:59 GMT+01:00 Catonano :
>>
>>>
>>> Eventuali software che avessero problemi nel parsing potrebbero estrarre
>>> i dati e metterli in un formato più adatto al loro progetto
>>>
>>
>>
>> appunto, è proprio questo il problema. Più relazioni hai, più dura questo
>> processo (perché gli unici ad avere posizioni sono nodi, i way contengono
>> solo numeri dei nodi, e relazioni contengono solo numeri di altre
>> relazioni, way e nodi).
>>
>
> ho capito. Ma ripeto: se ci si pone di questi problemi allora cambiano i
> termini del confronto con soluzioni commerciali
>
>
>
>>
>>> Del resto la relazione street esiste per un motivo
>>>
>>
>>
>> si, perché nessuno ha ancora avuto il corraggio o il tempo di sostituirle
>> con il sistema "vincente" ;-)
>> Intanto si tratta di una cosa opzionale e _in più_
>> "Note that this relation is *not established* and *unsupported* by some
>> applications. It has also not been approved by vote. You can still use it,
>> but you should not delete existing tagging in its favour."
>>
>
> associatedStreet tratta i numeri civici nello stesso modo ed è approvata
>
>
>
>>
>>
>>
>>>
>>> Il motivo è esattamente quello che replicare lo stesso dato su motli
>>> punti è una bad practice nelle basi dati dagli anni 60 almeno
>>>
>>
>>
>> è una bad practice se tu sei l'unico a gestire quel db, non se ci sono
>> millioni di amatori, raramente anche malintenzionate spesso però poco
>> pratici.
>>
>
> milioni di amatori non garantiscono che la correttezza dei dati possa
> essere assicurata con UN SOLO edit di uno che sa usare le relazioni
>
>
>
>
>
>>
>>
>>
>>
>>>
>>>
>>> Le relazioni incomplete si possono completare e quelle rotte si possono
>>> riparare
>>>
>>>
>>
>> certo, solo che non è divertente. Chi le ha preferite spesso ha smesso di
>> utilizzarle perché si è stancato delle continuate riparazioni...
>>
>
> quindi si moltiplicano i nodi potenzialmente bisognosi di riparazioni di
> diversi ordini di grandezza ?
>
>
>
>
>>
>>
 adesso, se ti sbagli con un civico e scrivi il nome sbagliato della
 strada, salta all'occhio, se invece sbagli il nome della relazione
 otteniamo un dato falso e non ci sono indicazioni, l'errore può dormire più
 tranquillo

>>>
>>> e perché ? Una relazione non è ispezionabile, a mano o da parte di un
>>> software ?
>>>
>>
>>
>> si, ma con cosa la vuoi confrontare, se il nome c'è solo scritto lì,
>> invece di avere 200 copie.
>>
>
> Uno che conosce il nome della strada guarda 

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

[Catonano]

Il giorno 14 dicembre 2017 16:03, Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> 2017-12-14 14:59 GMT+01:00 Simone Saviolo :
>
>> Qualitativamente, no. È vero, le relazioni comportano un *piccolo*
>> overhead: da una parte aggiungo un tag a un nodo/way, dall'altro aggiungo
>> il nodo/way alla relazione *e* ho una relazione. Ma bada, la relazione con
>> mille membri è sempre UNA relazione con mille membri, invece di essere
>> mille tag. Non mi sembra che sia un impatto rilevante - ma per scoprirlo
>> dovremmo avere numeri, e non li abbiamo.
>>
>
>
> i numeri ci sono, non le ho io, ma ho ascoltato chi le aveva. Il "dogma"
> "relations are not categories" viene proprio da questo lato. Altrimenti
> potresti anche dire: perché scrivere amenity=school mille volte, se posso
> avere una relazione "scuole di Roma" dove aggiungo tutte le scuole. Per
> esempio.
>

certo, lo potresti dire. Semplicemente non saresti obbligato a usare una
relazzione in _ogni_ caso in cui sarebbe possibile

In alcuni casi scegli di sare una relazione
In altri no

I civici per una strada possono essere migliaia. Le scuole no



>
> Ciao,
> Martin
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Martin Koppenhoefer]

2017-12-14 14:59 GMT+01:00 Simone Saviolo :

> Qualitativamente, no. È vero, le relazioni comportano un *piccolo*
> overhead: da una parte aggiungo un tag a un nodo/way, dall'altro aggiungo
> il nodo/way alla relazione *e* ho una relazione. Ma bada, la relazione con
> mille membri è sempre UNA relazione con mille membri, invece di essere
> mille tag. Non mi sembra che sia un impatto rilevante - ma per scoprirlo
> dovremmo avere numeri, e non li abbiamo.
>


i numeri ci sono, non le ho io, ma ho ascoltato chi le aveva. Il "dogma"
"relations are not categories" viene proprio da questo lato. Altrimenti
potresti anche dire: perché scrivere amenity=school mille volte, se posso
avere una relazione "scuole di Roma" dove aggiungo tutte le scuole. Per
esempio.

Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Catonano]

Il giorno 14 dicembre 2017 14:53, Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> 2017-12-14 12:59 GMT+01:00 Catonano :
>
>>
>> Eventuali software che avessero problemi nel parsing potrebbero estrarre
>> i dati e metterli in un formato più adatto al loro progetto
>>
>
>
> appunto, è proprio questo il problema. Più relazioni hai, più dura questo
> processo (perché gli unici ad avere posizioni sono nodi, i way contengono
> solo numeri dei nodi, e relazioni contengono solo numeri di altre
> relazioni, way e nodi).
>

ho capito. Ma ripeto: se ci si pone di questi problemi allora cambiano i
termini del confronto con soluzioni commerciali



>
>> Del resto la relazione street esiste per un motivo
>>
>
>
> si, perché nessuno ha ancora avuto il corraggio o il tempo di sostituirle
> con il sistema "vincente" ;-)
> Intanto si tratta di una cosa opzionale e _in più_
> "Note that this relation is *not established* and *unsupported* by some
> applications. It has also not been approved by vote. You can still use it,
> but you should not delete existing tagging in its favour."
>

associatedStreet tratta i numeri civici nello stesso modo ed è approvata



>
>
>
>>
>> Il motivo è esattamente quello che replicare lo stesso dato su motli
>> punti è una bad practice nelle basi dati dagli anni 60 almeno
>>
>
>
> è una bad practice se tu sei l'unico a gestire quel db, non se ci sono
> millioni di amatori, raramente anche malintenzionate spesso però poco
> pratici.
>

milioni di amatori non garantiscono che la correttezza dei dati possa
essere assicurata con UN SOLO edit di uno che sa usare le relazioni





>
>
>
>
>>
>>
>> Le relazioni incomplete si possono completare e quelle rotte si possono
>> riparare
>>
>>
>
> certo, solo che non è divertente. Chi le ha preferite spesso ha smesso di
> utilizzarle perché si è stancato delle continuate riparazioni...
>

quindi si moltiplicano i nodi potenzialmente bisognosi di riparazioni di
diversi ordini di grandezza ?




>
>
>>> adesso, se ti sbagli con un civico e scrivi il nome sbagliato della
>>> strada, salta all'occhio, se invece sbagli il nome della relazione
>>> otteniamo un dato falso e non ci sono indicazioni, l'errore può dormire più
>>> tranquillo
>>>
>>
>> e perché ? Una relazione non è ispezionabile, a mano o da parte di un
>> software ?
>>
>
>
> si, ma con cosa la vuoi confrontare, se il nome c'è solo scritto lì,
> invece di avere 200 copie.
>

Uno che conosce il nome della strada guarda la relazione e decide se il
nome inserito nella relazione sia corretto oppure no



>
>
>
> va discusso con gli abitanti della strada.
>
>>
>> eh ?
>>
>
>
> secondome, cambiare un typo nel nome di una strada in tanti indirizzi di
> quella strada, spazialmente limitato su quella strada, non è un automated
> edit secondo lo spirito della guideline. Stai guardando il singolo oggetto.
>

sono daccordo. Rimane il fatto che una relazzione richiederebbe UN SOLO
edit e quindi questa distinione non sarebbe necessaria



>
> Ciao,
> Martin
>

Ciao
Adriano
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Simone Saviolo]

Il giorno 14 dicembre 2017 14:41, Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> "parsing del diff" intendo aggiornare un estratto oppure tutto in un
> database relazionale, per esempio con osm2pgsql o imposm. Se tutto quello
> che è ridondante lo facciamo con le relazioni, vedrai che diventa sempre
> più lento importare e usare i dati OSM, e lo potranno fare solo le persone
> con le macchine potenti (già adesso avere 64GB o 128GB di RAM facilita
> molto l'importazione, ma lo ha solo chi usa in maniera professionale i
> dati).
>

Qualitativamente, no. È vero, le relazioni comportano un *piccolo*
overhead: da una parte aggiungo un tag a un nodo/way, dall'altro aggiungo
il nodo/way alla relazione *e* ho una relazione. Ma bada, la relazione con
mille membri è sempre UNA relazione con mille membri, invece di essere
mille tag. Non mi sembra che sia un impatto rilevante - ma per scoprirlo
dovremmo avere numeri, e non li abbiamo.

D'altro canto, non pensi che il motivo per cui adesso per lavorare su un
estratto di area vasta (una regione? uno stato? un continente?) ci vuole
molta RAM sta nel fatto che ci sono molti dati?


> Per prima cosa, è un problema del software di editing. Tu stai spostando
>> il problema sul mappatore, cioè sull'utente di quel software.
>>
>
> è un fatto che i software diffusi per smartphone non gesticono questo tipo
> di relazione e in generale pochi relazioni. Potrebbe essere diverso, forse,
> ma non lo è. Un nodo lo puoi inserire con un qualsiasi poi-editor.
>

Concordo sulla situazione di fatto. Ma contesto fortemente lo spirito.
Perché qualsiasi POI editor ti permette di aggiungere un nodo e non di
strutturare le sue informazioni? Te lo dico io perché, perché abbiamo mille
progettini di POI editor ognuno lasciato a metà. Sarebbe come se io facessi
un client di posta elettronica nel quale non gestisco né gli allegati né il
testo HTML: quello *non è* un editor di posta, è un abbozzo incompiuto.


> Attualmente, con Keypad Mapper, mi viene suggerito il nome della strada,
>> io a mano vado a metterlo nella schermata di dettagli (e potrei scriverlo
>> sbagliato già lì), e questo viene aggiunto ai nodi creati. Peccato che, se
>> giro l'angolo *e mi dimentico di cambiare il nome della strada*, continuo
>> ad inserire i civici di via Cavour come se fossero su corso Garibaldi...
>>
>
> qualcuno lo correggerà. Non vedo perché le relazioni dovrebbe farti fare
> meno errori e meno gravi rispetto agli indirizzi singoli, al massimo
> saranno errori diversi, ma tipicamente l'impatto di un errore in una
> relazione è più grande.
>

Ci sono categorie di errori che potremmo fare tanto con le relazioni quanto
con il tag. Ad esempio assegnare il civico alla strada sbagliata. Ma ci
sono altri errori che potremmo fare involontariamente con il tag *che
sarebbero impossibili da fare involontariamente con la relazione*.

Se io dico che il civico X fa parte della relazione "via Cavour", e fra due
anni via Cavour diventa "via della pace", modifico la relazione ed è tutto
a posto.

Se io dico che il civico X ha come "strada dell'indirizzo" "via Cavour",
quando fra due anni si cambierà il nome della way *nessuno* mi farà
cambiare il tag dei civici.

Se io dico che il civico X ha come "strada dell'indirizzo" "Via Camillo
Cavour", quel civico non c'entrerà mai niente con la strada.

Se io dico che il civico X ha come "strada dell'indirizzo" "via Cavuor",
quel civico non c'entrerà mai niente con la strada.


> In generale, le relazioni di questo tipo sono ignorabili al livello
> globale:
>
>
> [image: Inline-Bild 1]
>

Non sequitur. Per anni si è fatta guerra alle relazioni, è ovvio che sono
poco usate.

Qui il discorso è molto semplice: stiamo usando una sola cosa (il tag name
della highway) per indicare due cose: 1) il nome della strada, 2) quali
oggetti sono legati a quella strada. Questo è sbagliato. Punto, fine, stop.
Trovatemi una sola persona che possa dire che questo è il modo migliore di
risolvere il problema. Continuare a difendere l'uso del tag e osteggiare
quello della relazione significa negare l'esistenza del problema, ed è una
decisione politica sulla quale possiamo discutere. Ma dal punto di vista
tecnico non c'è opinione che tenga.

Ciao,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Catonano]

Il giorno 14 dicembre 2017 14:41, Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> 2017-12-14 12:33 GMT+01:00 Simone Saviolo :
>
>> Il giorno 14 dicembre 2017 11:24, Martin Koppenhoefer <
>> dieterdre...@gmail.com> ha scritto:
>>
>>> 2017-12-14 9:27 GMT+01:00 Simone Saviolo :
>>> le relazioni sono comunque onerose nel parsing e per ogni modifica
>>> (parsing del diff).
>>>
>>
>> Ma non lo sono nell'estrazione dati, che è l'operazione che viene svolta
>> la maggior parte del tempo, a differenza della modifica che è
>> essenzialmente un'operazione offline (nel senso che avviene
>> sporadicamente). Il parsing del diff lo fa una macchina, che lo fa
>> correttamente, ed è molto meno frequente di una qualsiasi lettura.
>>
>
>
> "parsing del diff" intendo aggiornare un estratto oppure tutto in un
> database relazionale, per esempio con osm2pgsql o imposm. Se tutto quello
> che è ridondante lo facciamo con le relazioni, vedrai che diventa sempre
> più lento importare e usare i dati OSM, e lo potranno fare solo le persone
> con le macchine potenti (già adesso avere 64GB o 128GB di RAM facilita
> molto l'importazione, ma lo ha solo chi usa in maniera professionale i
> dati).
>

Se Openstreetmap ha il vincolo di poter essere trattabile con mezzi
limitati, allora non vedo il confronto con soluzioni commerciali si pone in
termini diversi

Se poi chi tratta i dati in modo "professionale" non si preoccupa di dati
replicati e sbagliati, anche questo è un elemento che definisci i termini
del confronto con soluzioni commerciali


>
>
> E così, invece di avere una query semplice e sensata (cerca relazioni
 street con quel nome, estrai tutti i membri della relazione), ora facciamo
 una query assurda (tutti gli oggetti con highway=* e name=pippo, oppure con
 addr:street=pippo) che non ci dà i risultati giusti *perché è facilissimo
 disallineare i dati*. Magari qualcuno li migliora da una parte (come in
 questo caso, con un nome più corretto per la strada) ma *non può sapere (a
 meno di non sapere esattamente cosa cercare)* cos'altro deve modificare.

>>>
>>> Quando qualcuno usava le relazioni per gruppare elementi di una strada,
>>> il mappatore doveva sapere che esistesse una relazione e doveva cercarla e
>>> avere un programma di editing che supportava modificare relazioni di questo
>>> tipo (sopratutto per i civici è comodo poterli inserire con un smartphone),
>>> tutto non scontato, perciò si sono spesso rotte o erano incomplete.
>>>
>>
>> Per prima cosa, è un problema del software di editing. Tu stai spostando
>> il problema sul mappatore, cioè sull'utente di quel software.
>>
>
>
> è un fatto che i software diffusi per smartphone non gesticono questo tipo
> di relazione e in generale pochi relazioni. Potrebbe essere diverso, forse,
> ma non lo è.
>

Certo che se eliminiamo le relazioni su tutto, l' incentivo per i software
a tratatre le relazioni sarà diminuito. Una profezia che si autoavvera.


>
>
>>
>>
>> Attualmente, con Keypad Mapper, mi viene suggerito il nome della strada,
>> io a mano vado a metterlo nella schermata di dettagli (e potrei scriverlo
>> sbagliato già lì), e questo viene aggiunto ai nodi creati. Peccato che, se
>> giro l'angolo *e mi dimentico di cambiare il nome della strada*, continuo
>> ad inserire i civici di via Cavour come se fossero su corso Garibaldi...
>>
>
>
>
> qualcuno lo correggerà. Non vedo perché le relazioni dovrebbe farti fare
> meno errori e meno gravi rispetto agli indirizzi singoli,
>

perché un errore su una relazione si corregge con un solo edit


> al massimo saranno errori diversi, ma tipicamente l'impatto di un errore
> in una relazione è più grande.
>

come sopra: un errore su una relazione si corregge con un solo edit


>
> In generale, le relazioni di questo tipo sono ignorabili al livello
> globale:
>

il che vuol dire che mantenere quei dati è più difficile e dispendioso del
dovuto

E' un argomento per usarle di più, non di meno


>
> [image: Inline-Bild 1]
>
> Ciao,
> Martin
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Martin Koppenhoefer]

2017-12-14 12:59 GMT+01:00 Catonano :

>
> Eventuali software che avessero problemi nel parsing potrebbero estrarre i
> dati e metterli in un formato più adatto al loro progetto
>


appunto, è proprio questo il problema. Più relazioni hai, più dura questo
processo (perché gli unici ad avere posizioni sono nodi, i way contengono
solo numeri dei nodi, e relazioni contengono solo numeri di altre
relazioni, way e nodi).



> Del resto la relazione street esiste per un motivo
>


si, perché nessuno ha ancora avuto il corraggio o il tempo di sostituirle
con il sistema "vincente" ;-)
Intanto si tratta di una cosa opzionale e _in più_
"Note that this relation is *not established* and *unsupported* by some
applications. It has also not been approved by vote. You can still use it,
but you should not delete existing tagging in its favour."



>
> Il motivo è esattamente quello che replicare lo stesso dato su motli punti
> è una bad practice nelle basi dati dagli anni 60 almeno
>


è una bad practice se tu sei l'unico a gestire quel db, non se ci sono
millioni di amatori, raramente anche malintenzionate spesso però poco
pratici.




>
>
> Le relazioni incomplete si possono completare e quelle rotte si possono
> riparare
>
>

certo, solo che non è divertente. Chi le ha preferite spesso ha smesso di
utilizzarle perché si è stancato delle continuate riparazioni...


>> adesso, se ti sbagli con un civico e scrivi il nome sbagliato della
>> strada, salta all'occhio, se invece sbagli il nome della relazione
>> otteniamo un dato falso e non ci sono indicazioni, l'errore può dormire più
>> tranquillo
>>
>
> e perché ? Una relazione non è ispezionabile, a mano o da parte di un
> software ?
>


si, ma con cosa la vuoi confrontare, se il nome c'è solo scritto lì, invece
di avere 200 copie.


va discusso con gli abitanti della strada.

>
> eh ?
>


secondome, cambiare un typo nel nome di una strada in tanti indirizzi di
quella strada, spazialmente limitato su quella strada, non è un automated
edit secondo lo spirito della guideline. Stai guardando il singolo oggetto.

Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Alessandro]

  
  
Il 14/12/2017 14:38, Simone Saviolo ha
  scritto:


  

  ...


Anzi, guarda: facciamoci due risate :D https://imgflip.com/i/212bfx


  

  

Ahiahiahi addr:street va scritto in minuscolo :-)
  


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Catonano]

Il giorno 14 dicembre 2017 14:30, Simone Saviolo 
ha scritto:

> Il giorno 14 dicembre 2017 14:21, Catonano  ha
> scritto:
>>
>> credo ci sia un equivoco
>>
>> Io stavo sostenenedo e caldeggiando l' uso delle relazioni !!
>>
>
> Sì sì, l'avevo capito, ma non è una guerra personale :D ho appena finito
> di dire che io stesso l'ho fatto (di non usare le relazioni), e dopo due
> giorni che lo facevo mi sono scontrato con tutti i limiti di questo
> approccio.
>

Io non mi sono scontrato con nulla perche finche non ho capito non ho
toccato dati di cui mi sarei potuto pentire
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Martin Koppenhoefer]

2017-12-14 12:33 GMT+01:00 Simone Saviolo :

> Il giorno 14 dicembre 2017 11:24, Martin Koppenhoefer <
> dieterdre...@gmail.com> ha scritto:
>
>> 2017-12-14 9:27 GMT+01:00 Simone Saviolo :
>> le relazioni sono comunque onerose nel parsing e per ogni modifica
>> (parsing del diff).
>>
>
> Ma non lo sono nell'estrazione dati, che è l'operazione che viene svolta
> la maggior parte del tempo, a differenza della modifica che è
> essenzialmente un'operazione offline (nel senso che avviene
> sporadicamente). Il parsing del diff lo fa una macchina, che lo fa
> correttamente, ed è molto meno frequente di una qualsiasi lettura.
>


"parsing del diff" intendo aggiornare un estratto oppure tutto in un
database relazionale, per esempio con osm2pgsql o imposm. Se tutto quello
che è ridondante lo facciamo con le relazioni, vedrai che diventa sempre
più lento importare e usare i dati OSM, e lo potranno fare solo le persone
con le macchine potenti (già adesso avere 64GB o 128GB di RAM facilita
molto l'importazione, ma lo ha solo chi usa in maniera professionale i
dati).


E così, invece di avere una query semplice e sensata (cerca relazioni
>>> street con quel nome, estrai tutti i membri della relazione), ora facciamo
>>> una query assurda (tutti gli oggetti con highway=* e name=pippo, oppure con
>>> addr:street=pippo) che non ci dà i risultati giusti *perché è facilissimo
>>> disallineare i dati*. Magari qualcuno li migliora da una parte (come in
>>> questo caso, con un nome più corretto per la strada) ma *non può sapere (a
>>> meno di non sapere esattamente cosa cercare)* cos'altro deve modificare.
>>>
>>
>> Quando qualcuno usava le relazioni per gruppare elementi di una strada,
>> il mappatore doveva sapere che esistesse una relazione e doveva cercarla e
>> avere un programma di editing che supportava modificare relazioni di questo
>> tipo (sopratutto per i civici è comodo poterli inserire con un smartphone),
>> tutto non scontato, perciò si sono spesso rotte o erano incomplete.
>>
>
> Per prima cosa, è un problema del software di editing. Tu stai spostando
> il problema sul mappatore, cioè sull'utente di quel software.
>


è un fatto che i software diffusi per smartphone non gesticono questo tipo
di relazione e in generale pochi relazioni. Potrebbe essere diverso, forse,
ma non lo è. Un nodo lo puoi inserire con un qualsiasi poi-editor.



>
>
> Attualmente, con Keypad Mapper, mi viene suggerito il nome della strada,
> io a mano vado a metterlo nella schermata di dettagli (e potrei scriverlo
> sbagliato già lì), e questo viene aggiunto ai nodi creati. Peccato che, se
> giro l'angolo *e mi dimentico di cambiare il nome della strada*, continuo
> ad inserire i civici di via Cavour come se fossero su corso Garibaldi...
>



qualcuno lo correggerà. Non vedo perché le relazioni dovrebbe farti fare
meno errori e meno gravi rispetto agli indirizzi singoli, al massimo
saranno errori diversi, ma tipicamente l'impatto di un errore in una
relazione è più grande.

In generale, le relazioni di questo tipo sono ignorabili al livello globale:


[image: Inline-Bild 1]

Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Simone Saviolo]

Il giorno 14 dicembre 2017 14:30, Simone Saviolo 
ha scritto:

> Non è uno scontro tra "buoni" che usano le relazioni e "cattivi" che non
> le usano :D Martin non è un cattivo, anzi, avercene di Martin! Solo che a
> volte dice che se una cosa è difficile non bisogna farla... e su questo,
> sempre in amicizia, non sono d'accordo.
>

Anzi, guarda: facciamoci due risate :D https://imgflip.com/i/212bfx

Ciao,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Simone Saviolo]

Il giorno 14 dicembre 2017 14:21, Catonano  ha scritto:
>
> credo ci sia un equivoco
>
> Io stavo sostenenedo e caldeggiando l' uso delle relazioni !!
>

Sì sì, l'avevo capito, ma non è una guerra personale :D ho appena finito di
dire che io stesso l'ho fatto (di non usare le relazioni), e dopo due
giorni che lo facevo mi sono scontrato con tutti i limiti di questo
approccio.

Non è uno scontro tra "buoni" che usano le relazioni e "cattivi" che non le
usano :D Martin non è un cattivo, anzi, avercene di Martin! Solo che a
volte dice che se una cosa è difficile non bisogna farla... e su questo,
sempre in amicizia, non sono d'accordo.

Ciao,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Catonano]

Il giorno 14 dicembre 2017 13:18, Simone Saviolo 
ha scritto:

> Il giorno 14 dicembre 2017 13:05, Catonano  ha
> scritto:
>
>> e come uno
>>>
>> inesperto non può sapere che o come deve cercare gli addr:street può
>>> benissimo non sapere nulla delle relazioni;
>>
>>
>> lo può sempre imparare
>>
>> Pure io ho avuto anni di perplessità su come si usassero le relazioni
>>
>> Semplicemente finche sono stato perplesso non le ho usate
>>
>> Non è caduto il mondo
>>
>
> Non cade il mondo, ma ora tu, io o qualcun altro dovrà correre dietro ai
> possibili problemi che creano o creeranno i tuoi dati.
>
> Riprendo l'esempio che ho fatto prima. Da un po' di tempo mappo civici a
> Trino, qualche volta, durante la pausa pranzo, con Keypad Mapper. Vista la
> diatriba che c'era stata *e visto che Keypad Mapper me lo fa già trovare
> pronto* (pigro io!), li sto mappando inserendo addr:street (facendolo
> inserire da KM). L'altro giorno ero sui civici di corso Cavour. Apriti
> cielo! Sulla strada c'è una targa "corso Cavour". So già che prima o poi
> qualcuno passerà e dirà "orrore! una via con un nome proprio di persona
> incompleto!" (e se fosse intitolato al paese in provincia di Torino, BTW?
> Vedasi corso Palestro a Vercelli, dedicato alla battaglia e non al paese),
> e cambierà la strada in name=Corso Camillo Benso Conte di Cavour (e perché
> non "Camillo Paolo Filippo Giulio Benso, conte di Cavour, di Cellarengo e
> di Isolabella"?). Che ne sarà dei civici?
>
> Non cade il mondo, per carità. Non cade il mondo neanche se riprendiamo a
> misurare le case con i tratti di corda invece che col telemetro laser.
>
> Ciao,
>

credo ci sia un equivoco

Io stavo sostenenedo e caldeggiando l' uso delle relazioni !!
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Simone Saviolo]

Il giorno 14 dicembre 2017 13:05, Catonano  ha scritto:

> e come uno
>>
> inesperto non può sapere che o come deve cercare gli addr:street può
>> benissimo non sapere nulla delle relazioni;
>
>
> lo può sempre imparare
>
> Pure io ho avuto anni di perplessità su come si usassero le relazioni
>
> Semplicemente finche sono stato perplesso non le ho usate
>
> Non è caduto il mondo
>

Non cade il mondo, ma ora tu, io o qualcun altro dovrà correre dietro ai
possibili problemi che creano o creeranno i tuoi dati.

Riprendo l'esempio che ho fatto prima. Da un po' di tempo mappo civici a
Trino, qualche volta, durante la pausa pranzo, con Keypad Mapper. Vista la
diatriba che c'era stata *e visto che Keypad Mapper me lo fa già trovare
pronto* (pigro io!), li sto mappando inserendo addr:street (facendolo
inserire da KM). L'altro giorno ero sui civici di corso Cavour. Apriti
cielo! Sulla strada c'è una targa "corso Cavour". So già che prima o poi
qualcuno passerà e dirà "orrore! una via con un nome proprio di persona
incompleto!" (e se fosse intitolato al paese in provincia di Torino, BTW?
Vedasi corso Palestro a Vercelli, dedicato alla battaglia e non al paese),
e cambierà la strada in name=Corso Camillo Benso Conte di Cavour (e perché
non "Camillo Paolo Filippo Giulio Benso, conte di Cavour, di Cellarengo e
di Isolabella"?). Che ne sarà dei civici?

Non cade il mondo, per carità. Non cade il mondo neanche se riprendiamo a
misurare le case con i tratti di corda invece che col telemetro laser.

Ciao,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Catonano]

Il giorno 14 dicembre 2017 12:24, Aury88  ha
scritto:

> dieterdreist wrote
> > 2017-12-14 9:27 GMT+01:00 Simone Saviolo 
>
> > simone.saviolo@
>
> > :
> >
> >> Invece noi su OSM dobbiamo abbattere le barriere all'ingresso perché i
> >> mappatori abbiano vita facile, dobbiamo abbattere le barriere in uscita
> >> perché i consumatori abbiano vita facile, e poi siamo un progetto open,
> >> mica dobbiamo cristallizzarci, no? Se la community dice che le relazioni
> >> sono scomode da usare, non le si usano. È meglio ripetere i dati
> >> cinquanta
> >> volte in cinquanta posti diversi, perché puoi farlo con cinquanta soli
> >> clic, invece di usarne cinquantacinque per fare una relazione e
> >> aggiungerci
> >> i numeri civici. (Sarcasmo, se non fosse chiaro).
> >>
> >
> >
> > le relazioni sono comunque onerose nel parsing e per ogni modifica
> > (parsing
> > del diff).
> >
> >
> >
> >>
> >> E così, invece di avere una query semplice e sensata (cerca relazioni
> >> street con quel nome, estrai tutti i membri della relazione), ora
> >> facciamo
> >> una query assurda (tutti gli oggetti con highway=* e name=pippo, oppure
> >> con
> >> addr:street=pippo) che non ci dà i risultati giusti *perché è
> facilissimo
> >> disallineare i dati*. Magari qualcuno li migliora da una parte (come in
> >> questo caso, con un nome più corretto per la strada) ma *non può sapere
> >> (a
> >> meno di non sapere esattamente cosa cercare)* cos'altro deve modificare.
> >>
> >
> >
> > Quando qualcuno usava le relazioni per gruppare elementi di una strada,
> il
> > mappatore doveva sapere che esistesse una relazione e doveva cercarla e
> > avere un programma di editing che supportava modificare relazioni di
> > questo
> > tipo (sopratutto per i civici è comodo poterli inserire con un
> > smartphone),
> > tutto non scontato, perciò si sono spesso rotte o erano incomplete.
> >
> >
> >
> >>
> >> Mi spiego meglio: oggi stiamo parlando dei numeri civici. Se modifico il
> >> nome di una strada, devo sapere che devo cercare anche tutti gli
> elementi
> >> con addr:street=
> > 
> > . E io lo so perché mappo da 8 anni, ma un altro (un
> >> principiante, magari) non lo sa,
> >>
> >
> >
> > proprio per questo c'è OSM inspector ;-)
> >
> >
> >
> >
> >> oppure io stesso quel giorno lì sto facendo una modifica al volo, oppure
> >> mi sono distratto e mi sono dimenticato di farlo - e già così ho
> rovinato
> >> i
> >> dati.
> >>
> >
> >
> > adesso, se ti sbagli con un civico e scrivi il nome sbagliato della
> > strada,
> > salta all'occhio, se invece sbagli il nome della relazione otteniamo un
> > dato falso e non ci sono indicazioni, l'errore può dormire più tranquillo
> >
> >
> >
> >>
> >> Scusate il lungo sfogo, ma è frustrante dire "facciamo un minimo sforzo
> >> in
> >> più perché non succeda *questo problema* nel futuro", sentirsi
> rispondere
> >> "non è un minimo sforzo, è una complicazione inutile che aggiunge solo
> >> difficoltà per i mappatori, non lo facciamo", e poi trovarsi di fronte
> *a
> >> quell'esatto problema*... e chiedersi come diamine potremmo fare a
> >> risolverlo.
> >>
> >
> >
> > CTRL+F
> > ;-)
> >
> >
> >
> >>
> >> Oltretutto, nel caso specifico, prima diciamo no ad usare le relazioni
> (e
> >> allora perché non facciamo che eliminarle?!), perché "nel caso basterà
> >> fare
> >> un cerca e sostituisci", poi però, quando succede, viene fuori che un
> >> cerca
> >> e sostituisci (sempre che ci ricordiamo di farlo) in realtà è un
> >> mechanical
> >> edit e va analizzato e discusso e presentato alla community e
> documentato
> >> e
> >> votato.
> >>
> >
> >
> > va discusso con gli abitanti della strada.
> >
> >
> > Ciao,
> > Martin ;-)
> >
> > ___
> > Talk-it mailing list
>
> > Talk-it@
>
> > https://lists.openstreetmap.org/listinfo/talk-it
>
> quoto tutto e aggiungo il mio dubbio: dove ci potrebbe portare decidere di
> mappare con una relazione per paura dei disallineamenti?


A lavorare meno e meglio ?

sono decine i casi
> in cui si potrebbero verificare disallineamenti...che dire di tutti quegli
> elementi gestiti dallo stesso operator, o che commerciano lo stesso brand o
> che appartengono alla stessa catenatutti casi in cui tra l'altro, vista
> la maggior distribuzione spaziale, è molto più facile che i singoli
> elementi
> vengano mappati da mappatori differenti con value, che dovrebbero essere
> comuni, più o meno diversi tra loro...
>

sono tutti casi che si prestano a essere tratatti con relazioni
Come ci si regola ?

Si propone una relazione e  la si vota

E comuqnue chi vorrà mapperà come vuole

Esattamente come con le altre feature


>
> qui non stiamo parlando di qualche elemento più o meno esotico e raro che
> quindi può essere gestito  mappato unicamente da un elite di mappatori
> esperti, ma di un dato maledettamente comune e che deve essere
> necessariamente frutto anche del contributo dei meno esperti... il
> trascurare questo aspetto 

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

[Simone Saviolo]

Il giorno 14 dicembre 2017 12:24, Aury88  ha
scritto:

> quoto tutto e aggiungo il mio dubbio: dove ci potrebbe portare decidere di
> mappare con una relazione per paura dei disallineamenti? sono decine i casi
> in cui si potrebbero verificare disallineamenti...che dire di tutti quegli
> elementi gestiti dallo stesso operator, o che commerciano lo stesso brand o
> che appartengono alla stessa catenatutti casi in cui tra l'altro, vista
> la maggior distribuzione spaziale, è molto più facile che i singoli
> elementi
> vengano mappati da mappatori differenti con value, che dovrebbero essere
> comuni, più o meno diversi tra loro...
>

Dove ci potrebbe mai portare il decidere di identificare le persone con un
codice alfanumerico? Ogni persona ha un nome: non è più semplice scrivere
il suo nome su tutte le cose che la riguardano?

Fu così che il signor Walter faticò a prendere la pensione, perché i suoi
contributi erano stati registrati a Valter. Fu così che la povera Jose
dovette farsi riconoscere in tribunale l'accesso all'università, visto che
sul diploma di maturità c'era scritto Iose. E fu così che mio nonno faceva
Bosso di cognome mentre tutti i suoi fratelli erano Bossi.

Non lo dico io: da quando esistono i database, anzi, diciamo da un mese
dopo :) , ci si è resi conto che i dati vanno normalizzati. Le relazioni
tra entità diverse non possono essere identificate da dati che possono
cambiare. Se mi taglio i capelli, o se mi vesto di verde invece che di
rosso, mia moglie o i miei colleghi capiscono che sono ancora io, perché
non mi cercano come "quello con la maglia rossa".

Più lasciamo che i dati siano non-normalizzati, più li gettiamo nel caos.
Vale anche per l'operator e per il brand, sia chiaro! Al momento il caso
d'uso più problematico sono i civici; il secondo più problematico sono i
CAP e i Comuni di appartenenza. Oggi, per sapere se un certo numero civico
sta a Vercelli o a Borgovercelli stiamo guardando se ha la maglia rossa :)


> qui non stiamo parlando di qualche elemento più o meno esotico e raro che
> quindi può essere gestito  mappato unicamente da un elite di mappatori
> esperti, ma di un dato maledettamente comune e che deve essere
> necessariamente frutto anche del contributo dei meno esperti... il
> trascurare questo aspetto per paura di disallineamenti o per avere query di
> ricerca sensate e semplici mi sembra onestamente un po' assurdo. e come uno
> inesperto non può sapere che o come deve cercare gli addr:street può
> benissimo non sapere nulla delle relazioni; tanto più che le relazioni e i
> tag ed essi associati, sono  nascosti o in secondo piano  in un po' tutti
> gli editor, specialmente in quelli usati da meno esperti, rispetto i tag
> dell'elemento.
>

Questo è di nuovo un problema dell'editor. Se esiste uno strumento (le
relazioni) che permette di normalizzare i dati *e quindi migliorarne la
qualità*, devo usarlo. Se è complicato usarlo nell'editor, l'editor va
modificato. Se l'editor rimane così, meglio cercarne un altro.

Immagina di essere il classico magazziniere in un'azienda privata. Ti
dicono "da oggi, invece di scrivere un numero sui colli col pennarello,
devi metterci un codice a barre e poi leggere quello". Tu protesti perché
disegnare il codice a barre col pennarello è una cosa improponibile, e
leggerlo è complicato. Cosa fa un'azienda sana? Ti mette a disposizione una
stampante di codici a barre e un lettore ottico, e pure un sistema che sa
gestire l'associazione codice a barre - prodotto. E a quel punto voglio
vedere se scrivi ancora un numero a caso con il pennarello!

Beh, in questo caso, l'azienda privata sei tu mappatore, tu sviluppatore,
tu contributore del progetto OSM. Mi sembra che stiamo volutamente tirando
il freno a mano. D'accordo, open culture, open source, community, tutto
bello. Ma prima diciamo che vogliamo fare "il miglior database geografico",
poi, invece di fare un database come se fosse un bell'archivio ordinato e
referenziato, facciamo in realtà una lista di bigliettini, anzi, di
etichette (tag), e le appiccichiamo sul muro.

La meniamo sempre che noi siamo meglio di un fornitore commerciale che
aggiorna o visualizza i dati in base a logiche commerciali. Peccato che poi
noi i dati li inseriamo e li aggiorniamo sulla base di logiche come "se uno
non capisce come fare una cosa, non la si fa". Potremmo scoprire (esempio a
caso) che in Italia ci sono solo una ventina di "Carrefour Market", perché
gli altri "GS" ce li siamo persi (magari perché erano scritti "Gs") e non
abbiamo fatto CTRL+F su quelli!

Inoltre, i mappatori meno esperti dovrebbero in seguito diventare esperti.
Quando hai fatto la prima lezione di scuola guida non sapevi che dovevi
accendere le quattro frecce se c'è una coda inattesa... ma l'istruttore non
ha mica detto "tieni, questa è la tua patente, per evitarti difficoltà ora
deprechiamo le quattro frecce e siamo a posto così".

Ciao,

Simone
___
Talk-it 

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

[Catonano]

Il giorno 14 dicembre 2017 11:24, Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> 2017-12-14 9:27 GMT+01:00 Simone Saviolo :
>
>> Invece noi su OSM dobbiamo abbattere le barriere all'ingresso perché i
>> mappatori abbiano vita facile, dobbiamo abbattere le barriere in uscita
>> perché i consumatori abbiano vita facile, e poi siamo un progetto open,
>> mica dobbiamo cristallizzarci, no? Se la community dice che le relazioni
>> sono scomode da usare, non le si usano. È meglio ripetere i dati cinquanta
>> volte in cinquanta posti diversi, perché puoi farlo con cinquanta soli
>> clic, invece di usarne cinquantacinque per fare una relazione e aggiungerci
>> i numeri civici. (Sarcasmo, se non fosse chiaro).
>>
>
>
> le relazioni sono comunque onerose nel parsing e per ogni modifica
> (parsing del diff).
>

Non ho capito bene a cosa ti riferisci

Osservo che un programam scritto in python è oneroso rispetto a uno scritto
in assembler

Tutto è relativo

Eventuali software che avessero problemi nel parsing potrebbero estrarre i
dati e metterli in un formato più adatto al loro progetto

Del resto la relazione street esiste per un motivo

Il motivo è esattamente quello che replicare lo stesso dato su motli punti
è una bad practice nelle basi dati dagli anni 60 almeno


>
>
>>
>> E così, invece di avere una query semplice e sensata (cerca relazioni
>> street con quel nome, estrai tutti i membri della relazione), ora facciamo
>> una query assurda (tutti gli oggetti con highway=* e name=pippo, oppure con
>> addr:street=pippo) che non ci dà i risultati giusti *perché è facilissimo
>> disallineare i dati*. Magari qualcuno li migliora da una parte (come in
>> questo caso, con un nome più corretto per la strada) ma *non può sapere (a
>> meno di non sapere esattamente cosa cercare)* cos'altro deve modificare.
>>
>
>
> Quando qualcuno usava le relazioni per gruppare elementi di una strada, il
> mappatore doveva sapere che esistesse una relazione e doveva cercarla e
> avere un programma di editing che supportava modificare relazioni di questo
> tipo (sopratutto per i civici è comodo poterli inserire con un smartphone),
> tutto non scontato, perciò si sono spesso rotte o erano incomplete.
>

invece così le informazioni sono coerenti e complete ?

Le relazioni incomplete si possono completare e quelle rotte si possono
riparare

Riparare e completare relazioni costa una quantità di lavoro infinitamente
inferiore rispetto all' informazione duplicata n volte

Vespucci supporta le relazioni anche su smartphone


>
>
>>
>> Mi spiego meglio: oggi stiamo parlando dei numeri civici. Se modifico il
>> nome di una strada, devo sapere che devo cercare anche tutti gli elementi
>> con addr:street=. E io lo so perché mappo da 8 anni, ma un altro (un
>> principiante, magari) non lo sa,
>>
>
>
> proprio per questo c'è OSM inspector ;-)
>

certo. Poi però l' olio di gomito che ci vuole a correggere tutto mi pare
che OSM inspector non lo metta


>
>
>
>> oppure io stesso quel giorno lì sto facendo una modifica al volo, oppure
>> mi sono distratto e mi sono dimenticato di farlo - e già così ho rovinato i
>> dati.
>>
>
>
> adesso, se ti sbagli con un civico e scrivi il nome sbagliato della
> strada, salta all'occhio, se invece sbagli il nome della relazione
> otteniamo un dato falso e non ci sono indicazioni, l'errore può dormire più
> tranquillo
>

e perché ? Una relazione non è ispezionabile, a mano o da parte di un
software ?
Questo argomento mi pare non conseguente


>
>
>>
>>
>>
>> Oltretutto, nel caso specifico, prima diciamo no ad usare le relazioni (e
>> allora perché non facciamo che eliminarle?!),
>>
>
appunto



perché "nel caso basterà fare un cerca e sostituisci", poi però, quando
>> succede, viene fuori che un cerca e sostituisci (sempre che ci ricordiamo
>> di farlo) in realtà è un mechanical edit e va analizzato e discusso e
>> presentato alla community e documentato e votato.
>>
>


>
>
> va discusso con gli abitanti della strada.
>

eh ?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Simone Saviolo]

Il giorno 14 dicembre 2017 11:24, Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> 2017-12-14 9:27 GMT+01:00 Simone Saviolo :
>
>> Invece noi su OSM dobbiamo abbattere le barriere all'ingresso perché i
>> mappatori abbiano vita facile, dobbiamo abbattere le barriere in uscita
>> perché i consumatori abbiano vita facile, e poi siamo un progetto open,
>> mica dobbiamo cristallizzarci, no? Se la community dice che le relazioni
>> sono scomode da usare, non le si usano. È meglio ripetere i dati cinquanta
>> volte in cinquanta posti diversi, perché puoi farlo con cinquanta soli
>> clic, invece di usarne cinquantacinque per fare una relazione e aggiungerci
>> i numeri civici. (Sarcasmo, se non fosse chiaro).
>>
>
> le relazioni sono comunque onerose nel parsing e per ogni modifica
> (parsing del diff).
>

Ma non lo sono nell'estrazione dati, che è l'operazione che viene svolta la
maggior parte del tempo, a differenza della modifica che è essenzialmente
un'operazione offline (nel senso che avviene sporadicamente). Il parsing
del diff lo fa una macchina, che lo fa correttamente, ed è molto meno
frequente di una qualsiasi lettura.

(Sempre che io abbia capito cosa intendi con "parsing del diff")

E così, invece di avere una query semplice e sensata (cerca relazioni
>> street con quel nome, estrai tutti i membri della relazione), ora facciamo
>> una query assurda (tutti gli oggetti con highway=* e name=pippo, oppure con
>> addr:street=pippo) che non ci dà i risultati giusti *perché è facilissimo
>> disallineare i dati*. Magari qualcuno li migliora da una parte (come in
>> questo caso, con un nome più corretto per la strada) ma *non può sapere (a
>> meno di non sapere esattamente cosa cercare)* cos'altro deve modificare.
>>
>
> Quando qualcuno usava le relazioni per gruppare elementi di una strada, il
> mappatore doveva sapere che esistesse una relazione e doveva cercarla e
> avere un programma di editing che supportava modificare relazioni di questo
> tipo (sopratutto per i civici è comodo poterli inserire con un smartphone),
> tutto non scontato, perciò si sono spesso rotte o erano incomplete.
>

Per prima cosa, è un problema del software di editing. Tu stai spostando il
problema sul mappatore, cioè sull'utente di quel software.

Inoltre, inserendoli da smartphone, ad esempio con Keypad Mapper, mi viene
già suggerito il nome della strada: si potrebbe quindi far cercare
all'editor la relazione corrispondente, e l'editor, invece di aggiungere il
tag addr:street, dovrebbe solo aggiungere il nodo alla relazione.

Attualmente, con Keypad Mapper, mi viene suggerito il nome della strada, io
a mano vado a metterlo nella schermata di dettagli (e potrei scriverlo
sbagliato già lì), e questo viene aggiunto ai nodi creati. Peccato che, se
giro l'angolo *e mi dimentico di cambiare il nome della strada*, continuo
ad inserire i civici di via Cavour come se fossero su corso Garibaldi...

Premesso che far inserire automaticamente il nome della strada proposto dal
software sarebbe sbagliato (cattivo segnale GPS, casi limite vicino agli
incroci, etc.), cambiare il valore di addr:street o cambiare la relazione
di riferimento sono operazioni che vanno fatte fare all'utente. Ma l'utente
non ha bisogno di sapere se sta facendo l'una o l'altra cosa: basta che il
software gli dica che sta assegnando i civici a via Cavour.

Infine, ti faccio presente che il tag addr:street mi richiede comunque di
scoprire dov'è la strada. Mi è capitato proprio pochi giorni fa: per
associare un numero civico a via Cavour, ho dovuto guardare se la way, nel
suo name, aveva "via Cavour" o "via Conte di Cavour" o "via Camillo Benso
conte di Cavour". Al contrario, potresti avere una lista di "strade a cui
associare questo civico" - e la cosa più furba sarebbe prendere l'elenco
delle relazioni street. Oppure, sarebbe trasparente all'utente se l'editor
gli mostrasse l'elenco dei nomi delle highway=* che compaiono nel raggio di
200 metri - ma proprio perché per l'utente è trasparente, dovremmo usare la
soluzione migliore, non quella più semplice.

Mi spiego meglio: oggi stiamo parlando dei numeri civici. Se modifico il
>> nome di una strada, devo sapere che devo cercare anche tutti gli elementi
>> con addr:street=. E io lo so perché mappo da 8 anni, ma un altro (un
>> principiante, magari) non lo sa,
>>
>
> proprio per questo c'è OSM inspector ;-)
>

Fare errori, cercarli, segnalarli e chiedere di correggerli è una cosa.

Evitare di fare errori (soprattutto quando l'errore viene fuori tre anni
dopo la mappatura) è un'altra.

oppure io stesso quel giorno lì sto facendo una modifica al volo, oppure mi
>> sono distratto e mi sono dimenticato di farlo - e già così ho rovinato i
>> dati.
>>
>
> adesso, se ti sbagli con un civico e scrivi il nome sbagliato della
> strada, salta all'occhio, se invece sbagli il nome della relazione
> otteniamo un dato falso e non ci sono indicazioni, l'errore può dormire più
> tranquillo
>

Sbagliare 

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

[Aury88]

dieterdreist wrote
> 2017-12-14 9:27 GMT+01:00 Simone Saviolo 

> simone.saviolo@

> :
> 
>> Invece noi su OSM dobbiamo abbattere le barriere all'ingresso perché i
>> mappatori abbiano vita facile, dobbiamo abbattere le barriere in uscita
>> perché i consumatori abbiano vita facile, e poi siamo un progetto open,
>> mica dobbiamo cristallizzarci, no? Se la community dice che le relazioni
>> sono scomode da usare, non le si usano. È meglio ripetere i dati
>> cinquanta
>> volte in cinquanta posti diversi, perché puoi farlo con cinquanta soli
>> clic, invece di usarne cinquantacinque per fare una relazione e
>> aggiungerci
>> i numeri civici. (Sarcasmo, se non fosse chiaro).
>>
> 
> 
> le relazioni sono comunque onerose nel parsing e per ogni modifica
> (parsing
> del diff).
> 
> 
> 
>>
>> E così, invece di avere una query semplice e sensata (cerca relazioni
>> street con quel nome, estrai tutti i membri della relazione), ora
>> facciamo
>> una query assurda (tutti gli oggetti con highway=* e name=pippo, oppure
>> con
>> addr:street=pippo) che non ci dà i risultati giusti *perché è facilissimo
>> disallineare i dati*. Magari qualcuno li migliora da una parte (come in
>> questo caso, con un nome più corretto per la strada) ma *non può sapere
>> (a
>> meno di non sapere esattamente cosa cercare)* cos'altro deve modificare.
>>
> 
> 
> Quando qualcuno usava le relazioni per gruppare elementi di una strada, il
> mappatore doveva sapere che esistesse una relazione e doveva cercarla e
> avere un programma di editing che supportava modificare relazioni di
> questo
> tipo (sopratutto per i civici è comodo poterli inserire con un
> smartphone),
> tutto non scontato, perciò si sono spesso rotte o erano incomplete.
> 
> 
> 
>>
>> Mi spiego meglio: oggi stiamo parlando dei numeri civici. Se modifico il
>> nome di una strada, devo sapere che devo cercare anche tutti gli elementi
>> con addr:street=
> 
> . E io lo so perché mappo da 8 anni, ma un altro (un
>> principiante, magari) non lo sa,
>>
> 
> 
> proprio per questo c'è OSM inspector ;-)
> 
> 
> 
> 
>> oppure io stesso quel giorno lì sto facendo una modifica al volo, oppure
>> mi sono distratto e mi sono dimenticato di farlo - e già così ho rovinato
>> i
>> dati.
>>
> 
> 
> adesso, se ti sbagli con un civico e scrivi il nome sbagliato della
> strada,
> salta all'occhio, se invece sbagli il nome della relazione otteniamo un
> dato falso e non ci sono indicazioni, l'errore può dormire più tranquillo
> 
> 
> 
>>
>> Scusate il lungo sfogo, ma è frustrante dire "facciamo un minimo sforzo
>> in
>> più perché non succeda *questo problema* nel futuro", sentirsi rispondere
>> "non è un minimo sforzo, è una complicazione inutile che aggiunge solo
>> difficoltà per i mappatori, non lo facciamo", e poi trovarsi di fronte *a
>> quell'esatto problema*... e chiedersi come diamine potremmo fare a
>> risolverlo.
>>
> 
> 
> CTRL+F
> ;-)
> 
> 
> 
>>
>> Oltretutto, nel caso specifico, prima diciamo no ad usare le relazioni (e
>> allora perché non facciamo che eliminarle?!), perché "nel caso basterà
>> fare
>> un cerca e sostituisci", poi però, quando succede, viene fuori che un
>> cerca
>> e sostituisci (sempre che ci ricordiamo di farlo) in realtà è un
>> mechanical
>> edit e va analizzato e discusso e presentato alla community e documentato
>> e
>> votato.
>>
> 
> 
> va discusso con gli abitanti della strada.
> 
> 
> Ciao,
> Martin ;-)
> 
> ___
> Talk-it mailing list

> Talk-it@

> https://lists.openstreetmap.org/listinfo/talk-it

quoto tutto e aggiungo il mio dubbio: dove ci potrebbe portare decidere di
mappare con una relazione per paura dei disallineamenti? sono decine i casi
in cui si potrebbero verificare disallineamenti...che dire di tutti quegli
elementi gestiti dallo stesso operator, o che commerciano lo stesso brand o
che appartengono alla stessa catenatutti casi in cui tra l'altro, vista
la maggior distribuzione spaziale, è molto più facile che i singoli elementi
vengano mappati da mappatori differenti con value, che dovrebbero essere
comuni, più o meno diversi tra loro...

qui non stiamo parlando di qualche elemento più o meno esotico e raro che
quindi può essere gestito  mappato unicamente da un elite di mappatori
esperti, ma di un dato maledettamente comune e che deve essere
necessariamente frutto anche del contributo dei meno esperti... il
trascurare questo aspetto per paura di disallineamenti o per avere query di
ricerca sensate e semplici mi sembra onestamente un po' assurdo. e come uno
inesperto non può sapere che o come deve cercare gli addr:street può
benissimo non sapere nulla delle relazioni; tanto più che le relazioni e i 
tag ed essi associati, sono  nascosti o in secondo piano  in un po' tutti
gli editor, specialmente in quelli usati da meno esperti, rispetto i tag
dell'elemento.





-
Ciao,
Aury
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[Martin Koppenhoefer]

2017-12-14 9:27 GMT+01:00 Simone Saviolo :

> Invece noi su OSM dobbiamo abbattere le barriere all'ingresso perché i
> mappatori abbiano vita facile, dobbiamo abbattere le barriere in uscita
> perché i consumatori abbiano vita facile, e poi siamo un progetto open,
> mica dobbiamo cristallizzarci, no? Se la community dice che le relazioni
> sono scomode da usare, non le si usano. È meglio ripetere i dati cinquanta
> volte in cinquanta posti diversi, perché puoi farlo con cinquanta soli
> clic, invece di usarne cinquantacinque per fare una relazione e aggiungerci
> i numeri civici. (Sarcasmo, se non fosse chiaro).
>


le relazioni sono comunque onerose nel parsing e per ogni modifica (parsing
del diff).



>
> E così, invece di avere una query semplice e sensata (cerca relazioni
> street con quel nome, estrai tutti i membri della relazione), ora facciamo
> una query assurda (tutti gli oggetti con highway=* e name=pippo, oppure con
> addr:street=pippo) che non ci dà i risultati giusti *perché è facilissimo
> disallineare i dati*. Magari qualcuno li migliora da una parte (come in
> questo caso, con un nome più corretto per la strada) ma *non può sapere (a
> meno di non sapere esattamente cosa cercare)* cos'altro deve modificare.
>


Quando qualcuno usava le relazioni per gruppare elementi di una strada, il
mappatore doveva sapere che esistesse una relazione e doveva cercarla e
avere un programma di editing che supportava modificare relazioni di questo
tipo (sopratutto per i civici è comodo poterli inserire con un smartphone),
tutto non scontato, perciò si sono spesso rotte o erano incomplete.



>
> Mi spiego meglio: oggi stiamo parlando dei numeri civici. Se modifico il
> nome di una strada, devo sapere che devo cercare anche tutti gli elementi
> con addr:street=. E io lo so perché mappo da 8 anni, ma un altro (un
> principiante, magari) non lo sa,
>


proprio per questo c'è OSM inspector ;-)




> oppure io stesso quel giorno lì sto facendo una modifica al volo, oppure
> mi sono distratto e mi sono dimenticato di farlo - e già così ho rovinato i
> dati.
>


adesso, se ti sbagli con un civico e scrivi il nome sbagliato della strada,
salta all'occhio, se invece sbagli il nome della relazione otteniamo un
dato falso e non ci sono indicazioni, l'errore può dormire più tranquillo



>
> Scusate il lungo sfogo, ma è frustrante dire "facciamo un minimo sforzo in
> più perché non succeda *questo problema* nel futuro", sentirsi rispondere
> "non è un minimo sforzo, è una complicazione inutile che aggiunge solo
> difficoltà per i mappatori, non lo facciamo", e poi trovarsi di fronte *a
> quell'esatto problema*... e chiedersi come diamine potremmo fare a
> risolverlo.
>


CTRL+F
;-)



>
> Oltretutto, nel caso specifico, prima diciamo no ad usare le relazioni (e
> allora perché non facciamo che eliminarle?!), perché "nel caso basterà fare
> un cerca e sostituisci", poi però, quando succede, viene fuori che un cerca
> e sostituisci (sempre che ci ricordiamo di farlo) in realtà è un mechanical
> edit e va analizzato e discusso e presentato alla community e documentato e
> votato.
>


va discusso con gli abitanti della strada.


Ciao,
Martin ;-)
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Aury88]

Giovanni Berti-2 wrote
> È possibile correggere massivamente gruppi di numeri civici sostituendo 
> la descrizione errata della strada con quella giusta? Ho provato a 
> modificare con Notepad++ il file osm ma non funziona.
> 
> Grazie
> 
> Giovanni Berti

Ciao.
In josm direi che è molto semplice.
Scarichi l'area in cui vuoi modificare i dati e dopo aver fatto Ctrl+F
scrivi nella barra di ricerca la stringa 
addr:street="nome strada errato" 
in questa maniera ti ritrovi selezionati tutti i civici che hanno quel value
per la chiave addr:street. a quel punto puoi modificare a tutti gli elementi
selezionati il value sfruttando il pannello oggetti a destra.



-
Ciao,
Aury
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Simone Saviolo]

Il giorno 13 dicembre 2017 19:17, Giovanni Berti  ha scritto:

> Le modifiche non sono state portate all'interno della chiave addr:street
> dei singoli numeri civici e lo strumento utilizzato lo evidenzia segnalando
> l'errore "Street not found". Ho provato a correggerne a mano alcuni con
> Josm e in quei casi gli errori sono rientrati e ora quei  numeri civici
> risultano correttamente collegati alla strada con il nome corretto.
>
> È possibile correggere massivamente gruppi di numeri civici sostituendo la
> descrizione errata della strada con quella giusta? Ho provato a modificare
> con Notepad++ il file osm ma non funziona.
>

Ciao a tutti. Perdonatemi se sembrerò polemico - forse è perché sto per
esserlo :) Vorrei comunque fare una discussione costruttiva.

Qualche anno fa, io insieme ad altri dicevamo che mettere le informazioni
dell'indirizzo sulla singola feature era evidentemente sbagliato, e che era
il caso di lasciare il solo numero civico sulla feature spostando invece
tutto il resto (nome strada, CAP, città...) in una relazione che
rappresenta la strada, come street o associatedStreet, alla quale la
feature andrebbe aggiunta come membro. Quarant'anni fa chi faceva database
sapeva che questo è il modo più sensato di operare e lo chiamava
"normalizzazione".

Invece noi su OSM dobbiamo abbattere le barriere all'ingresso perché i
mappatori abbiano vita facile, dobbiamo abbattere le barriere in uscita
perché i consumatori abbiano vita facile, e poi siamo un progetto open,
mica dobbiamo cristallizzarci, no? Se la community dice che le relazioni
sono scomode da usare, non le si usano. È meglio ripetere i dati cinquanta
volte in cinquanta posti diversi, perché puoi farlo con cinquanta soli
clic, invece di usarne cinquantacinque per fare una relazione e aggiungerci
i numeri civici. (Sarcasmo, se non fosse chiaro).

E così, invece di avere una query semplice e sensata (cerca relazioni
street con quel nome, estrai tutti i membri della relazione), ora facciamo
una query assurda (tutti gli oggetti con highway=* e name=pippo, oppure con
addr:street=pippo) che non ci dà i risultati giusti *perché è facilissimo
disallineare i dati*. Magari qualcuno li migliora da una parte (come in
questo caso, con un nome più corretto per la strada) ma *non può sapere (a
meno di non sapere esattamente cosa cercare)* cos'altro deve modificare.

Mi spiego meglio: oggi stiamo parlando dei numeri civici. Se modifico il
nome di una strada, devo sapere che devo cercare anche tutti gli elementi
con addr:street=. E io lo so perché mappo da 8 anni, ma un altro (un
principiante, magari) non lo sa, oppure io stesso quel giorno lì sto
facendo una modifica al volo, oppure mi sono distratto e mi sono
dimenticato di farlo - e già così ho rovinato i dati. Ma pensate se oltre
ai numeri civici ci fossero altre cinque o sei categorie di oggetti
associati alla strada - o trenta, perché no. Di ognuno di questi cinque,
sei, trenta casi dovrei conoscere i tag coinvolti, se ci sono
trasformazioni da fare, rintracciarli, modificarli... e incrociare le dita,
aggiungo io. Tutta roba che con la relazione sarebbe risolta nel momento in
cui si associa l'oggetto alla strada.

Scusate il lungo sfogo, ma è frustrante dire "facciamo un minimo sforzo in
più perché non succeda *questo problema* nel futuro", sentirsi rispondere
"non è un minimo sforzo, è una complicazione inutile che aggiunge solo
difficoltà per i mappatori, non lo facciamo", e poi trovarsi di fronte *a
quell'esatto problema*... e chiedersi come diamine potremmo fare a
risolverlo.

Oltretutto, nel caso specifico, prima diciamo no ad usare le relazioni (e
allora perché non facciamo che eliminarle?!), perché "nel caso basterà fare
un cerca e sostituisci", poi però, quando succede, viene fuori che un cerca
e sostituisci (sempre che ci ricordiamo di farlo) in realtà è un mechanical
edit e va analizzato e discusso e presentato alla community e documentato e
votato.

TL;DR: il problema esiste ed è molto più serio di una sostituzione su una
manciata di elementi in un paese. Per favore, *per favore*, possiamo
riprendere (o iniziare) ad usare le relazioni per i numeri civici? Possiamo
almeno riaprire la discussione?

Ciao,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Davide Sandona']

>
> Grazie dell'attenzione: si tratta di Storo (Tn)


Guardando la cronologia, si tratta di un import del 2012.
Eviterei l'approccio di sostituzione con Notepad++ o editor testuali, in
quanto è necessario prestare molta attenzione agli elementi che si vanno a
modificare.

Poiché il paese è abbastanza piccolo, utilizzerei JOSM con il seguente
approccio:
1. scaricare l'area interessata.
2. utilizzare lo strumento "Cerca" (puoi utilizzare la combinazione dei
tasti CTRL + F)
3. inserire questi termini di ricerca:  type:node "addr:street"="NOME VIA
DA CERCARE"
Ovviamente sostituisci NOME VIA DA CERCARE con il nome sbagliato da
correggere, ad esempio "Via A. Manzoni". Poi premi il pulsante Cerca, e
JOSM selezionerà tutti i nodi che avranno quel nome di via. A questo punto,
nella lista dei tag fai doppio click su "addr:street" e inserisci il valore
corretto, ad esempio "Via Alessandro Manzoni". In questo modo effettui la
sostituzione su tutti i nodi in un colpo solo.
4. Ripetere il procedimento per tutte le vie da correggere.

Se hai altri dubbi, chiedi pure.


Davide.

Il giorno 13 dicembre 2017 19:17, Giovanni Berti  ha scritto:

> Seguendo il consiglio che ho letto poco tempo fa in Talk-it ho utilizzato
> OSM Inspector | Geofabrik Tools (http://tools.geofabrik.de/osmi/) per
> controllare un'area che seguo e ho notato moltissimi errori dovuti
> all'errata indicazione del valore nella chiave addr:street dei numeri
> civici. Ciò penso sia dovuto al fatto che, seguendo correttamente le
> disposizioni e le regole dell'Archivio nazionale dei numeri civici delle
> strade urbane (ANNCSU) sono state modificate le denominazioni di alcune
> strade mettendo titoli onorifici e nomi al completo. Per esempio via G.
> Garibaldi è diventata Via Giuseppe Garibaldi.
>
> Le modifiche non sono state portate all'interno della chiave addr:street
> dei singoli numeri civici e lo strumento utilizzato lo evidenzia segnalando
> l'errore "Street not found". Ho provato a correggerne a mano alcuni con
> Josm e in quei casi gli errori sono rientrati e ora quei  numeri civici
> risultano correttamente collegati alla strada con il nome corretto.
>
> È possibile correggere massivamente gruppi di numeri civici sostituendo la
> descrizione errata della strada con quella giusta? Ho provato a modificare
> con Notepad++ il file osm ma non funziona.
>
> Grazie
>
> Giovanni Berti
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Davide Sandona']

Ciao Giovanni, potresti dire quale area si tratta?

Davide.

Il giorno 13 dicembre 2017 19:17, Giovanni Berti  ha scritto:

> Seguendo il consiglio che ho letto poco tempo fa in Talk-it ho utilizzato
> OSM Inspector | Geofabrik Tools (http://tools.geofabrik.de/osmi/) per
> controllare un'area che seguo e ho notato moltissimi errori dovuti
> all'errata indicazione del valore nella chiave addr:street dei numeri
> civici. Ciò penso sia dovuto al fatto che, seguendo correttamente le
> disposizioni e le regole dell'Archivio nazionale dei numeri civici delle
> strade urbane (ANNCSU) sono state modificate le denominazioni di alcune
> strade mettendo titoli onorifici e nomi al completo. Per esempio via G.
> Garibaldi è diventata Via Giuseppe Garibaldi.
>
> Le modifiche non sono state portate all'interno della chiave addr:street
> dei singoli numeri civici e lo strumento utilizzato lo evidenzia segnalando
> l'errore "Street not found". Ho provato a correggerne a mano alcuni con
> Josm e in quei casi gli errori sono rientrati e ora quei  numeri civici
> risultano correttamente collegati alla strada con il nome corretto.
>
> È possibile correggere massivamente gruppi di numeri civici sostituendo la
> descrizione errata della strada con quella giusta? Ho provato a modificare
> con Notepad++ il file osm ma non funziona.
>
> Grazie
>
> Giovanni Berti
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Giovanni Berti]

Seguendo il consiglio che ho letto poco tempo fa in Talk-it ho 
utilizzato OSM Inspector | Geofabrik Tools 
(http://tools.geofabrik.de/osmi/) per controllare un'area che seguo e ho 
notato moltissimi errori dovuti all'errata indicazione del valore nella 
chiave addr:street dei numeri civici. Ciò penso sia dovuto al fatto che, 
seguendo correttamente le disposizioni e le regole dell'Archivio 
nazionale dei numeri civici delle strade urbane (ANNCSU) sono state 
modificate le denominazioni di alcune strade mettendo titoli onorifici e 
nomi al completo. Per esempio via G. Garibaldi è diventata Via Giuseppe 
Garibaldi.


Le modifiche non sono state portate all'interno della chiave addr:street 
dei singoli numeri civici e lo strumento utilizzato lo evidenzia 
segnalando l'errore "Street not found". Ho provato a correggerne a mano 
alcuni con Josm e in quei casi gli errori sono rientrati e ora quei  
numeri civici risultano correttamente collegati alla strada con il nome 
corretto.


È possibile correggere massivamente gruppi di numeri civici sostituendo 
la descrizione errata della strada con quella giusta? Ho provato a 
modificare con Notepad++ il file osm ma non funziona.


Grazie

Giovanni Berti



___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it