Cambio massivo valore alla chiave addr:street nei numeri civici

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Cambio massivo valore alla chiave addr:street nei numeri civici

Giovanni Berti-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Davide Sandona'
In reply to this post by Giovanni Berti-2
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Simone Saviolo
In reply to this post by Giovanni Berti-2
Il giorno 13 dicembre 2017 19:17, Giovanni Berti <[hidden email]> 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=<nome>. 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Aury88
In reply to this post by Giovanni Berti-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Ciao,
Aury
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

dieterdreist
In reply to this post by Simone Saviolo
2017-12-14 9:27 GMT+01:00 Simone Saviolo <[hidden email]>:
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=<nome>. 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

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

> simone.saviolo@

> &gt;:
>
>> 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=
> <nome>
> . 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 catena....tutti 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

_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Ciao,
Aury
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Simone Saviolo
In reply to this post by dieterdreist
Il giorno 14 dicembre 2017 11:24, Martin Koppenhoefer <[hidden email]> ha scritto:
2017-12-14 9:27 GMT+01:00 Simone Saviolo <[hidden email]>:
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=<nome>. 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 il name nella relazione è un errore, tanto quanto sbagliarlo nel name della highway. Nel civico invece non scriverei più un dato potenzialmente sbagliato, perché sarebbe ricavato dalla relazione a cui appartiene. O togli il civico dalla relazione (il che è un'operazione non certo involontaria), o il civico avrà sempre il nome giusto - almeno tanto giusto quant'è nella relazione. 

Se invece metti il nome sbagliato su highway e civici, poi devi modificarli tutti. E se te ne perdi uno, hai rovinato i dati. 
 
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
;-)

A parte il fatto che operazioni simili sono state segnalate come mechanical edit...

Tu mi proponi di fare CTRL+F. Io ti propongo di non aver mai più bisogno di fare neanche CTRL+F! E neanche di ricordarti ogni tanto di andare a controllare se per caso da qualche parte devi fare 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.

Questa non l'ho capita. 
 
Ciao,
Martin ;-)

Ciao,

Simone :) 

_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Catonano
In reply to this post by dieterdreist


Il giorno 14 dicembre 2017 11:24, Martin Koppenhoefer <[hidden email]> ha scritto:
2017-12-14 9:27 GMT+01:00 Simone Saviolo <[hidden email]>:
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=<nome>. 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Simone Saviolo
In reply to this post by Aury88
Il giorno 14 dicembre 2017 12:24, Aury88 <[hidden email]> 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 catena....tutti 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 mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Catonano
In reply to this post by Aury88


Il giorno 14 dicembre 2017 12:24, Aury88 <[hidden email]> ha scritto:
dieterdreist wrote
> 2017-12-14 9:27 GMT+01:00 Simone Saviolo &lt;

> simone.saviolo@

> &gt;:
>
>> 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=
> <nome>
> . 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 catena....tutti 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 per paura di disallineamenti o per avere query di
ricerca sensate e semplici mi sembra onestamente un po' assurdo.

A me sembra assurdo il contrario

Che si debba essere lenti a correggere i dati e farlo con maggior fatica del necessario per scelta.


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


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

_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Simone Saviolo
Il giorno 14 dicembre 2017 13:05, Catonano <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Catonano


Il giorno 14 dicembre 2017 13:18, Simone Saviolo <[hidden email]> ha scritto:
Il giorno 14 dicembre 2017 13:05, Catonano <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Simone Saviolo
Il giorno 14 dicembre 2017 14:21, Catonano <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Simone Saviolo
Il giorno 14 dicembre 2017 14:30, Simone Saviolo <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

dieterdreist
In reply to this post by Simone Saviolo
2017-12-14 12:33 GMT+01:00 Simone Saviolo <[hidden email]>:
Il giorno 14 dicembre 2017 11:24, Martin Koppenhoefer <[hidden email]> ha scritto:
2017-12-14 9:27 GMT+01:00 Simone Saviolo <[hidden email]>:
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:


Inline-Bild 1

Ciao,
Martin

_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Catonano
In reply to this post by Simone Saviolo


Il giorno 14 dicembre 2017 14:30, Simone Saviolo <[hidden email]> ha scritto:
Il giorno 14 dicembre 2017 14:21, Catonano <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Alessandro P.
In reply to this post by Simone Saviolo
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

dieterdreist
In reply to this post by Catonano
2017-12-14 12:59 GMT+01:00 Catonano <[hidden email]>:

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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Cambio massivo valore alla chiave addr:street nei numeri civici

Catonano
In reply to this post by dieterdreist


Il giorno 14 dicembre 2017 14:41, Martin Koppenhoefer <[hidden email]> ha scritto:
2017-12-14 12:33 GMT+01:00 Simone Saviolo <[hidden email]>:
Il giorno 14 dicembre 2017 11:24, Martin Koppenhoefer <[hidden email]> ha scritto:
2017-12-14 9:27 GMT+01:00 Simone Saviolo <[hidden email]>:
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



Inline-Bild 1

Ciao,
Martin

_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it



_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
123