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

[Catonano]

Il giorno 15 dicembre 2017 08:43, Federico Cortese <cortese...@gmail.com>
ha scritto:

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

Va bene questa cosa l'abbiamo chiarita in privato


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

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

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

Avevo capito male sull'appiattimento degli edifici.

Chiedo scusa


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

Le mie

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

[Catonano]

Il giorno 15 dicembre 2017 10:42, Aury88 <spacedrive...@gmail.com> ha
scritto:

> Catonano wrote
> > Il giorno 14 dicembre 2017 23:59, Aury88 
>
> > spacedriver88@
>
> >  ha
> > scritto:
> >
> >> Catonano wrote
> >> > Il giorno 14 dicembre 2017 18:40, Aury88 
> >>
> >> > spacedriver88@
> >>
> >> >  ha
> >> > scritto:
> >> >
> >> >> Simone Saviolo wrote
> >> >> > Il giorno 14 dicembre 2017 12:24, Aury88 
> >> >>
> >> >> > spacedriver88@
> >> >>
> >> >
> >> >> ma perchè fermarci li! l'hai detto te no? dobbiamo normalizzare i
> >> dati.
> >> >> creiamo una relazione al posto del tag amenity=bar e un altro al
> posto
> >> >> dell'amenity=restaurant e in questo ricordiamoci la relazione per la
> >> >>
> >> >
> >> > a questa obiezione è già stato risposto che amenity=cafe è un tag
> >> fisso,
> >> > mentre name="... è free form
> >> > Quindi il paragone non regge
> >>
> >>  a maggior ragione andrebbe normalizzato un tag che deve rimanere fisso!
> >> sono proprio quelli da cui si parte nei database relazionali
> >>
> >
> > non comprendo l'obiezione
>
> la normalizzazione è tanto più importante quanto diffuso (key e value
> uguali) è un tag ...idealmente è proprio dai tag più importanti, quelli
> cioè
> principali, che si dovrebbe cominciare con un processo del genere...e il
> motivo è identico a quello che utilizzate voi come argomentazione a favore
> del passaggio all'uso delle relazioni: se si deve cambiare il tag o un
> merge
> di alcune categorie di elementi allo stato attuale devi andare a pescarli
> (a
> livello globale, non locale quanto può esserlo una strada) e modificargli
> il
> tag (key e/o value) di ciascuno (e in quasi tutti i casi parliamo di
> migliaiai di elementi) con la relazione basterebbe selezionarla e spostarne
> tutti i membri nella relazione corretta (quando si tratta di merge) o
> modificare quella errata modificando unna volta sola il tag...
>
>
> > e invece no
> > Puoi tenere entrambi gli schemi, per un periodo di transizione
> > Facoltativamente
>
>  hai presente quanto è lungo un periodo di transizione se si lascia la
> possibilità di avere entrambi i metodi? il tag amenity=fitness_center è
> rimasto in circolo per anni pur essendo chiaramente nnon conforme agli std
> OSM ed erano poche migliaia di casi con in più la segnalazione di
> errore...nel caso di addr:street la situazione sarebbe peggiore con i nuovi
> inserimenti fatti da neomappatori, ma anche da altri non opportunamente
> informati, che probabilmente usando come riferimento la mappatura già
> presente e largamente più evidente  su qualsiasi editor finirebbero per
> continuare a mappare come hanno sempre fatto senza accorgersi neanche della
> presenza della relazione
>
>
> > Ovviamente quello della relazione
> >  Che siccome deve essere manuteuto una volta sole per tutti i civici si
> > suppone essere corretto
>
>  lo supponi tu, io suppondo invece che il tag addr:street venga modificato
> meno frequentemente, essendo meno evidente, e che di conseguenza i
> neomappatori che non conoscono le regole di stile su osm (es. i nomi non
> abbreviati) apporteranno cambiamenti scorretti sul nome della strada (
> quindi sul riferimento della relazione sostitutiva di addr:street). con gli
> addr:street un errore di distrazione non si perde il nome della strada ne
> il
> nome viene cambiato su tutti i nodi =>posso trovarlo e correggerlo...sulla
> relazione via ferdinando d'aragona che diventa via aragosta rimane via
> aragosta...e tu che non conosci quella via non puoi neache accorgertene ed
> eventualmente segnalarla ad un mappatore locale
>
>
questa idea che errori sui nodi si trovano ed errori sulle relazioni non si
trovano davvero non capisco da dove arrivi

Forse manca un tool per le relazioni

Ma la disponibilità di tool non qualifica la bontà degli schemi

Come dire che siccome manca il tool per le basi dati relazionali ci
accontentiamo del file csv

E comunque anche senza tool gli errori si trovano

Chiedi di essere instradato ad un indirizzo su via erdinando D'Aragona, ti
accorgi che via d'aragona non esiste e vai a guardare la relazione. oaprri
un bug, o scrivi in n forum, o su twitter

Questa idea che le relazioni occultino gli errori che non emergerebbero mai
più non me la spiego


>
>
> > è dimostrato dalle basi dati da 50 anni
>
> un db non vale l'altro...il fatto che ci siano ambiti di utilizzo di
> database in cui il sist

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

