Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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
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
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
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
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 il name nella relazione è un
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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
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 mailing list Talk-it@open
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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 per paura di disallineam
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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
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
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
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
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
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
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
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
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
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
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
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
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
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&lon=11.67004&lat=44.80572&zoom=11&overlays=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 la relazione e dec
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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
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
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
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
> > 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
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
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
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 pochi a contribuire alla > m
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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, 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 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
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
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, invece di scrivere un numero
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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
> > 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 > > Diciamo che dover difendere concetto fondamentali di
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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 c
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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 cam
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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
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
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 dell'utente di turno (o del troll di
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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 sareb
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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
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 ad adesso quello > che
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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 seconda volta che dico ch
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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
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&lon=18.1794130&zoom=18&camera.theta=53.308&camera.phi=-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 norm
Re: [Talk-it] Cambio massivo valore alla chiave addr:street nei numeri civici
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