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

Simone Saviolo simone.saviolo a gmail.com
Gio 14 Dic 2017 11:33:18 UTC


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

> 2017-12-14 9:27 GMT+01:00 Simone Saviolo <simone.saviolo at gmail.com>:
>
>> 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-it/attachments/20171214/9c91f906/attachment-0001.html>


Maggiori informazioni sulla lista Talk-it