[Catonano]

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

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

Amen

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

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

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

[Catonano]

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

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

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

Con conseguenti costi aggiuntivi

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

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

[OSM-talk] shop windows on differnt streets

[Catonano]

I hope this is the right place to ask about tagging

There s this shop that has shop windows on 2 streets
https://imgur.com/a/icpwJ

Some of its shop windows have street numbers. as shown here
https://imgur.com/a/ny08t

This is  a quite common case, as you can see here
https://photos.app.goo.gl/Vr2vKuqr1S5hjf772

Some have their shop windows separated by building entrances or a different
shop windows

How do I map these ?

My idea is that every shop window should be its own point with address info
and then a relation should group them and be tagged with common data, such
as the shop name, the web site, the phone number, the operator, whatever

Does anyone here know of any example of a similar situation ?

Thanks
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Catonano]

Il giorno 14 dicembre 2017 23:09, Federico Cortese <cortese...@gmail.com>
ha scritto:

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

Federico

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

Infatti, hai unificato ogni isolato in un unico edificio

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

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

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

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

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

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

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

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

Ma l'andamento di questa discssione è stato estremamente scoraggiante

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

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

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

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

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

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

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

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

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


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


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

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


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

sono daccordo



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

È chiaro che non voglio impedire nulla a nessuno

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

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


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

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

[Catonano]

Il giorno 14 dicembre 2017 21:26, Aury88 <spacedrive...@gmail.com> 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 è cambia

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

[Catonano]

Il giorno 14 dicembre 2017 23:59, Aury88 <spacedrive...@gmail.com> 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 ch

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

[Catonano]

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

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

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

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

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

Quindi direi che no, non è pretenzzioso affatto.


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

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

Solo di questo ho parlato, in tutto il thread

Allora o non mi ai letto oppure non hai capito

In entrambi i casi sono sconfortato



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

Ti ripeto che la questione non dipende dallo specifico tool

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


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

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


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

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

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

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

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

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


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

Non hho MAI MAI MAI sostenuto quetsa cosa

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


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

Si può fare


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

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

[Catonano]

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

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

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



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


che vuol dire non locale ?


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

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

E comunque di errori ce ne sono a milioni

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

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


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


e non desideri nient'altro ?


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


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


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

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

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

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

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


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

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

[Catonano]

Il giorno 14 dicembre 2017 17:47, Simone Saviolo <simone.savi...@gmail.com>
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

[Catonano]

Il giorno 14 dicembre 2017 16:50, Aury88 <spacedrive...@gmail.com> 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
&

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

[Catonano]

Il giorno 14 dicembre 2017 16:49, Davide Sandona' <sandona.dav...@gmail.com>
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 <simone.savi...@gmail.com
> > 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 <simone.savi...@gmail.com>:
>>>
>>>> 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

[Catonano]

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

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

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

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

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

[Catonano]

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

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

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

In alcuni casi scegli di sare una relazione
In altri no

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



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

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

[Catonano]

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

> 2017-12-14 12:59 GMT+01:00 Catonano <caton...@gmail.com>:
>
>>
>> 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

[Catonano]

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

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

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

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


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

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

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


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

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


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

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


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

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

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


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

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

[Catonano]

Il giorno 14 dicembre 2017 14:30, Simone Saviolo <simone.savi...@gmail.com>
ha scritto:

> Il giorno 14 dicembre 2017 14:21, Catonano <caton...@gmail.com> 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

[Catonano]

Il giorno 14 dicembre 2017 13:18, Simone Saviolo <simone.savi...@gmail.com>
ha scritto:

> Il giorno 14 dicembre 2017 13:05, Catonano <caton...@gmail.com> 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

[Catonano]

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

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


A lavorare meno e meglio ?

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

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

Si propone una relazione e  la si vota

E comuqnue chi vorrà mapperà come vuole

Esattamente come con le altre feature


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

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

[Catonano]

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

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

Non ho capito bene a cosa ti riferisci

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

Tutto è relativo

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

Del resto la relazione street esiste per un motivo

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


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

invece così le informazioni sono coerenti e complete ?

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

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

Vespucci supporta le relazioni anche su smartphone


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

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


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

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


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



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

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

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

Re: [Talk-it] appartengono alla relazione ?

[Catonano]

Il giorno 12 novembre 2017 21:02, Federico Cortese 
ha scritto:

> 2017-11-12 14:35 GMT+01:00 Alessandro :
> >
> > Le diverse sensibilità tra i mappatori mi fanno considerare certe
> relazioni
> > quasi come una degenerazione della mappatura.
> >
>
> Sì, io eviterei quel tipo di relazioni.
>

Perchè ?


>
> > Personalmente dirigerei prima le mie attenzioni sulle centinaia di POI
> > mancanti nella zona. Terminati i POI ci sarebbero i numeri civici.
> Terminati
> > i numeri civici ci sarebbero gli idranti. Poi passarei alle relazioni del
> > servizio pubblico, i numeri di telefono e gli altri dettagli di farmacie
> e
> > negozi, gli orari d'apertura, i cestini per la raccolta dei rifiuti, il
> > numero di piani degli edifici, la mappatura dei marciapiedi e eventuali
> > scivoli dei disabili, and so forth ...
> >
>
> +1, concordo con la priorità POI e numeri civici.
>

Federico tu fai un gran lavoro ma il discorso vale anchhe per te

La domanda non era: "cosa fareste voi al mio posto ?"

La domanda era: alla relazione linkata dovrebbero appartenere gli alberi e
i cancelli ?

Allora se sai rispondere e se ti va rispondi alla mia domanda

Altrimenti puoi anche passare avanti.

Le mie priorità non erano in discussione, mi pare. Come non lo sono le tue.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] appartengono alla relazione ?

[Catonano]

Il giorno 12 novembre 2017 14:35, Alessandro  ha
scritto:


> Le diverse sensibilità tra i mappatori mi fanno considerare certe
> relazioni quasi come una degenerazione della mappatura.
>
[...]


>
> Personalmente ...
>

 [...]

> Ma si sà, ognuno è libero d'interpretare le priorità e mappare ciò che
> preferisce.
>

Delle due l'una.

O sono libero di mappare a partire da dove voglio, oppure quello che faccio
è una degenerazione.

Se è una degenerazione e la libertà di cominciare da dove voglio è solo una
gentile concessione allora cancello i miei contributi nuovi e vecchi e
lascio la mappatura ai savii.

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

Re: [Talk-it] questa fontana

[Catonano]

Il giorno 12 novembre 2017 11:54, Cascafico Giovanni 
ha scritto:

> Dalla wiki:
>
> Se si può considerare decorativa o con velleità artistiche,
> amenity=fountain
> drinking _water=Yes
>
> Altrimenti
> amenity=drinking_water
>

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

Re: [Talk-it] questa fontana

[Catonano]

Il giorno 12 novembre 2017 10:57, Alessandro Rubini 
ha scritto:

> > Come si mappa la fontana che compare in queste foto ?
>
> amenity=drinking_water, come tutte le fontane potabili (IMHO).
>
> > molti la usano anche come doccia da campo dopo il mare
>
> Io sudo come un cammello e uso *qualunque* fontanella come doccia
> quando pedalo. Non credo servano tag particolari per le scelte personali
> di come usare l'acqua.
>
>

e perché non invece

amenity=fountain
drinking_water=yes

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

[Talk-it] questa fontana

[Catonano]

Come si mappa la fontana che compare in queste foto ?

https://photos.app.goo.gl/HuPmu6b2RIeNP38m2

L' acqua è potabile e in estate un sacco di gente si ferma a bere, molti la
usano anche come doccia da campo dopo il mare

I tag sulle fontane mi confondono

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

[Talk-it] appartengono alla relazione ?

[Catonano]

Ho creato la prima relazione della mia vita: eccola

http://www.openstreetmap.org/relation/7725174#map=18/40.46997/17.24982

Qui una foto panoramica che dovrebbe valere più di mille parole

https://photos.google.com/share/AF1QipMprYeWDTmI0zEEdy5vHLvbv5huCArederlldjhKjwYJMEcv-3AIKJlwNIdZYhY9g/photo/AF1QipOk0eX7UY_97QbgCM4zOuvMxUGL_k1vgLIf4lM?key=OWc3YU96ZmxmdkV4WU1MeF96VmVXSUhkdzk1ZUxB

Come vedete alla relazione appartengono due grandi aree pedonali. Avevo
chiesto come mapparle qui qualche giorno fa.

Le due grandi aree contengono a loro volta alberi, cestini dei rifiuti,
lampioni, una fermata di bus suburbani

Sono delimitate da diversi cancelli e pezzi di ringhiere e muretti assortiti

Ora le domande sono: alla relazione dovrebbero appartenere anche gli
alberi, i cesini e i lampioi contenuti nelle due aree ?

Oppure il fatto che siano contenuti nelle ue aree è sufficiente ?

Spero di essermi spiegato.

La stessa domanda si applica ai cancelli che delimitano le grandi aree (due
dei quali vedete nella foto panoramica)

Devono appartenere alla relazione ? Oppure il fatto che delimitino aree che
appartengono è sufficiente ?

Comunque l' album intero è qui
https://photos.app.goo.gl/gWYpMAA5A62Xmu1Q2

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

Re: [Talk-it] un'edicola

[Catonano]

Il giorno 10 novembre 2017 10:03, Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

>
>
> sent from a phone
>
> > On 10. Nov 2017, at 08:05, Luigi Toscano 
> wrote:
> >
> > No, decisamente.
> > shop=kiosk è un "peccato originale" dei primi tempi, senza considerare
> il fatto che un chiosco può ospitare vari tipi di attività.
> >
> > Semmai:
> >
> > building=kiosk
> > shop=newsagent
>
>
>
> +1
>
>
daccordo, grazie !
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] un'edicola

[Catonano]

come si mappa un edicola ospitata in un chiosco sul marciapiede ?

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

Re: [Talk-it] Marciapiede alberato

[Catonano]

Il giorno 18 ottobre 2017 11:55, Max1234Ita  ha
scritto:

> dieterdreist wrote
> > nel caso di alberi urbani faccio un node per ogni albero (natural=tree),
> > poi ci sono questi tag per il tipo:
> > denotation=urban (alberi in un centro abitato, generico, non in filiera
> > lungo la strada)
> > denotation=avenue (in filiera lungo la strada)
> >
> > Ciao,
> > Martin
>
> Interessante il tag denotation, non lo conoscevo ancora:
> http://wiki.openstreetmap.org/wiki/Key:denotation
>
> ... e si applica anche ai tree_row! :)
>
>
> Ciao e buona giornata.
> Max
>

Grazie a tutti

Ho creato gli alberi e le due aree

Ora manca una relazione cui appartengano tutte queste cose

Mi riservo di farla presto

Nel frattempo, potete ammirare i risultati del lavoro qui ;-)
https://www.openstreetmap.org/#map=19/40.47009/17.25103
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] lampione non compare sulla mappa

[Catonano]

Il giorno 8 novembre 2017 15:18, Volker Schmidt  ha
scritto:

> Secondo
> http://wiki.openstreetmap.org/wiki/Standard_tile_layer/Key
> non dovrebbe essere renderizzato del tutto.
> Per l'illuminazione stradale c'è questa mappa (prototipo al momento):
> http://inai.de/sl/#19/40.46987/17.25077
>
>

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

Re: [Talk-it] lampione non compare sulla mappa

[Catonano]

Il giorno 8 novembre 2017 14:41, Alessandro <ale_z...@libero.it> ha scritto:

> Il 08/11/2017 14:31, Catonano ha scritto:
>
> questo lampione non compare sulla mappa
>
> https://www.openstreetmap.org/node/5217997758
>
> perché ?
>
>
> Perchè è troppo vicino ai due alberi e in quel caso il rendering ha delle
> regole che piuttosto di rendere la mappa illeggibile a causa di troppi
> simboli ravvicinati ne sacrifica alcuni.
> Altra possibilità è che il rendering non abbia ancora aggiornato
> quell'area.
>
>
No, l'ha aggiornata. Ok, li ho messi vicini perche sono vicini

Direi che va bene così

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

[Talk-it] lampione non compare sulla mappa

[Catonano]

questo lampione non compare sulla mappa

https://www.openstreetmap.org/node/5217997758

perché ?

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

[Talk-it] Marciapiede alberato

[Catonano]

Riprovo:

Come si mappa questo marciapiede alberato ?

È un'area ?

https://photos.app.goo.gl/BvrSNLYOS6Bh7ugX2
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Palermo - marciapiedi

[Catonano]

Il 07 ott 2017 2:22 PM, "Irene Saltini"  ha scritto:

Riguardo alla relazione, esistono sia street che associatedStreet, la
seconda mi pare di ricordare sia più utilizzata, ma dovrebbe includere
soltanto gli indirizzi. La prima invece può includere anche altre entità e
io personalmente l’ho usata per includere cestini dei rifiuti, parcheggi
per biciclette, etc.


Grazie Irene

Terrò presente !


Ciao,
Irene.

___
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] Palermo - marciapiedi

[Catonano]

Il giorno 15 settembre 2017 10:00, Roberto Inzerillo <
roberto.inzeri...@gmail.com> ha scritto:

> Ho appena aggiunto il tag name=* ai marciapiedi highway=footway /
> footway=sidewalk come suggerito nel wiki così da identificare i nomi delle
> strade per ogni marciapiede. Pensavo che così facendo, software di routing
> come mapzen avrebbero mostrato  esplicitamente il nome della via ...
>
> E però ho avuto un risultato inatteso e sgradito: adesso su OSM i tile
> vengono renderizzati con il nome della via su ogni marciapiede!!! Non si
> può guardare :-(
>

diciamo che non si mappa per il rendering ;-)

Il renderig di marciapiedi col nome può sempre essere corretto in seguito !

Ma comunque secondo me sevirebbe una relazione "strada" che dovrebbe
contenere la strada e tutti gli annessi. Marciapiedi, numeri civici,
slarghi, manifesti e cartelloni...

Poi non tutti i marciapiedi sono uguali. Alcuni sono larghissimi e alberati
e altri strettissimi. Una highway non tiene conto di questo, mi pare, a
meno di non scrivere la larghezza in un tag apposito (imagino il casino con
le unità di misura)

Senza usare relazioni direi che la higway mi pare la soluzione migliore,
non sono daccordo che diventa pesante in fase di editing (anche se non ho
ancora provato)
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] immagini ortorettificate

[Catonano]

2017-05-05 14:31 GMT+02:00 Alessandro Palmas :

> Ma stiamo parlando di queste?
> http://gis.19327.n8.nabble.com/Sulle-ortofoto-a-50-cm-rilasc
> iate-ieri-da-e-Geos-td5797851.html


si, di quelle


>
>
>
> CIT.: muoro :-(


perché che c'è ?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] immagini ortorettificate

[Catonano]

Graze a tuutti perr gli aggiornamenti

Il giorno 5 maggio 2017 13:19, Martin Koppenhoefer <dieterdre...@gmail.com>
ha scritto:

>
> 2017-05-05 11:48 GMT+02:00 Catonano <caton...@gmail.com>:
>
> Consiglio mapbox, bing e pcn per mappare in Italia (più gli WMS regionali
> ecc. se esistenti).
>
>

cos'è pcn ?

Quanto a mapbox e Bing, mi sembrano vecchierelle puure quelle :-/

Vabé grazie comunque

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

Re: [Talk-it] immagini ortorettificate

[Catonano]

Ok mi son ricordato

Erano quelle di RealVista

Ho un account, se è ancora valido, ma non riesco a risalire all' url del
server wms

Qualcuno lo sa ?

E poi, come inserisco le credenziali in Josm ?

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

[Talk-it] immagini ortorettificate

[Catonano]

salve,

dopo molto tempo vorrei fare qualche edit alla mappa

Ricordo che avevo trovato un servizio che forniva immagini ortorettificate
per Josm

Era richiesto di creare un account

Lo provai, era buono

Ora lo vorrei ritrovare nella mia posta ma non so con quale paroal chiave
cercarlo

Ho provato con le banali wms e tms ma non trovo nulla

Avete suggerimenti ?

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

Re: [Talk-it] Top 250 dell'Italia

[Catonano]

Il giorno 3 maggio 2017 16:13, Martin Koppenhoefer 
ha scritto:

> Ho scoperto poco fa un ottimo tool: Osmium-tool, una versione riga di
> commando per la libreria Osmium di Jochen Topf.
>
> E' veramente veloce e conveniente nell'uso (se vi piace la shell).
>
> Un esempio:
>
> osmium cat 20170302_italy.osm.pbf -f opl|cut -d' ' -f7|cut -c 2- \
>  |sort|uniq -c|sort -nr|head -n 250 >italy-top250.txt
>
>
> più informazioni qui: http://www.openstreetmap.org/
> user/dieterdreist/diary/41034
>
> il risultato di questa query (vincono gli import, ovviamente, povero
> Lucadelu si trova appena in classifica ;-) ):
>
>  129194970 mcheckimport
>  211687326 DarkSwan_Import
>  34783408 simone
>  43498422 mcheck
>  53158791 corfedeimport
>

Corfede fa un lavoro straordinario

Lo avevo visto di persona ma non avevo il polso sui dati !
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] on the field

[Catonano]

Ciao Federico :-)

Il giorno 26 novembre 2016 15:14, Federico Cortese <cortese...@gmail.com>
ha scritto:

> 2016-11-26 15:09 GMT+01:00 Catonano <caton...@gmail.com>:
> >
> > Io non ho MAI connettività. Vorrei, infatti, poter caricare la mappa sul
> > telefono PRIMA di partire e POI poter annotare punti e poligoni sulla
> mappa
> > OFFLINE
> >
> > E poi poter riversare tutto dentro a Josm quando rientro.
>
>
> Scusami non avevo capito questo limite.
> Quindi decisamente osmtracker non va bene.
> Con Vespucci puoi scaricare una porzione della mappa, quindi apportare
> tutte le modifiche e salvarle per fare l'upload in seguito.
> Certo bisogna vedere anche quanta porzione ti serve, perchè credo che
> caricare troppi dati possa appesantire l'applicazione, anche se non ho
> mai provato perchè carico piccole porzioni di mappa per volta.
> Ciao
> Federico
>

Vespucci consente ance di scattare foto e scrivere note ?

Sarebbe perfetto, nel caso
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] on the field

[Catonano]

Il giorno 26 novembre 2016 15:01, Stefano <saba...@gmail.com> ha scritto:

>
>
> Il giorno 26 novembre 2016 14:52, Catonano <caton...@gmail.com> ha
> scritto:
>
>> ma esistono soluzioni praticabili per telefoni android per raccogliere
>> dati on the field ?
>>
>> Fra Qfield, Geopaparazzi, Qgis mobile non riesco a farne funzionare manco
>> uno ! :-/
>>
>> Geopaparazzi, secondo quanto capisco da questo filmato, richiede gvSig
>> online e sulla Ultima Ubuntu non si installa. Si installa ma poi non
>> funziona.
>> https://www.youtube.com/watch?v=bPlL1dyySlE
>>
>> Da Qgis non so come fare a portare i dati in osm, posto che riesca a far
>> funzionare Qfield.
>>
>> Forse devo esportare in kmz e poi usare qualche plugin per importare in
>> Josm ?
>>
>
> Io uso Geopararazzi, mi faccio traccia e note testuali e poi esporto in
> gpx. Se scatti la foto dal bottone delle note e scarichi anche la foto Josm
> la visualizza.
>

Quando ci ho provato non mi ha importato la foto in Josm, solo i tracciati
gps. Perciò chiedevo di kmz

Devo aver sbagliato qualcosa :-/

Dal bottone delle note, dici ?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] on the field

[Catonano]

Il giorno 26 novembre 2016 14:55, Luigi Toscano 
ha scritto:

>
> Io uso osmtracker o (se ho connettività e tempo per inserimento al volo)
> vespucci. Entrambi software libero e disponibili anche su F-Droid.
>

Mi accorgo di esser stato sbrigativo.

Io non ho MAI connettività. Vorrei, infatti, poter caricare la mappa sul
telefono PRIMA di partire e POI poter annotare punti e poligoni sulla mappa
OFFLINE

E poi poter riversare tutto dentro a Josm quando rientro.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] on the field

[Catonano]

ma esistono soluzioni praticabili per telefoni android per raccogliere dati
on the field ?

Fra Qfield, Geopaparazzi, Qgis mobile non riesco a farne funzionare manco
uno ! :-/

Geopaparazzi, secondo quanto capisco da questo filmato, richiede gvSig
online e sulla Ultima Ubuntu non si installa. Si installa ma poi non
funziona.
https://www.youtube.com/watch?v=bPlL1dyySlE

Da Qgis non so come fare a portare i dati in osm, posto che riesca a far
funzionare Qfield.

Forse devo esportare in kmz e poi usare qualche plugin per importare in
Josm ?

Insomma il panorama mi sconforta :-/
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] collegamenti a Wikidata o a Wikipedia

[Catonano]

Il giorno 6 dicembre 2015 13:13, Catonano <caton...@gmail.com> ha scritto:

>
>
> 2015-12-06 11:10 GMT+01:00 Maurizio Napolitano <napoo...@gmail.com>:
>
>> intanto hai visto
>> http://wtosm.openstreetmap.ti ?
>>
>> e la pagina wiki di osm?
>> http://wiki.openstreetmap.org/wiki/Wikidata
>>
>
> Grazie !
>
> Ma quindi i tag li devo mettere entrambi ?
>
> La funzionalità di  wtosm è interessante, ma perche non la fornisce anche
> il link agli item di Wikidata ?
>

Rispondo a me stesso: si ;-)

I link a Wikidata sono una evoluzione di wtosm. Ho letto dopo ;-)


>
> Leggo che linkare gli articoli di Wikipedia non è "future proof" perché i
> titoli (e quindi gli url) possono cambiare e questa è esattamente la
> ragione di esistenza di Wikidata.
>


Quindi sul piano strettamente logico sarebbe opportuno lnkare gli item, non
> gli articoli
>
>
Wikidata è nel mezzo di un conflitto quindi può avere senso mettere
entrambi i tag



> Però linkando solo gli item si rinuncia alla funzionalità di un "web gis"
> icorporato in Wikipedia :-/
>
>
Questo non l' ho ancora capito bene. Come si fa ad avere un widget sulle
pagine di Wikipedia linkate da un oggetto in osm ?

Ho visto gli esempi ma le keyword erano tutte in tedesco e non ho capito
:-/
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] collegamenti a Wikidata o a Wikipedia

[Catonano]

Il giorno 6 dicembre 2015 12:17, Stefano <saba...@gmail.com> ha scritto:

>
>
> Il giorno 6 dicembre 2015 10:58, Catonano <caton...@gmail.com> ha scritto:
>
>> Salve,
>>
>> vorrei collegare tre oggetti sulla mappa alle rispettive pagine su
>> Wikipedia oppure ai rispettivi nodi su Wikidata
>>
>> Intanto: qual'è lo stato dell'arte ? Devo collegarli alle pagine o ai
>> nodi ?
>>
>> E poi: l'edito integrato iD (non ho provato con Josm per semplicità, mi
>> secco di aprire Josm per un semplice tag) NON offre il tag per Wikidata,
>> mentre offre quello per Wikipedia.
>>
>> Come mai ? Semplicemente non è aggiornato oppure implementa qualche
>> policy di cui non so ?
>>
>
> C'è una Pull request in attesa (
> https://github.com/openstreetmap/iD/pull/2732).
> Nel frattempo lo puoi aggiungere manualmente da 'tutti i tag'.
>
> Sulla voce wikipedia appare la geometria o il punto se c'è il tag
> wikipedia sull'oggetto.
>
> Ciao,
> Stefano
>

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

Re: [Talk-it] collegamenti a Wikidata o a Wikipedia

[Catonano]

2015-12-06 11:10 GMT+01:00 Maurizio Napolitano :

> intanto hai visto
> http://wtosm.openstreetmap.ti ?
>
> e la pagina wiki di osm?
> http://wiki.openstreetmap.org/wiki/Wikidata
>

Grazie !

Ma quindi i tag li devo mettere entrambi ?

La funzionalità di  wtosm è interessante, ma perche non la fornisce anche
il link agli item di Wikidata ?

Leggo che linkare gli articoli di Wikipedia non è "future proof" perché i
titoli (e quindi gli url) possono cambiare e questa è esattamente la
ragione di esistenza di Wikidata.

Quindi sul piano strettamente logico sarebbe opportuno lnkare gli item, non
gli articoli

Però linkando solo gli item si rinuncia alla funzionalità di un "web gis"
icorporato in Wikipedia :-/

Cosa non ho capito ?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] collegamenti a Wikidata o a Wikipedia

[Catonano]

Salve,

vorrei collegare tre oggetti sulla mappa alle rispettive pagine su
Wikipedia oppure ai rispettivi nodi su Wikidata

Intanto: qual'è lo stato dell'arte ? Devo collegarli alle pagine o ai nodi ?

E poi: l'edito integrato iD (non ho provato con Josm per semplicità, mi
secco di aprire Josm per un semplice tag) NON offre il tag per Wikidata,
mentre offre quello per Wikipedia.

Come mai ? Semplicemente non è aggiornato oppure implementa qualche policy
di cui non so ?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] non compare una fontana

[Catonano]

Perché questa fontana pur essendo presente non compare sulla mappa ?

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

[Talk-it] ID e mapillary

[Catonano]

Buongiorno,

leggo che le immagini di Mapillary diventano disponibili dentro ID, qui
http://blog.mapillary.com/update/2014/10/21/iD-and-mapillary.html

Però poi se apro ID su un luogo dove c'è una mia sequenza di fiti non la
trovo :-/

Non solo ! Il link fornito come esempio nel post del blog di Mapillary non
funziona: viene fuori un popup che dice

"Modifica non riuscita - assicurarsi che JOSM o Merkaartor sia avviato e
che l'opzione di controllo remoto sia abilitata"

e io questo messaggio d' errorenon lo capisco :-/

Cosa centrano JOSM e Merkaator ? Cos'è l' opzione di controllo remoto ?
Perché questo popup non viene fuori in altre occasioni ?

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

Re: [Talk-it] ID e mapillary

[Catonano]

Volker,

Il giorno 11 novembre 2015 12:52, Volker Schmidt  ha
scritto:

> Devi abilitare il strato photo Mapillary. Nella bara a destra o cliccando
> "F" (shortcut).
> Ma tieni presente che con ID puoi solo utilizzare le mappe Bing come
> sfondo, che, in Italia hanno problemi con allineamento alla mappa.
> Meglio utilizzare JOSM e utilizzare le ortofoto PCN2006 per
> l'allineamento. Per JOSM c'è il plugin Mapillary
>
>
Grazie !

Si, so di Josm, ma devo tenere una lezioncina veloce oggi pomeriggio e ID
mi sembrava l' opzione più immediata !

Non sapevo che le immagini di Bing avessero questo problema ! Come lo
attivo queste ortofoto PCN2006 ?

Si so del plugin di Mapillary, ne ho letto !

Grazie ancora !


> Volker
>
> 
>
>>
>>
>
> ___
> 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] Uniformiamo i beach resort ?

[Catonano]

Il giorno 23 maggio 2015 15:43, Fabrizio Carrai fabrizio.car...@gmail.com
ha scritto:

 Ok, sto inviando i messaggi. Perdonate una domanda: uno dei tag è stato
 aggiunto dall' utente mcheckimport: è un utente o un'utenza particolare ?


A quanto pare uno dei destinatari ero io ;-)

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

[Talk-it] modifiche in un azona

[Catonano]

Come faccio a vedere giorno per giorno quali modifiche vengono fatte alla
zona su cui lavoro anche io ?

Sul mio profilo vedo l'elenco di quelle che ho fatto io.

Ma vorrei vedere l'elenco di tutte quelle fatte sulla stessa zona su cui
sto lavorando io
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] senso unico

[Catonano]

Il giorno 11 maggio 2015 14:06, emmexx emm...@tiscalinet.it ha scritto:


 Non sempre, ad esempio ora non c'e'.
 Se non ricordo male la data di aggiornamento viene generata da uno script
 esterno, non dagli eseguibili che generano il grafo ed i dati per il
 routing.

 ciao
 maxx


Comunque adesso il routing è corretto. Ecco qua ;-) http://osrm.at/chG
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] senso unico

[Catonano]

Il giorno 10 maggio 2015 11:19, Daniele Forsi dfo...@gmail.com ha scritto:


 la data di aggiornamento dei dati di OSRM si vede dall'icona con
 l'ingranaggio in basso a destra: attualmente dice 150508 17:00Z e la
 modifica del senso unico è datata da 2015-05-09T22:12:14Z

 --
 Daniele Forsi


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

[Talk-it] non appare

[Catonano]

Ho aggiunto un pezzettino di strada. Una strada chiusa. L'ultimo tratto,
infatti, è un portico percorribile solo a piedi.

Ebbene la parte percorribile a piedi è pparsa nel renderimg. L'altra parte
no.

Dove ho sbagliato ?

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

[Talk-it] senso unico

[Catonano]

Un pezzettino di strada risultava essere a senso unico (oneway=yes)

L'infornazione era sbagliata, cosicché l'ho corretta settandola a oneway=no

Ma il routing continua a suggerire percorsi sbagliati perche continua a
considerare quel pezzettino a senso unico. Dove sbaglio ?

Il pezzettino in questione è questo
http://www.openstreetmap.org/way/343857115
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] senso unico

[Catonano]

Il giorno 9 maggio 2015 23:19, Francesco Pelullo f.pelu...@gmail.com ha
scritto:


 Il 09/mag/2015 22:34, Catonano caton...@gmail.com ha scritto:
 
  Un pezzettino di strada risultava essere a senso unico (oneway=yes)
 
  L'infornazione era sbagliata, cosicché l'ho corretta settandola a
 oneway=no

 Ok, ma oneway=no è considerato comunque un errore di mappatura, meglio
 usare niente (tutte le strade sono a doppio senso, tranne le eccezioni,
 quindi si usa specificare oneway=yes solo per le eccezioni).


Grazie. Ho corretto.


 
  Ma il routing continua a suggerire percorsi sbagliati perche continua a
 considerare quel pezzettino a senso unico. Dove sbaglio ?
 
  Il pezzettino in questione è questo
  http://www.openstreetmap.org/way/343857115
 
 


 Probabilmente si aggiornerà nelle prossime ore o giorni.
 Se vuoi verificare immediatamente, devi caricare un plugin di routing in
 Josm.

Sto provando il routing nella app di scrivania di Gnome (gnome-maps). E
mentre sul sito web il cambiamento risulta, il routing della app rimane
sbagliato.

Aspetterò...

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

Re: [Talk-it] senso unico

[Catonano]

Il giorno 10 maggio 2015 00:00, Damjan Gerl dam...@damjan.net ha scritto:

 09.05.2015 - 23:19 - Francesco Pelullo:

 Ok, ma oneway=no è considerato comunque un errore di mappatura, meglio
 usare niente (tutte le strade sono a doppio senso, tranne le eccezioni,
 quindi si usa specificare oneway=yes solo per le eccezioni).


 No, oneway=no è giusto. Serve a specificare che non c'è una strada a senso
 unico. Se non metti niente può significare che non sai se si tratta di
 senso unico oppure no, anche se normalmente viene considerato a doppio
 senso.

 Damjan


Fatto sta che il routing non funziona neanche con osrm. Lo considera senso
unico :-/
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] senso unico

[Catonano]

Il giorno 10 maggio 2015 00:04, Catonano caton...@gmail.com ha scritto:


 Fatto sta che il routing non funziona neanche con osrm. Lo considera senso
 unico :-/


Ecco qua http://osrm.at/cga
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] il bar all'angolo

[Catonano]

Ciao a tutti

il bar in questione è questo

https://nominatim.openstreetmap.org/details.php?place_id=27494941

io non lo avevo taggato con nessun indirizzo, ma Nominatim lo associa
correttamente a via di Palma.

Il fatto è che è ad angolo e ha una entrata anche sulla via che fa,
apputno, angolo, via Regina Elena.

Come faccio ad associarlo a entrambe le strade ?

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

[Talk-it] domanda naive

[Catonano]

C'è una piazza che era fatta male su OSM.

Avevo provato a correggerla più volte senza riuscirci. Mi ero incartato. E
avevo rinunciato

A un certo punto, d'incanto, la piazza è perfetta. Qualcuno l'ha corretta.
È venuta benissimo.

La piazza è questa
http://www.openstreetmap.org/relation/4675236#map=19/40.47123/17.24318

E l'autore della correzione sembra essere questo
http://www.openstreetmap.org/user/Molko

Guardando la lista di modifiche che ha fatto, vedo che ha editato luoghi in
tutta Italia: Pesaro, Parma, Macerata, Livorno

Come fa ? Quale processo si cela dietro questo utente ?

I dati corretti dove li prende ? Da qualche db cartografico governativo
parasegreto ?

Giusto per sapere quali sono le modifiche per le quali ha senso lottare.

Se avessi saputo che esisteva questa cosa non mi sarei cimentato con quella
piazza, ma magari con qualcos'altro

La piazza, peraltro, è solo un esempio. Ci sono almeno altri tre luoghi che
ha editato rendendoli soddisfacenti (prima erano scorretti e sconnessi)
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] numeri civici

[Catonano]

Come si mettono i numeri civici ?

Lo so che probabilmente la cosa è stata dibattuta a morte, lo vedo scritto
nei forum in mezzo mondo, ma non mi è chiaro se sia stata raggiunta una
soluzione finale.

Sono arrivato a leggere del dibattito fra il tag su un punto dell'edificio
e un punto separato dalla via e dall'edificio ma incluso in una relazione
con la strada.

La discussione si è evoluta ulteriormente ? A che punto siamo adesso ?

Lasciamo scritto ai posteri che la domanda viene posta nel novembre del 2014
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] Licenza Immagini RealVista e Agea

[Catonano]

Ciao a tutti,

a questo indirizzo c'è un esempio con due interessanti fornitori di immagini
aeree rettificate (cosiddette ortofoto)
http://tanto.github.io/50centimetri/#17/38.12017/13.35724

Le posso usare in Josm al posto di quelle di Bing ? O la licenza non lo
consente ?

Grazie



--
View this message in context: 
http://gis.19327.n5.nabble.com/Licenza-Immagini-RealVista-e-Agea-tp5822905.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Licenza Immagini RealVista e Agea

[Catonano]

Il giorno 03 novembre 2014 21:14, girarsi_liste liste.gira...@gmail.com
ha scritto:


 Il sito è di un noto utente di questa lista :)


Già ;-)



 Comunque mi pare se ne era parlato neanche tanto tempo fà,


si, scusami, sono nuovo di osm


 ad ogni
 modo, se vei sui rispettivi siti, ti rendi conto che quello a destra
 c'è già, si tratta del portale cartografico nazionale, quello a
 sinistra la licenza è qui:


 http://www.realvista.it/website/Joomla/index.php?option=com_contentview=articleid=12:realvista1-0-wms-opencatid=24Itemid=128

 E come vedi è open ma previa registrazione per potervi accedere.


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