Re: [Talk-it] SENTIERO NON PERCORRIBILE

[Sergio Manzi]

... potrebbe anche essere obstacle=landslide (frana), già usato in 4 casi (vedi 
[1])

[1] https://taginfo.openstreetmap.org/keys/?key=obstacle#values


On 2018-08-29 19:02, Sergio Manzi wrote:
>
> Secondo il wiki [1] "barrier" è un elemento artificiale (costruito 
> appositamente per limitare i movimenti) mentre "obstacle" è un elemento che 
> oggettivamente limita il passaggio e può essere di origine naturale.
>
> Quindi... direi "obstacle", ma come valore della chiave... non è prevista 
> quella giusta! Io *inventerei* "boulder" (vedi [2]), ma se non si vuole 
> essere troppo creativi, la cosa che gli si avvicina di più mi sembra essere 
> "heap", oppure anche solo "yes".
>
> Inoltre penso non farebbe male aggiungere anche una key "access" con valore 
> "no" se l'ostruzione blocca del tutto la possibilità di usufruire del 
> sentiero.
>
>
> P.S., Ciao a tutti, è il mio primo post sulla mailing-list: sono Sergio, da 
> Venezia...
>
>
> [1] 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle#Differences_with_other_keys
> [2] http://www.wordreference.com/enit/boulder
>
>
> On 2018-08-29 18:43, Roberto Brazzelli wrote:
>> Ok come proposta cosa vuol dire, si può usare?
>> Se utilizzo il tags barrier=block il render di openstretmap
>> non si modifica giusto...ma per quanto riguarda OSMand?
>>
>> Grazie mille
>>
>> Il 29/08/2018 16:44, Martin Koppenhoefer ha scritto:
>>>
>>>
>>> sent from a phone
>>>
>>> On 29. Aug 2018, at 12:13, Roberto Brazzelli >> <mailto:geom.brazze...@gmail.com>> wrote:
>>>
>>>> si presente con una grosso ostruzione nel mezzo?
>>>
>>>
>>> ci sono vari tags, forse barrier=block ? C’è anche obstacle come proposta:
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle
>>>
>>> e forse anche hazard, se ci fossero pericoli:
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
>>>
>>> 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
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] SENTIERO NON PERCORRIBILE

[Sergio Manzi]

Secondo il wiki [1] "barrier" è un elemento artificiale (costruito 
appositamente per limitare i movimenti) mentre "obstacle" è un elemento che 
oggettivamente limita il passaggio e può essere di origine naturale.

Quindi... direi "obstacle", ma come valore della chiave... non è prevista 
quella giusta! Io *inventerei* "boulder" (vedi [2]), ma se non si vuole essere 
troppo creativi, la cosa che gli si avvicina di più mi sembra essere "heap", 
oppure anche solo "yes".

Inoltre penso non farebbe male aggiungere anche una key "access" con valore 
"no" se l'ostruzione blocca del tutto la possibilità di usufruire del sentiero.


P.S., Ciao a tutti, è il mio primo post sulla mailing-list: sono Sergio, da 
Venezia...


[1] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle#Differences_with_other_keys
[2] http://www.wordreference.com/enit/boulder


On 2018-08-29 18:43, Roberto Brazzelli wrote:
> Ok come proposta cosa vuol dire, si può usare?
> Se utilizzo il tags barrier=block il render di openstretmap
> non si modifica giusto...ma per quanto riguarda OSMand?
>
> Grazie mille
>
> Il 29/08/2018 16:44, Martin Koppenhoefer ha scritto:
>>
>>
>> sent from a phone
>>
>> On 29. Aug 2018, at 12:13, Roberto Brazzelli > > wrote:
>>
>>> si presente con una grosso ostruzione nel mezzo?
>>
>>
>> ci sono vari tags, forse barrier=block ? C’è anche obstacle come proposta:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle
>>
>> e forse anche hazard, se ci fossero pericoli:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
>>
>> 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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] SENTIERO NON PERCORRIBILE

[Sergio Manzi]

Per essere ultrapreciso penso che dovresti mettere 
obstacle_description:it=Masso di tot metri. Blocca il sentiero, ma è aggirabile 
a monte (per fare un esempio)


On 2018-08-29 19:21, liste DOT girarsi AT posteo DOT eu wrote:
> Il 29/08/2018 19:12, Sergio Manzi ha scritto:
>> ... potrebbe anche essere obstacle=landslide (frana), già usato in 4 casi 
>> (vedi [1])
>>
>> [1] https://taginfo.openstreetmap.org/keys/?key=obstacle#values
>>
>
>
> onestamente seguo, ma non ci capisco nulla, perchè manca l'informazione 
> importante, di che ostacolo/impedimento si tratta? se parliamo di dettaglio.
>
> Diversamente questo ho capito, si sta cercando il modo di ovviare ad un 
> problema con un'altro problema, quello di renderizzare con qualcosa che non è 
> necessariamente quello della realtà, ma che permette al navigatore di crware 
> un routing diverso, giusto?  ;)
>
> Non si mappa per il rendering, e vabbè pazienza,ad una domanda non ho visto 
> risposta, ovvero se si può passare lo stesso, però sinceramente qualche 
> informazione e capire la situazione sarebbe più "onesto", utile per OSM non 
> per i programmi e compagnia bella.
>
>




smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] SENTIERO NON PERCORRIBILE

[Sergio Manzi]

Riguardo alle tue considerazioni riguardo la renderizzazione:

anche se sono del tutto nuovo qui mi sembra di capire che uno dei dogmi 
principali di OSM sia che con i DATI che inseriamo, tendiamo a costruire un 
MODELLO del territorio il più vicino possibile alla realtà.

Sulla base di quel modello, poi, altre applicazioni potranno provvedere alla 
rappresentazione grafica dello stesso, ma COME questo venga fatto dalle varie 
applicazioni è un problema assolutamente trascurabile (ma ovviamente ci si 
augura che le applicazioni siano ragionevoli e diano una rappresentazione 
grafica consistente con la realtà modellata)

Personalmente ADORO questo concetto, che in informatica si definisce 
"Separation of Concerns", e lo sposo al 100%!

Quello che invece non mi è chiaro, leggendo il wiki, è se questi oggetti 
"obstacle" in qualche modo blocchino o meno la "routabilità" del percorso. 
Cioè, se metto un nodo "obstacle" in coincidenza con il nodo di una way, questa 
way viene esclusa dall'insieme delle possibili way per andare dal punto A al 
punto B? Ed in caso, per quale tipo di mezzi? Un obstacle potrebbe bloccare una 
bicicletta, ma non un pedone, per esempio...


On 2018-08-29 19:32, Sergio Manzi wrote:
> Per essere ultrapreciso penso che dovresti mettere 
> obstacle_description:it=Masso di tot metri. Blocca il sentiero, ma è 
> aggirabile a monte (per fare un esempio)
>
>
> On 2018-08-29 19:21, liste DOT girarsi AT posteo DOT eu wrote:
>> Il 29/08/2018 19:12, Sergio Manzi ha scritto:
>>> ... potrebbe anche essere obstacle=landslide (frana), già usato in 4 casi 
>>> (vedi [1])
>>>
>>> [1] https://taginfo.openstreetmap.org/keys/?key=obstacle#values
>>>
>>
>> onestamente seguo, ma non ci capisco nulla, perchè manca l'informazione 
>> importante, di che ostacolo/impedimento si tratta? se parliamo di dettaglio.
>>
>> Diversamente questo ho capito, si sta cercando il modo di ovviare ad un 
>> problema con un'altro problema, quello di renderizzare con qualcosa che non 
>> è necessariamente quello della realtà, ma che permette al navigatore di 
>> crware un routing diverso, giusto?  ;)
>>
>> Non si mappa per il rendering, e vabbè pazienza,ad una domanda non ho visto 
>> risposta, ovvero se si può passare lo stesso, però sinceramente qualche 
>> informazione e capire la situazione sarebbe più "onesto", utile per OSM non 
>> per i programmi e compagnia bella.
>>
>>
>




smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Numero di corsie sbagliato

[Sergio Manzi]

Se due vetture in senso opposto non passano (/e bisogna fare qualche manovra, 
anche di solo rallentamento, per incrociarsi/), allora chiaramente non è 
lanes=2. Una fila di vetture d'altro canto può transitare, quindi lanes=1 si 
applica. Una fila di "mezze macchine" la vedo diffcile...

Precedentemente avevo detto che lanes=1 è adatto ai "sensi unici alternati" 
debitamente indicati. Mi correggo: è adatta anche ai sensi unici alternati "/di 
fatto/".

Ciao,

Sergio

On 2018-09-08 16:12, Marcello wrote:
> ... Non si passa mai con due autovetture contemporaneamente senza rallentare 
> molto e a volte ci si deve fermare e trovare uno slargo per consentire il 
> passaggio. ...
>
> Ciao
> Marcello
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Numero di corsie sbagliato

[Sergio Manzi]

Martin,

ho letto il thread che hai indicato (/alcuni post un po' velocemente quindi 
magari qualcosa mi è sfuggita.../), ma non ho visto nessuna ri-affermazione del 
prerequisito della presenza di segnaletica orizzontale a demarcare le lanes. Al 
massimo si discute di larghezze standard (americane, per lo più...) o 
addirittura di "segni di copertoni sulla strada".

Io la vedo così:

  * Esiste una segnaletica orizzontale che demarca le lanes? Se sì, ci si 
attiene a quella.
  * Se non esiste, si verificano altri parametri, legali e pratici: quanti 
veicoli (al massimo) possono procedere affiancati o incrociarsi senza 
infrangere la normativa vigente, altri generi di indicazione (/es. segnaletica 
verticale di senso unico alternato/), e senza necessariamente dovere effettuare 
manovre di facilitazione? Si mette quel numero.
  * Se non si sa, si sta "stimando ad occhio" da foto di superficie, si hanno 
dubbi sullo stato delle cose, ecc...: non si mette il numero di lanes (/ma 
certo non si mette lanes=0!/)

Sergio


On 2018-09-08 17:38, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 8. Sep 2018, at 15:48, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
>> Però dissento sul prerequisito di "marcate": il Wiki non è le tavole della 
>> legge scolpite nella pietra e, assai spesso, pecca di distorsioni (un 
>> "bias"...) di natura culturale.
>
>
> anch‘io dissento, ma quando ho cercato di cambiare la wiki non mi sembrava 
> fattibile, questo è tutto il thread:
> https://lists.openstreetmap.org/pipermail/tagging/2018-May/036484.html
>
>
> Ciao, Martin 
>
>
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Problema mailing list

[Sergio Manzi]

Eccomi qui, sono io il "colpevole" del patatrac!

In realtà non mi sento tanto colpevole: il problema è che il mio dominio usa 
una "feature" di sicurezza e anti-spam che è "allo stato dell'arte" (si chiama 
DMARC e chi è curioso può travare info su https://dmarc.org o su Wikipedia), 
mentre il software che OSM utilizza per le mailing-list non è aggiornato per 
poter interoperare con i domini che usano questa feature. Tra l'altro credo che 
le mail di Yahoo siano "a rischio" sotto questo aspetto.

Adesso e temporaneamente, ho "ucciso" il mio DMARC e spero di non creare altri 
problemi nell'immediato, ma penso che ci sia un problema reale ed attuale che 
OSM deve affrontare...

Un caro saluto a tutti e mi scuso per essere stato involontaria causa dei 
problemi.

Sergio


P.S.: per favore avvisatemi se ancora ci sono "rogne" con il mio dominio...


On 2018-09-05 20:42, Stefano wrote:
>
>
> Il giorno mer 5 set 2018 alle ore 19:31 Daniele Forsi  > ha scritto:
>
> Il giorno mer 5 set 2018 alle ore 19:11 Gabriele Sani ha scritto:
>
> > +1 ho riattivato, ma è come se fossero stati mandati troppi messaggi da 
> me (se ho interpretato bene bounces)
>
> hai interpretato male: gmail ha "rimbalzato" un messaggio quasi
> certamente perché lo ha considerato SPAM e mailman ci ha sospeso da
> talk-it
>
> il messaggio che io non ho ricevuto è questo, giudicate voi se i
> filtri di gmail hanno fatto un buon lavoro
>
> 
> https://lists.openstreetmap.org/pipermail/talk-it/2018-September/064222.html
>
>
> Si, è il "vecchio" problema di autenticazione delle email, la disiscrizione 
> di massa era successa solo una volta...
> Nulla di grave :-)
>  
>
>
>
> --
> Daniele Forsi
>
>
> Stefano
>  
>
> ___
> 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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] dataset MISE distributori

[Sergio Manzi]

Secondo me dovrebbe essere "operator = *NomeDiPersona*", lasciando il tenant ai 
soli casi in cui il proprietario dell'impianto, noto, sia diverso dall'operator.

Ma alla fine, ci interessa sapere a quele tenant l'operator paga l'affitto 
dell'impianto a fine mese?

E con la GDPR come la mettiamo? Andiamo a casa del tenant a chiedergli se gli 
va bene essere pubblicato (al 99% no...)?

Ciao,

Sergio


On 2018-09-06 19:12, LvdT wrote:
> Se facessi le cose a modo mio, taggerei semplicemente:
> brand = Eni
> tenant = *NomeDiPersona*
>
> Voi cosa fareste?
>
> Ciao,
> Irene.
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] dataset MISE distributori

[Sergio Manzi]

Martin, il "tenant" (/solo "padrone dei muri", al quale l'operator paga 
l'affitto/) può benissimo essere un privato cittadino che non ci tiene tanto a 
far sapere in giro quali siano le sue proprietà. Direi che la GDPR si applica, 
eccome!


On 2018-09-07 08:59, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 6. Sep 2018, at 20:32, Sergio Manzi  wrote:
>>
>> E con la GDPR come la mettiamo? Andiamo a casa del tenant a chiedergli se 
>> gli va bene essere pubblicato (al 99% no...)?
>
> non si applica la GDPR perché non mappiamo dati di persone private, mappiamo 
> attività commerciali/società/imprese (che possono essere anche fatte di una 
> sola persona, include i liberi professionisti). Sono dati pubblici. 
>
>
> Ciao, Martin 
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] dataset MISE distributori

[Sergio Manzi]

Ooops... hai perfettamente ragione!

Comunque mi sembra in ogni caso una informazione secondaria (/e forse pure 
quella privata/): quello che può interessare è chi "gestisce" la pompa (/o un 
qualsiasi esercizio/), per capirci quello che compare nello scontrino fiscale.


On 2018-09-07 11:32, LvdT wrote:
>> solo "padrone dei muri", al quale l'operator paga l'affitto
> Quello sarebbe landlord (locatore), tenant (locatario) è colui che opera
> fisicamente la stazione.
>
> Ciao,
> Irene.
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] dataset MISE distributori

[Sergio Manzi]

Elaborando un po' di più:

  * Dai documenti pubblici possiamo desumere chi *gestisce* l'esercizio e direi 
che non c'è dubbio che "gestore == operator".
  * Non possiamo sapere se è anche proprietario (/landlord/) della struttura, 
oppure la sta affittando (e quindi è /tenant/)
  * L'esistenza di un /tenant /implica necessariamente l'esistenza di un 
/landlord/, diverso dal /tenant/,  e può trattarsi di figura privata alla quale 
sia applica (a mio avviso) la GDPR
  * Ricordiamoci che esiste anche il concetto di /"affitto di ramo di 
impresa"/, dove comunque "appare" il locatario e non necessariamente il 
locatore.
//


On 2018-09-07 11:38, Sergio Manzi wrote:
>
> Ooops... hai perfettamente ragione!
>
> Comunque mi sembra in ogni caso una informazione secondaria (/e forse pure 
> quella privata/): quello che può interessare è chi "gestisce" la pompa (/o un 
> qualsiasi esercizio/), per capirci quello che compare nello scontrino fiscale.
>
>
> On 2018-09-07 11:32, LvdT wrote:
>>> solo "padrone dei muri", al quale l'operator paga l'affitto
>> Quello sarebbe landlord (locatore), tenant (locatario) è colui che opera
>> fisicamente la stazione.
>>
>> Ciao,
>> Irene.
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Utente veneziano che basa il lavoro su streetview

[Sergio Manzi]

Senza entrare nel merito della qualità del changeset, credo dipenda molto da 
quale tipo di informazione è stata desunta da StreetView: se l'unica 
informazione che ho desunto è il nome della via (calle, fondamenta, ecc..), 
puntando lo "sguardo" verso il "nisioetto" (/per i non veneziani, si tratta del 
riquadro di intonaco bianco sul quale vengono indicati i toponimi: 
nisiol=lenzuolo, nisioetto=piccolo lenzuolo/), mi sembra che l'operazione sia 
lecita, soprattutto se sto semplicemente controllando che la memoria o un 
appunto preso male non mi ingannino.

Non sto "copiando" o "ricalcando" dati di Google, ma sto usando uno strumento 
che Google ha messo a disposizione di tutti (/per un suo chiaro interesse.../) 
per tele-trasportarmi sul luogo e poter dare una occhiata virtuale (/siamo nel 
2018.../). Subentra poi il "mio" know-how, la mia intelligenza, la mia vista, 
ecc., ad interpretare quel che vedo e desumerne informazione. Diverso sarebbe 
il copia-incolla del nome della via da Google Maps.

Quanto sopra è una mia personalissima opinione e mi rendo conto che è in 
contrasto con quanto indicato nel wiki [1], dove si cita esplicitamente anche 
Google StreetView

Ciao,

Sergio

[1] 
https://wiki.openstreetmap.org/wiki/Legal_FAQ#2a._Can_I_trace_data_from_Google_Maps.2FNokia_Maps.2F3F


On 2018-08-31 13:58, Martin Koppenhoefer wrote:
> Nel contesto di una discussione su un changeset, ho incontrato un utente che 
> dice di basare il lavoro su Google StreetView.
>
> https://www.openstreetmap.org/changeset/50453873
>
> Come si procede? Non credo tutto il suo lavoro sia stato basato su 
> streetview, per esempio il changeset che non mi piaceva era un edit 
> automatico che trasformava alcuni footway a Venezia in pedestrian.
>
> Ciao,
> Martin
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Utente veneziano che basa il lavoro su streetview

[Sergio Manzi]

P.S. e N.B.: mi sono volontariamente limitato a parlare del dato "toponimo", 
perché si tratta di un dato particolarmente stabile: come contro-esempio, non 
accetterei informazioni sul nome di un ristorante o di una pompa di benzina 
(/visto che se ne parla in questi giorni.../), basandomi su quanto posso vedere 
in StreetView.


On 2018-08-31 14:58, Sergio Manzi wrote:
>
> Senza entrare nel merito della qualità del changeset, credo dipenda molto da 
> quale tipo di informazione è stata desunta da StreetView: se l'unica 
> informazione che ho desunto è il nome della via (calle, fondamenta, ecc..), 
> puntando lo "sguardo" verso il "nisioetto" (/per i non veneziani, si tratta 
> del riquadro di intonaco bianco sul quale vengono indicati i toponimi: 
> nisiol=lenzuolo, nisioetto=piccolo lenzuolo/), mi sembra che l'operazione sia 
> lecita, soprattutto se sto semplicemente controllando che la memoria o un 
> appunto preso male non mi ingannino.
>
> Non sto "copiando" o "ricalcando" dati di Google, ma sto usando uno strumento 
> che Google ha messo a disposizione di tutti (/per un suo chiaro 
> interesse.../) per tele-trasportarmi sul luogo e poter dare una occhiata 
> virtuale (/siamo nel 2018.../). Subentra poi il "mio" know-how, la mia 
> intelligenza, la mia vista, ecc., ad interpretare quel che vedo e desumerne 
> informazione. Diverso sarebbe il copia-incolla del nome della via da Google 
> Maps.
>
> Quanto sopra è una mia personalissima opinione e mi rendo conto che è in 
> contrasto con quanto indicato nel wiki [1], dove si cita esplicitamente anche 
> Google StreetView
>
> Ciao,
>
> Sergio
>
> [1] 
> https://wiki.openstreetmap.org/wiki/Legal_FAQ#2a._Can_I_trace_data_from_Google_Maps.2FNokia_Maps.2F3F
>
>
> On 2018-08-31 13:58, Martin Koppenhoefer wrote:
>> Nel contesto di una discussione su un changeset, ho incontrato un utente che 
>> dice di basare il lavoro su Google StreetView.
>>
>> https://www.openstreetmap.org/changeset/50453873
>>
>> Come si procede? Non credo tutto il suo lavoro sia stato basato su 
>> streetview, per esempio il changeset che non mi piaceva era un edit 
>> automatico che trasformava alcuni footway a Venezia in pedestrian.
>>
>> Ciao,
>> Martin
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] dataset MISE distributori

[Sergio Manzi]

+1 ! :-)


On 2018-09-07 19:23, Martin Koppenhoefer wrote:
>
>
> 2018-09-07 11:53 GMT+02:00 Sergio Manzi mailto:s...@smz.it>>:
>
> Elaborando un po' di più:
>
>   * Dai documenti pubblici possiamo desumere chi *gestisce* l'esercizio e 
> direi che non c'è dubbio che "gestore == operator".
>   * Non possiamo sapere se è anche proprietario (/landlord/) della 
> struttura, oppure la sta affittando (e quindi è /tenant/)
>   * L'esistenza di un /tenant /implica necessariamente l'esistenza di un 
> /landlord/, diverso dal /tenant/,  e può trattarsi di figura privata alla 
> quale sia applica (a mio avviso) la GDPR
>   * Ricordiamoci che esiste anche il concetto di /"affitto di ramo di 
> impresa"/, dove comunque "appare" il locatario e non necessariamente il 
> locatore.
>
>
> noi di questo mappiamo soltanto "operator" (la società (anche unipersonale) 
> di chi gestice), gli altri dati potrebbero anche essere protetti dalla legge 
> della privacy (nel caso che siano persone fisiche). Operator è quello che si 
> legge sullo scontrino / timbro.
>
> Ciao,
> Martin
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Numero di corsie sbagliato

[Sergio Manzi]

Vabbé, mi sono dimenticato il link...

[1] https://it.wikipedia.org/wiki/Corsia_di_marcia


On 2018-09-07 23:21, Sergio Manzi wrote:
>
> Per il poco che potrà valere, sono totalmente d'accordo con l'interpretazione 
> che Martin da di /lanes/
>
> In realtà anche Wikipedia [1] Italiana sembra essere d'accordo:
>
> /La corsia di marcia è una parte della carreggiata o della strada (e in 
> particolare delle superstrade e delle autostrade) *dimensionata* in modo tale 
> da consentire lo scorrimento di una fila di veicoli in viaggio./
>
> Attenzione, dice "dimensionata", non "disegnata", e parla di "fila" (/quindi 
> traffico in una certa unica direzione/): c'è spazio per due file? 2 lanes!
>
> Attenzione (/forse.../) anche al "/false friend/" linguistico in Inglese: 
> /designated/ non è "disegnato", ma "riservato", "predisposto", 
> "d*e*s*i*gnato".
>
> On 2018-09-07 23:06, Martin Koppenhoefer wrote:
>>
>>
>> sent from a phone
>>
>> On 7. Sep 2018, at 21:44, Davide Sandona' > <mailto:sandona.dav...@gmail.com>> wrote:
>>
>>> Io sono uno dei mappatori che ha utilizzato il tag lanes=1, che secondo 
>>> alcuni sembra essere il male
>>
>>
>> lanes=1 va bene per strade dove c’è una corsia di marcia insieme, per tutti 
>> i sensi di marcia, in altre parole, 2 macchine non passano.
>>
>> https://dennisschatz.files.wordpress.com/2011/02/single-lane-road.jpg
>>
>>
>> Ciao, Martin 
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Numero di corsie sbagliato

[Sergio Manzi]

Per il poco che potrà valere, sono totalmente d'accordo con l'interpretazione 
che Martin da di /lanes/

In realtà anche Wikipedia [1] Italiana sembra essere d'accordo:

/La corsia di marcia è una parte della carreggiata o della strada (e in 
particolare delle superstrade e delle autostrade) *dimensionata* in modo tale 
da consentire lo scorrimento di una fila di veicoli in viaggio./

Attenzione, dice "dimensionata", non "disegnata", e parla di "fila" (/quindi 
traffico in una certa unica direzione/): c'è spazio per due file? 2 lanes!

Attenzione (/forse.../) anche al "/false friend/" linguistico in Inglese: 
/designated/ non è "disegnato", ma "riservato", "predisposto", "d*e*s*i*gnato".

On 2018-09-07 23:06, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 7. Sep 2018, at 21:44, Davide Sandona'  > wrote:
>
>> Io sono uno dei mappatori che ha utilizzato il tag lanes=1, che secondo 
>> alcuni sembra essere il male
>
>
> lanes=1 va bene per strade dove c’è una corsia di marcia insieme, per tutti i 
> sensi di marcia, in altre parole, 2 macchine non passano.
>
> https://dennisschatz.files.wordpress.com/2011/02/single-lane-road.jpg
>
>
> Ciao, Martin 
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Numero di corsie sbagliato

[Sergio Manzi]

Martin,

forse mi sono un po' rimbambito, ma mi sembra che queste tue due affermazioni 
(/vedi sotto.../) non vadano d'accordo l'una con l'altra...

Mi chiedo anche come faccia ad essere marcata *una* corsia per i due sensi di 
marcia: intendi quando sono segnalati i limiti della carreggiata, ma non la 
divisione centrale? Io credo che, in caso di traffico bi-direzionale, lanes=1 
sia valido solo nel caso in cui esista un senso unico alternato, identificato 
da apposita segnaletica.

In ogni caso trovo sbagliato, sempre, per definizione, lanes=0: semanticamente 
"lanes=0" vuol dire che "non ci sono corsie", quindi non mi stupirei se qualche 
algoritmo di routing interpretasse la cosa in modo da non instradare il 
traffico su una siffatta /highway.

/Sono anche (decisamente) contrario alle lanes frazionarie: o la lane c'è (e 
conti +1), o la lane non c'è (e quindi non la conti)/.

/Ripeto anche che sono favorevole ad un approccio "pratico" all'interpretazione 
di lane: c'è una lane quando c'è uno spazio riservato ad una "fila di 
traffico", così come definito anche in Wikipedia.
//
Sergio

On 2018-09-08 10:12, Martin Koppenhoefer wrote:
> no, lanes=0 quando non sono marcate corsie.
> lanes=1 è quando è marcata una corsia.
> Il wiki suggerisce di mappare solo width in quel caso, senza lanes.

On 2018-09-07 23:06, Martin Koppenhoefer wrote:
> lanes=1 va bene per strade dove c’è una corsia di marcia insieme, per tutti i 
> sensi di marcia, in altre parole, 2 macchine non passano.
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Numero di corsie sbagliato

[Sergio Manzi]

Errata corrige, nell'ultimo paragrafo: riservato -> disponibile


On 2018-09-08 14:43, Sergio Manzi wrote:
>
> Martin,
>
> forse mi sono un po' rimbambito, ma mi sembra che queste tue due affermazioni 
> (/vedi sotto.../) non vadano d'accordo l'una con l'altra...
>
> Mi chiedo anche come faccia ad essere marcata *una* corsia per i due sensi di 
> marcia: intendi quando sono segnalati i limiti della carreggiata, ma non la 
> divisione centrale? Io credo che, in caso di traffico bi-direzionale, lanes=1 
> sia valido solo nel caso in cui esista un senso unico alternato, identificato 
> da apposita segnaletica.
>
> In ogni caso trovo sbagliato, sempre, per definizione, lanes=0: 
> semanticamente "lanes=0" vuol dire che "non ci sono corsie", quindi non mi 
> stupirei se qualche algoritmo di routing interpretasse la cosa in modo da non 
> instradare il traffico su una siffatta /highway.
>
> /Sono anche (decisamente) contrario alle lanes frazionarie: o la lane c'è (e 
> conti +1), o la lane non c'è (e quindi non la conti)/.
>
> /Ripeto anche che sono favorevole ad un approccio "pratico" 
> all'interpretazione di lane: c'è una lane quando c'è uno spazio riservato ad 
> una "fila di traffico", così come definito anche in Wikipedia.
>
> Sergio
>
> On 2018-09-08 10:12, Martin Koppenhoefer wrote:
>> no, lanes=0 quando non sono marcate corsie.
>> lanes=1 è quando è marcata una corsia.
>> Il wiki suggerisce di mappare solo width in quel caso, senza lanes.
>
> On 2018-09-07 23:06, Martin Koppenhoefer wrote:
>> lanes=1 va bene per strade dove c’è una corsia di marcia insieme, per tutti 
>> i sensi di marcia, in altre parole, 2 macchine non passano.
>>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Numero di corsie sbagliato

[Sergio Manzi]

Vedo che ora dai un'altra interpretazione di lanes=0 (/è arrivata mentre 
spedivo il messaggio precedente../.).

Dissento anche su questa: per traffico limitato a moto, bici, pedoni, birrocci, 
cavalli, ecc... ci sono apposite tag. In quel contesto il numero di lanes deve 
essere ovviamente interpretato per la particolare tipologia di mezzo di 
trasporto permesso.


On 2018-09-08 14:42, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 8. Sep 2018, at 12:54, Marcello  wrote:
>>
>> Leggo le mail dal digest quindi non avevo ancora visto la tua
>> indicazione di lanes=0 quando non sono marcate, può essere utile per far
>> capire che in quel momento non ci sono linee tracciate,
>
> intendevo lasciare libero lanes. Lanes=0 era pensato così. Io vedo i lanes 
> come sono effettivamente, anche in assenza di marcature, guardando il 
> traffico reale delle macchine (moto e bici non contano).
> Quindi lanes=0 non ha molto senso per le strade, perché sarebbe troppo 
> stretto per una macchina, e quindi sarebbe un altro highway (path, footway, 
> etc.), forse per i service stretti (centri storici, service=alley, dove si va 
> con la moto ma la macchina non passa) avrebbe senso.
>
> Ciao, Martin 
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Numero di corsie sbagliato

[Sergio Manzi]

BANG! Mi suicido... "cuesto" non è accettabile! Scusate!!!


On 2018-09-08 15:48, Sergio Manzi wrote:
>
> OK, chiaro, no problem!
>
> Però dissento sul prerequisito di "marcate": il Wiki non è le tavole della 
> legge scolpite nella pietra e, assai spesso, pecca di distorsioni (un 
> "bias"...) di natura culturale.
>
> Volker stesso (/che ha scritto un altro post mentre sto rispondendo.../) cita 
> il caso delle strade Inglesi dove dove la segnaletica orrizzontale e assente. 
> Ma cuesto non "cancella" la reale concreta, usufruibile, esistenza delle 
> "lanes".
>
> Se serve, correggiamo il Wiki, portando la discussione a livello 
> internazionale (mi sembra corretto...)
>
> Sergio
>
> On 2018-09-08 15:40, Martin Koppenhoefer wrote:
>> sent from a phone
>>
>>> On 8. Sep 2018, at 14:43, Sergio Manzi  wrote:
>>>
>>> In ogni caso trovo sbagliato, sempre, per definizione, lanes=0:
>> si, anch’io non l’avevo mai messo e mai visto, ho visto solo ora che ci 
>> stanno 800+ di questi tags nel db. Per me potrebbero avere un certo senso, 
>> cfr. altra mail, ma quando avevo scritto per la prima volta lanes=0 qui, la 
>> mia intenzione era di dire non mettere il tag, scusa per la confusione che 
>> si è creata.
>>
>>
>>
>>> semanticamente "lanes=0" vuol dire che "non ci sono corsie...",
>> ...sufficientemente larghe e per traffico motorizzato, e marcate (requisiti 
>> dal wiki).
>>
>>
>> Ciao, Martin 
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Numero di corsie sbagliato

[Sergio Manzi]

OK, chiaro, no problem!

Però dissento sul prerequisito di "marcate": il Wiki non è le tavole della 
legge scolpite nella pietra e, assai spesso, pecca di distorsioni (un 
"bias"...) di natura culturale.

Volker stesso (/che ha scritto un altro post mentre sto rispondendo.../) cita 
il caso delle strade Inglesi dove dove la segnaletica orrizzontale e assente. 
Ma cuesto non "cancella" la reale concreta, usufruibile, esistenza delle 
"lanes".

Se serve, correggiamo il Wiki, portando la discussione a livello internazionale 
(mi sembra corretto...)

Sergio

On 2018-09-08 15:40, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 8. Sep 2018, at 14:43, Sergio Manzi  wrote:
>>
>> In ogni caso trovo sbagliato, sempre, per definizione, lanes=0:
>
> si, anch’io non l’avevo mai messo e mai visto, ho visto solo ora che ci 
> stanno 800+ di questi tags nel db. Per me potrebbero avere un certo senso, 
> cfr. altra mail, ma quando avevo scritto per la prima volta lanes=0 qui, la 
> mia intenzione era di dire non mettere il tag, scusa per la confusione che si 
> è creata.
>
>
>
>> semanticamente "lanes=0" vuol dire che "non ci sono corsie...",
>
> ...sufficientemente larghe e per traffico motorizzato, e marcate (requisiti 
> dal wiki).
>
>
> Ciao, Martin 
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Numero di corsie sbagliato

[Sergio Manzi]

Io ne vedo 2... quindi metterei 2.


On 2018-09-08 15:48, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 8. Sep 2018, at 14:43, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
>> Sono anche (decisamente) contrario alle lanes frazionarie: o la lane c'è (e 
>> conti +1), o la lane non c'è (e quindi non la conti)/./
>
>
> ci sono delle situazioni strane però, con una lane segnata ma due effettive, 
> esempio:
>
> https://www.google.com/maps/@41.3645922,13.0488137,0a,75y,310.91h,90.02t/data=!3m4!1e1!3m2!1sF1FciA5j5VvCdOImBWPj4A!2e0
>  
> <https://www.google.com/maps/@41.3645922,13.0488137,0a,75y,310.91h,90.02t/data=%213m4%211e1%213m2%211sF1FciA5j5VvCdOImBWPj4A%212e0>
>
> https://www.google.com/maps/@41.33993,13.0779026,0a,75y,322.62h,89.88t/data=!3m4!1e1!3m2!1scTijyoXU-WUDSQQXo0dnIg!2e0
>  
> <https://www.google.com/maps/@41.33993,13.0779026,0a,75y,322.62h,89.88t/data=%213m4%211e1%213m2%211scTijyoXU-WUDSQQXo0dnIg%212e0>
>
> ecc.
>
>
> Ciao, Martin 
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Violazione licenza - Rally Alpi Orientali

[Sergio Manzi]

On 2018-09-05 14:04, Maurizio Napolitano wrote:
> cominciare a fare spam su twitter con i loro hashtag

Mi auguro che tu stia scherzando... vero?



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Utente veneziano che basa il lavoro su streetview

[Sergio Manzi]

Esatto, non c'entra nulla: si tratterebbe solo di aver introdotto in OSM un 
errore causato dall'uso di informazione obsoleta. La stessa cosa sarebbe potuta 
accadere (/lecitamente secondo il parere di tutti, mi sembra di capire.../) 
avendo usato come fonte una foto di Mapillary.

Ma dirò di più: il mapper più scrupoloso del mondo (/ma un po' sfortunato.../) 
avrebbe potuto fare una ricognizione sul campo, avere usato l'informazione 
desunta da quel che ha visto lui, di persona, e, allontanandosi, avrebbe potuto 
incrociare la squadra di addetti che, scala sulle spalle e bidone di vernice in 
mano, si stava recando sul luogo per aggiornare il nome della calle in base ad 
una recente delibera comunale.

Il tema non è la qualità dell'informazione desunta da SV, ma se sia lecito o 
meno desumere quel tipo di informazione dalla "vista virtuale".

A meno che si pensi che Google, per somma cattiveria, non si impegni a 
photoshoppare le immagini introducendo falsa informazione per poter poi 
"incastrare" noi, "il nemico".

Ciao!

P.S., a scanso di equivoci: *non *sono io il famigerato "/armchair mapper/" e 
*non *ho mai usato SV come mia fonte.


On 2018-09-02 12:31, Volker Schmidt wrote:
> Ma questi esempi sembrano essere casi dove nomi sono stati cambiati 
> dall'amministrazione e tu confronti foto scattate a date diverse.
> Non c'entrano con la questione se SV è una fonte legale per OSM (non lo è 
> secondo me). Riguardano solo la probabilità di essere beccati copiando da SV 
> (nel raro caso di cambiamento nomi),
>
> 2018-09-02 11:17 GMT+02:00 Gianni Mistron  >:
>
>
> Venezia, tre esempi di toponimi discordanti tra SView e fotografie 
> scattate sul luogo (a sinistra la foto, a destra screenshot Sview)
>
> https://drive.google.com/open?id=1XOkSi8FVIQotgf8VMUF7Afz-scfOUWEl 
> 
> https://drive.google.com/open?id=1Vah4c7Yf13jKG1JnogWTbBOXMUzadtp5 
> 
> https://drive.google.com/open?id=10hItiPhjgDOeozQrpstzbH5lG-yAOcfH 
> 
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Numero di corsie sbagliato

[Sergio Manzi]

_CREDO_ che il processo formale dovrebbe passare attraverso una 
proposta+votazione sul Wiki... sbaglio?


On 2018-09-11 11:18, cascafico wrote:
> C'è un servizio che stabilisce quando il consenso è stato raggiunto? Ciò
> ovviamente riguarda anche l'import dei distributori.
>
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] ancora tabaccaio

[Sergio Manzi]

+1000!

Voi, come diavolo taggate la buona vecchia salumeria? Io, per l'unica che ho 
mappato, ho messo shop:deli, ma non mi convince PROPRIO PER NIENTE...


On 2018-09-11 11:10, LvdT wrote:
> Penso che il problema sia più che altro che i tag sono basati sulle
> tipologie di attività che si trovano nel mondo anglosassone, che non sempre
> sono in corrispondenza 1-a-1 con quelli italiani.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] ancora tabaccaio

[Sergio Manzi]

Accipicchia, la tag "sells" rischia di essere un vaso di Pandora! OSM dovrà 
comprare altro storage per il DB...  :-)


On 2018-09-11 10:59, Martin Koppenhoefer wrote:
>
>
> 2018-09-11 10:55 GMT+02:00 griphon  >:
>
> Secondo me va messa l'etichetta relativa alla funzione principale del
> negozio: un tabaccaio anche se offre una marea di servizi aggiuntivi è
> sempre un tabaccaio.
> Per fare un esempio a Fano ho trovato un negozio della famosa catena di
> profumerie (Acqua e Sapone) che vendevano anche vari tipi di pile, pero'
> resta sempre una profumeria, non ha senso aggiungerci anche l'elettronica 
> di
> consumo.
>
>
>
> sells:batteries=yes
>
>
> e poi per gli acribisci
> sells:batteries:aa=yes
> sells:batteries:aaa=yes
> sells:batteries:c=no
> sells:batteries:d=no
> sells:batteries:LR234=yes
> ...
> ;-)
>
>
> Ciao,
> Martin
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] ancora tabaccaio

[Sergio Manzi]

... per me sempre tabaccaio resta, perché ti assicuro che quando finisco le 
sigarette non ho nessuna voglia di smazzarmi tutti i kiosk in cerca di uno che 
le venda!  :-)

Per la cronaca, quello sotto casa mia vende anche: giocattolli, borse, scarpe e 
vestiti (da donna).

Inoltre penso che siano (più o meno tutti...) iscritti alla FIT, Federazione 
Italiana *Tabaccai*

Ciao,

Sergio


On 2018-09-11 08:00, claudio62PG wrote:
> Per quello che vedo non esistono più i tabaccai 
> shop=tobacco
> ma esistono dei negozi multiservice che sono anche tabaccai
> shop=kiosk
> ieri ne ho trovato uno che offriva i seguenti servizi
> Bollettini Postali
> Marche da bollo
> Canone rai
> Bollo Auto
> voucher inps
> cartelle equitalia
> ricariche telefoniche
> ricariche postpay
> Fax
> Fotocopie
> Biglietti autobus
> Tabacchi
> Lotto
> (per fortuna niente gionali e caffè)
> come taggare situazioni del genere?
>
>
> Ciao Claudio
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] ancora tabaccaio

[Sergio Manzi]

Ottima idea! Ne parleremo... (scusate, io vado off-line fino a questa sera...)

Ciao a tutti,

Sergio


On 2018-09-11 11:26, Martin Koppenhoefer wrote:
> infatti, dovremmo proporre noi i shops che non ci sono ancora. 
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Canale per centrale idroelettrica

[Sergio Manzi]

Visto così, a cielo aperto e di portata sicuramente ridotta (/e per quel 
//_poco_//che ne so!/) mi sembra strano che possa alimentare una centrale 
idroelettrica: penso più ad un canale di irrigazione o ad uno scolmatore... ci 
mandi le coordinate?

Ciao,

Sergio


On 2018-10-12 19:24, demon.box wrote:
> ciao, se ho un canale che scorre appena sopra il livello del terreno ed
> alimenta una centrale idroelettrica fatto così:
>
>  
>
>  
>
> parte scoperta:
>
> waterway=canal
> usage=headrace
>
> parte scoperta?
>
> waterway=canal
> usage=headrace
> covered=yes
>
> oppure cos'altro?
> grazie
>
> --enrico
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Canale per centrale idroelettrica

[Sergio Manzi]

"/ditch/" è propriamente un fosso e "/drain/" uno scolmatore.

Il canale che alimenta la caduta d'acqua in condotta forzata (/penstock/), in 
Inglese si chiama "/culvert/" quando è in galleria e "/race/" quando è a cielo 
aperto.

Nel wiki la "race" la vedo citata come "headrace" (/ci sta.../), sia qui [1] 
che qui [2], dove ci sono anche esempi fotografici.

Sempre secondo il wiki [3] sembra che sia meglio usare tunnell=flooded invece 
di tunnel=culvert, soprattutto quando si tratta di lunghe tratte

[1] https://wiki.openstreetmap.org/wiki/Waterways
[2] https://wiki.openstreetmap.org/wiki/Tag%3Ausage%3Dheadrace
[3] https://wiki.openstreetmap.org/wiki/Tag:tunnel%3Dculvert


On 2018-10-12 21:10, Alfredo Gattai wrote:
> Al di la dello scopo, secondo me e' piu' adatto waterway=drain oppure 
> waterway=ditch se piu' piccolo. Per la parte coperta e vedere qualche esempio 
> fai qualche query in valle d'Aosta,  ce ne sono molti antichi e che qualcuno 
> comincia a restaurare.
>
> Il Ven 12 Ott 2018, 20:52 demon.box  <mailto:e.rossin...@alice.it>> ha scritto:
>
> Sergio Manzi wrote
> > Visto così, a cielo aperto e di portata sicuramente ridotta (/e per quel
> > //_poco_//che ne so!/) mi sembra strano che possa alimentare una 
> centrale
> > idroelettrica: penso più ad un canale di irrigazione o ad uno
> > scolmatore...
>
> ciao, guarda ne sono sicuro al 101% perchè l'ho ispezionato di persona.
> in pratica quello che vedi nelle foto è un tratto di canale diciamo "in
> piano" che esce da un bacino di accumulo.
> alla fine di questo tratto di canale c'è il classico tubo 
> (man_made=pipeline
> + usage=penstock) che scende in picchiata fino a raggiungere il fondovalle
> dove c'è la centrale idroelettrica.
>
> ma tornando alla mia domanda: come faccio a taggare il tratto coperto
> peraltro appena al di sopra del livello del terreno?
>
> forse
>
> waterway=canal
> tunnel=culvert ?
>
> grazie
>
> --enrico
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org <mailto: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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Canale per centrale idroelettrica

[Sergio Manzi]

Mah... a me sembra che il wiki [1] sia abbastanza chiaro su quali siano i casi 
in cui, per le waterway "man made"  vanno usati "canal" (cielo aperto, acqua 
"utile"), "ditch" (cielo aperto, acqua "superflua", scavo in terra) o "drain" 
(cielo aperto, acqua "superflua", scavo "foderato"), insieme a millanta altri 
casi: non mi sembra corretto usare ditch/drain come casi "acchiappatutto", se è 
questo quello che intendevi dire...

Ciao!!

[1] https://wiki.openstreetmap.org/wiki/Key:waterway


On 2018-10-13 15:16, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 12. Oct 2018, at 21:50, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
>> "/ditch/" è propriamente un fosso e "/drain/" uno scolmatore.
>
>
> si, letteralmente si, ma se uno applica queste definizioni strettamente non 
> ci sarebbero più tags per gli altri tipi di waterway artificiali.
>
> Ciao, Martin 
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] fontane e amenity=fountain

[Sergio Manzi]

+1

Senza dubbio historic=yes mi sembra un po' "/over-the-top/" per un oggetto che 
riporta la data del 2008!  :-)

In realtà io avrei il dubbio se indicarli come amenity=watering_place + 
drinking_water=yes/conditional/untreated ...



On 2018-10-14 12:21, Andrea Musuruane wrote:
>
> A me sembrano dei semplici amenity=drinking_water. Non vedo alcuna funzione 
> tra quelle elencate nel wiki (/A fountain for cultural / decorational / 
> recreational purposes/) perché siano caratterizzate come  amenity=fountain.
>
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfountain
>
> Ciao,
>
> Andrea
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] fontane e amenity=fountain

[Sergio Manzi]

Scusate, ma insisto che per gli "oggetti in oggetto", amenity=fountain, proprio 
non ci sta, e cercherò di spiegarmi.

Intanto partiamo dalla parola inglese "fountain" (/volenti o nolenti, le tag 
sono in inglese.../):

Fountain in inglese è "qualcosa da cui scorre un liquido": anche la penna 
stilografica è una "fountain", o una sorgente è pure una "fountain".

Quindi non sarebbe errato *chiamare  *(n.b., non *taggare*...) "fountain" gli 
oggetti di cui trattiamo.

Altrettanto giusto sarebbe chiamare "fountain" tutte le fontanelle che 
forniscono acqua potabile nelle città, ma la stragrante maggioranza di esse è 
(/a mio avviso giustamente/) taggata come amenity=drinking_water, anche se 
hanno una loro dignità decorativa ed artistica (/e mi permetto di dire spesso 
decisamente superiore a quella degli oggetti ai quali ci riferiamo, pur 
ammettendo che il criterio di giudizio è totalmente soggettivo/). I "Toret" 
Torinesi mi sembrano una assoluta eccezione e non capisco perché debbano avere 
maggiore dignità rispetto, per esempio, alle altrettanto nobili fontanelle 
veneziane (taggate amenity=drinking_water).

*Ma*... "fountain" è anche la "fontana monumentale", con scopo prettamente 
decorativo e la cui acqua è tipicamente non potabile ed è esattamente in questa 
accezione che il wiki definisce le "fountain": ragazzi, basta leggere e dare 
un'occhiata agli esempi fotografici in 
https://wiki.openstreetmap.org/wiki/Tag:amenity=fountain?uselang=en-US per 
capire a che cosa ci si riferisce...

Martin, se dici che "il wiki non conta e/o spesso 'sbaglia'", scusa ma siamo 
belli che fregati: tutto diventa opinabile/soggettivo e le mappe diventano una 
babele: o ci si attiene al wiki o si cambia il wiki. Non vedo alternativa.

Vi prego anche di notare le icone con cui amenity=fountain e 
amenity=drinking_water vengono rese sulle mappe: quale assomiglia di più agli 
oggetti di cui stiamo discutendo?

Inoltre mi risulta (/l'ho visto, un po' di tempo fa,  ma adesso non riesco a 
ritrovarlo.../) che ci sia un bel sito che, partendo dai dati OSM,  mappa le 
fonti di acqua potabile e ho  il serio sospetto che si limiti 
(/ragionevolmente.../) a mappare le maneity=drinking_water.

Ciao,

Sergio


P.S.: Andrea Albani, scusa, prima, per sbaglio, avevo risposto solo a te e non 
alla lista, per cui riceverai un "doppione"...


On 2018-10-16 12:15, Andrea Albani wrote:
>
>
> Il giorno mar 16 ott 2018 alle ore 11:44 Martin Koppenhoefer 
> mailto:dieterdre...@gmail.com>> ha scritto:
>
>
> se cerchi da bere la becchi anche come amenity=fountain per il 
> drinking_water=yes
>
>
> Il filo logico del mio discorso non lo escludeva
>
> Se vorresti fare il censimento di tutte le fontane del comune, questa te 
> la aspetteresti o no?
>
>
> Mi sono già espresso per il no perchè in questo casi prediligo il solo ruolo 
> funzionale, ma essendo una situazione borderline non mi scandalizzerei che 
> altri possano dire si
>
> Per un censimento a regola d'arte però prima penserei ai criteri per 
> classificare cos'è una fontana. Ma su quali linee guida ? artistiche, 
> storiche, funzionali,... ? Le stesse domande che ci facciamo qua in ML e a 
> cui spesso si fa fatica a dare risposta perchè si entra nella zona 
> dell'opinabile.
>
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] tracciamo il futuro di OpenStreetMap in Italia?

[Sergio Manzi]

Così, d'acchito, mi vengono in mente alcuni criteri (che potranno ovviamente 
essere estesi o rigettati):

  * fornitura di dati
  * partecipazione con uno o più delegati alle attività OSM
  * sottoscrizione di un "protocollo di intesa di collaborazione" con OSM
  * patrocini
  * contributi economici
  * pubblicità alle attività/sito OSM


On 2018-10-16 15:50, Andrea Musuruane wrote:
> Ciao,
>
> On Tue, Oct 16, 2018 at 2:53 PM Sergio Manzi  <mailto:s...@smz.it>> wrote:
>
> L'ipotesi di stilare una "graduatoria" dei comuni/enti più virtuosi non 
> mi trova d'accordo: troppe variabili in gioco, tra le quali, non 
> trascurabile, quella delle realzioni personali tra l'ente e le "persone" che 
> contribuiscono a OSM e il loro realtivo "peso" all'interno della comunità.
>
> La risposta di Andrea mi sembra giustificatissima: lui sa cosa ha fatto 
> Biella (/io onestamente non ne ho la più pallida idea.../), altri sanno cosa 
> hanno fatto Bologna, Milano, Trento, ecc..: giudicare quale sia l'ente più 
> virtuoso mi sembra difficile ed estremamente opinabile.
>
> Direi invece che si potrebbero _stabilire dei criteri oggettivi_ (/poi se 
> ne potrà discutere.../) per assegnare agli enti pubblici una "patente" di 
> contributore, che potrebbe essere anche suddivisa in varie "classi" 
> (/Platino, Oro, Argento, tanto per dire.../).
>
> Che ve ne pare?
>
> Mi sembra una buona idea riuscire a stabilire dei criteri per identificare 
> gli enti virtuosi.
>
> Ciao,
>
> Andrea
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] tracciamo il futuro di OpenStreetMap in Italia?

[Sergio Manzi]

L'ipotesi di stilare una "graduatoria" dei comuni/enti più virtuosi non mi 
trova d'accordo: troppe variabili in gioco, tra le quali, non trascurabile, 
quella delle realzioni personali tra l'ente e le "persone" che contribuiscono a 
OSM e il loro realtivo "peso" all'interno della comunità.

La risposta di Andrea mi sembra giustificatissima: lui sa cosa ha fatto Biella 
(/io onestamente non ne ho la più pallida idea.../), altri sanno cosa hanno 
fatto Bologna, Milano, Trento, ecc..: giudicare quale sia l'ente più virtuoso 
mi sembra difficile ed estremamente opinabile.

Direi invece che si potrebbero _stabilire dei criteri oggettivi_ (/poi se ne 
potrà discutere.../) per assegnare agli enti pubblici una "patente" di 
contributore, che potrebbe essere anche suddivisa in varie "classi" (/Platino, 
Oro, Argento, tanto per dire.../).

Che ve ne pare?

Ciao,

Sergio


On 2018-10-16 14:19, Andrea Musuruane wrote:
> Ciao,
>
> On Tue, Oct 16, 2018 at 12:39 PM Alessandro Palmas 
> mailto:alessandro.pal...@wikimedia.it>> 
> wrote:
>
> > La tua proposta mi solletica però mettere in piedi una sorta di
> > concorso per premiare l'ente pubblico (e qui poi dobbiamo ragionare
> > sulle dimensioni territoriali e sulle competenze amministrative) che
> > si impegna su OSM.
>
> Allora diamo subito i premi a  Bologna, Milano e Trento. Fine del
> contest per i prossimi 2 anni :-)
>
>
> Mi spiace rilevare che non si pensi anche alla Provincia di Biella, che oltre 
> a distribuire moltissimi dati geografici come open data, collabora anche 
> attivamente con OSM.
>
> Ciao,
>
> Andrea
>
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] tracciamo il futuro di OpenStreetMap in Italia?

[Sergio Manzi]

... e comunque, la mia idea è, facendo un paragone scolastico, *non 
*identificare i pochi "primi della classe", *ma *i potenzialmente molti "bravi 
studenti"...


On 2018-10-16 15:55, Sergio Manzi wrote:
>
> Così, d'acchito, mi vengono in mente alcuni criteri (che potranno ovviamente 
> essere estesi o rigettati):
>
>   * fornitura di dati
>   * partecipazione con uno o più delegati alle attività OSM
>   * sottoscrizione di un "protocollo di intesa di collaborazione" con OSM
>   * patrocini
>   * contributi economici
>   * pubblicità alle attività/sito OSM
>
>
> On 2018-10-16 15:50, Andrea Musuruane wrote:
>> Ciao,
>>
>> On Tue, Oct 16, 2018 at 2:53 PM Sergio Manzi > <mailto:s...@smz.it>> wrote:
>>
>> L'ipotesi di stilare una "graduatoria" dei comuni/enti più virtuosi non 
>> mi trova d'accordo: troppe variabili in gioco, tra le quali, non 
>> trascurabile, quella delle realzioni personali tra l'ente e le "persone" che 
>> contribuiscono a OSM e il loro realtivo "peso" all'interno della comunità.
>>
>> La risposta di Andrea mi sembra giustificatissima: lui sa cosa ha fatto 
>> Biella (/io onestamente non ne ho la più pallida idea.../), altri sanno cosa 
>> hanno fatto Bologna, Milano, Trento, ecc..: giudicare quale sia l'ente più 
>> virtuoso mi sembra difficile ed estremamente opinabile.
>>
>> Direi invece che si potrebbero _stabilire dei criteri oggettivi_ (/poi 
>> se ne potrà discutere.../) per assegnare agli enti pubblici una "patente" di 
>> contributore, che potrebbe essere anche suddivisa in varie "classi" 
>> (/Platino, Oro, Argento, tanto per dire.../).
>>
>> Che ve ne pare?
>>
>> Mi sembra una buona idea riuscire a stabilire dei criteri per identificare 
>> gli enti virtuosi.
>>
>> Ciao,
>>
>> Andrea
>>
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Non vorrei sbagliarmi, ma mi sembra che il metodo più flessibile e 
scientificamente corretto per /taggare /entità biologiche consista 
nell'utilizzare la key "taxon" [1], il cui scopo è proprio quello di evitare il 
proliferare di chiavi per differenti per  i vari elementi tassonomici dato che 
"taxon" permette di indicare "d'un botto" sia il /genus /che la /species./

Per esempio, un Leccio dovrebbe essere:

  * taxon=Quercus ilex
  * taxon:species:it=Leccio

e una Farnia

  * taxon=Quercus robur
  * taxon:species:it=Farnia

Altri begli esempi sono nella pagina del wiki [1] della key...

Sergio


[1] https://wiki.openstreetmap.org/wiki/Key:taxon


On 2018-10-23 22:39, Cascafico Giovanni wrote:
> Si, ho letto, ma sta wiki mi lascia dei dubbi: se species è il nome 
> scientifico, species:it dovrebbe esserne la traduzione dal latino, con tanto 
> di abbreviazione del catalogatore, cosa che farnia non mi pare lo sia.
> Io sarei per genus:it=Farnia
>
> Il lun 22 ott 2018, 19:26 Any File  > ha scritto:
>
> On Mon, Oct 22, 2018 at 10:37 AM Cascafico Giovanni  > wrote:
>
> > Ma il nome volgare "Farnia" dove lo metto?
>
> In species:it
>
> come indicato negli esempi che ci sono nella pagina de te indicata,
> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree
>
> oppure come spiegato in https://wiki.openstreetmap.org/wiki/Key:species
>
>
> AnyFile
> >
> > ___
> > 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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Sì, ma coste, fiumi e montagne *normalmente *cambiano in una scala di tempo 
molto più lunga: non per nulla si usa dire "tempi geologici" per indicare un 
lungo lasso di tempo...

Sono d'accordo nell'indicare, le dimensioni dell'albero (/soprattutto quando 
"interessanti"/), ma la tua stessa frase spiega perché sarebbe opportuno 
fornire *anche *un riferimento temporale alla misura: tu dici "/... puoi anche 
immaginare 5 anni dopo che forse potrebbe essere cresciuto un po’ .../" e io ti 
chiedo "/5 anni dopo quando?/"

Ciao!

Sergio


On 2018-10-26 16:55, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 26. Oct 2018, at 14:40, Gabriele Sani  wrote:
>>
>> A mio avvisto "mappare" le misure di un qualcosa che le cambia col tempo non 
>> e' esattamente corretto: cioe', in teoria si mappa cio' che non e' effimero 
>> (o almeno che potrebbe non esserlo). Le misure di un albero, altezza e 
>> circonferenza, cambieranno PER FORZA nel corso del tempo...
>
>
> tutto cambia col tempo, le coste, il percorso di un fiume, l’altezza di una 
> montagna, tanto più gli edifici, le strade, i negozi ecc.
>
> Se tu vedi nei dati un albero alto 20metri e di una certa età e specie, puoi 
> anche immaginare 5 anni dopo che forse potrebbe essere cresciuto un po’, ciò 
> non toglie l’utilità dell’informazione.
>
> Ciao, Martin 
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

L'idea che me ne sono fatto è che servano soprattutto a descrivere boschi 
(natural=wood) [1] in cui c'è una popolazione non omogenea di diverse specie di 
piante, ma globalmente/prevalentemente dalle stesse caratteristiche.

Concordo che OSM non sia un catalogo per naturalisti e che "/presentare/" 
l'informazione riguardo ai leaf_type e leaf_cycle possa essere 
interessante/utile, ma questa info può essere desunta indirettamente (/per 
esempio da Wikidata/) se so esattamente di che "taxon" si tratta, così come il 
nome in Italiano o qualsiasi altra lingua.

[1] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood


On 2018-10-26 16:00, Cascafico Giovanni wrote:
> Eppoi perché allora creare i tag leaf_type e leaf_cycle?



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Perfettamente d'accordo sul "taxon=Cupressus cashmeriana"

Anche "circumference" e "height" mi sembrano corrette, ma... cosa si fa quando 
(/com'è naturale/) l'albero cresce? Serve un riferimento temporale che 
stabilisca quando le misure sono state fatte?

"ele" può anche andare bene, ma in realtà sembra essere più pensato per le 
montagne. E' diffuso l'utilizzo di questa key per altre features?

Non sono invece d'accordo con "leaf_cycle", "leaf_type" e "taxon:it": sono 
tutte informazioni ridondanti e derivabili da un "look-up" sulla base della 
chiave "taxon".

Ciao!

Sergio


On 2018-10-26 14:14, Cascafico Giovanni wrote:
> Che ne dite di questo [1] tagging?
>
> natural=tree
> ref=28/l483/UD/06
> circumference=3 
> ele=170 
> height=20 
> leaf_cycle=deciduous 
> leaf_type=broadleaved 
> taxon=Cupressus cashmeriana 
> taxon:it=Cipresso del Cashmere 
>
>
> [1] http://audit.osmz.ru/run/AM-RAFVG/33
>
>
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] poliambulatorio e centro medicina dello sport

[Sergio Manzi]

Come si dice dalle mie parti... /me par ben/!  :-)


On 2018-10-26 14:17, demon.box wrote:
> ciao, un poliambulatorio medico dove ci sono vari medici che effettuano
> visite specialistiche di vario genere (c'è un neurologo, un cardiologo,
> ecc.) lo taggo come amenity=clinic ?
>
> e nel caso invece di un centro con più dottori che eseguono però
> esclusivamente visite per il rilascio del certificato all'attività sportiva
> agonistica e non agonistica, lo taggo come amenity=doctors ?
>
> grazie
>
> --enrico
>
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

... o anche lasciare height e circumference e mettere una note del tipo 
"note=Height and circumference as of 2018-10-26"


On 2018-10-26 14:46, Sergio Manzi wrote:
>
> Concordo, ma d'altro canto sono info che potrebbero avere una certa 
> rilevanza, sopratutto quando si tratta di "misure eccezionali" che potrebbe 
> essere interessante segnalare. Forse meglio in note=* o note:it=*  ?
>
>
> On 2018-10-26 14:40, Gabriele Sani wrote:
>> A mio avvisto "mappare" le misure di un qualcosa che le cambia col tempo non 
>> e' esattamente corretto: cioe', in teoria si mappa cio' che non e' effimero 
>> (o almeno che potrebbe non esserlo). Le misure di un albero, altezza e 
>> circonferenza, cambieranno PER FORZA nel corso del tempo...
>>
>> Il giorno ven 26 ott 2018 alle ore 14:27 Sergio Manzi > <mailto:s...@smz.it>> ha scritto:
>>
>> Perfettamente d'accordo sul "taxon=Cupressus cashmeriana"
>>
>> Anche "circumference" e "height" mi sembrano corrette, ma... cosa si fa 
>> quando (/com'è naturale/) l'albero cresce? Serve un riferimento temporale 
>> che stabilisca quando le misure sono state fatte?
>>
>> "ele" può anche andare bene, ma in realtà sembra essere più pensato per 
>> le montagne. E' diffuso l'utilizzo di questa key per altre features?
>>
>> Non sono invece d'accordo con "leaf_cycle", "leaf_type" e "taxon:it": 
>> sono tutte informazioni ridondanti e derivabili da un "look-up" sulla base 
>> della chiave "taxon".
>>
>> Ciao!
>>
>> Sergio
>>
>>
>> On 2018-10-26 14:14, Cascafico Giovanni wrote:
>>> Che ne dite di questo [1] tagging?
>>>
>>> natural=tree
>>> ref=28/l483/UD/06
>>> circumference=3 
>>> ele=170 
>>> height=20 
>>> leaf_cycle=deciduous 
>>> leaf_type=broadleaved 
>>> taxon=Cupressus cashmeriana 
>>> taxon:it=Cipresso del Cashmere 
>>>
>>>
>>> [1] http://audit.osmz.ru/run/AM-RAFVG/33
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Talk-it mailing list
>>> Talk-it@openstreetmap.org <mailto:Talk-it@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org <mailto: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
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Concordo, ma d'altro canto sono info che potrebbero avere una certa rilevanza, 
sopratutto quando si tratta di "misure eccezionali" che potrebbe essere 
interessante segnalare. Forse meglio in note=* o note:it=*  ?


On 2018-10-26 14:40, Gabriele Sani wrote:
> A mio avvisto "mappare" le misure di un qualcosa che le cambia col tempo non 
> e' esattamente corretto: cioe', in teoria si mappa cio' che non e' effimero 
> (o almeno che potrebbe non esserlo). Le misure di un albero, altezza e 
> circonferenza, cambieranno PER FORZA nel corso del tempo...
>
> Il giorno ven 26 ott 2018 alle ore 14:27 Sergio Manzi  <mailto:s...@smz.it>> ha scritto:
>
> Perfettamente d'accordo sul "taxon=Cupressus cashmeriana"
>
> Anche "circumference" e "height" mi sembrano corrette, ma... cosa si fa 
> quando (/com'è naturale/) l'albero cresce? Serve un riferimento temporale che 
> stabilisca quando le misure sono state fatte?
>
> "ele" può anche andare bene, ma in realtà sembra essere più pensato per 
> le montagne. E' diffuso l'utilizzo di questa key per altre features?
>
> Non sono invece d'accordo con "leaf_cycle", "leaf_type" e "taxon:it": 
> sono tutte informazioni ridondanti e derivabili da un "look-up" sulla base 
> della chiave "taxon".
>
> Ciao!
>
> Sergio
>
>
> On 2018-10-26 14:14, Cascafico Giovanni wrote:
>> Che ne dite di questo [1] tagging?
>>
>> natural=tree
>> ref=28/l483/UD/06
>> circumference=3 
>> ele=170 
>> height=20 
>> leaf_cycle=deciduous 
>> leaf_type=broadleaved 
>> taxon=Cupressus cashmeriana 
>> taxon:it=Cipresso del Cashmere 
>>
>>
>> [1] http://audit.osmz.ru/run/AM-RAFVG/33
>>
>>
>>
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org <mailto:Talk-it@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-it
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org <mailto: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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Ciao Giovanni,

scusami, hai perfettamente ragione: parlando di "/certificazione/" dei dati ho 
usato un termine assolutamente errato che capisco possa dare adito ad infinite 
discussioni. Non era mia intenzione: avrei dovuto parlare di "/affidabilità/" e 
in particolare intendevo riferirmi al fatto che la precisione del dato GPS per 
quanto riguarda l'altezza può essere molto più scadente di quella orizzontale 
(/ho visto coi miei occhi errori superiori ai 20m/) e che per avere un dato 
ragionevolmente corretto servono strumentazioni e tecniche di misura 
tipicamente al di fuori della nostra portata.

---

Per quanto riguarda la tassonomia delle piante, neanche io sono un 
professionista del settore, ma mi sembra proprio che il dato (estremamente 
preciso) fornito dal mipaaf come "Nome scientifico" non debba essere in nessun 
modo deteriorato, ma vada mantenuto "tale e quale".

"Dove" inserire questo dato può essere opinabile:

  * escluderei "genus" perché /genus /in biologia ha un significato ben 
preciso, riconosciuto dal Wiki in [1], "/T//he scientific name of the *genus 
*for a living or fossil organism./" cioè "/Il nome scientifico del *genere *di 
un organismo vivente o fossile/" e con /genere /si intende "/una categoria che 
_raggruppa le specie_, in quanto aventi caratteristiche comuni tra loro/" [2].

  * "species" potrebbe andare bene, visto che la definizione che ne da il Wiki 
è proprio "/The scientific name of the species for a living or fossil 
organism./" [3], "/Il nome scientifico //**della specie di un organismo vivente 
o fossile/" e che /specie /rappresenta il /"livello tassonomico obbligatorio 
gerarchicamente più basso"/ [4]. La mia sensazione, però, è che nella prassi, 
probabilmente a causa di un Wiki men che chiaro, si sia diffusa l'abitudine (/a 
mio avviso orribile/) di /spacchettare /il nome scientifico (es. Quercus 
robur") in genus=Qurecus + species=Robur, o, come cita il Wiki, ad errori quali 
"species=Oak" (/Oak è un termine Inglese, quindi non un nome scientifico, e 
l'equivalente latino "Quercus" è un genus , non una species/)

  * "taxon" [5], è ampiamente meno usato di "species" e non gode dello "status: 
approved", ma solo di "status: in use". Il suo uso, però, mi sembra rappresenti 
il tentativo di mettere un po' di ordine nelle cose e soprattutto di spingere 
verso l'uso della nomenclatura scientifica (in latino) piuttosto che quella in 
Inglese. Inoltre, con le sue sotto-chiavi, permette anche (dove fosse 
necessario) di indicare "la precisione" con cui è stato identificato l'oggetto. 
Se ho certezza che un certo albero sia del genere "Quercus", ma non so 
identificare con esattezza di che specie si tratti, posso mettere 
"taxon:genus=Quercus". In un secondo tempo qualcuno più bravo di me potrà 
identificarlo come "Quercus robur" e aggiustare di conseguenza il taxon in 
"taxon=Quercus robur". Inoltre taxon permette una identificazione ancora pù 
precisa del livello di "specie", permettendo anche l'identificazione di 
varietà, cultivar, o altro ancora. Ma, mi ripeto, l'aspetto che trovo più 
importante è
che utilizzando "taxon" in qualche modo /si assicura/ che si tratti di un 
nome scientifico e non di un nome comune (/e da questo, poi, può derivare la 
possibilità di effettuare look-up per "estrarre" ulteriore informazioni, quali 
per esempio i nomi localizzati per le varie lingue/)

Per questo motivo la mia proposta è di utilizzare per i nomi scientifici del 
dataset mipaaf la chiave "taxon".

Ciao,

Sergio

---

[1] https://wiki.openstreetmap.org/wiki/Key:genus
[2] https://it.wikipedia.org/wiki/Genere_(tassonomia)
[3] https://wiki.openstreetmap.org/wiki/Key:species
[4] https://it.wikipedia.org/wiki/Specie
[5] https://wiki.openstreetmap.org/wiki/Key:taxon


On 2018-10-27 17:03, Cascafico Giovanni wrote:
>
> Il mio dubbio riguardo al dato "ele" è se (/non so.../) venga sempre 
> visualizzato sulla mappa quando presente.
>
>
> No, mi pare non sia visualizzato nemmeno se è l'unico tag.
>
> Inoltre, forse, è preferibile utilizzare questo dato solo quando sia 
> certificato (/parliamo comunque di certezza umana.../), come nel caso 
> dell'altezza delle montagne o degli aeroporti.
>
>
> Personalmente ho aggiunto diversi valori ele ricavati dai dati exif delle mie 
> foto. Comunque un'occhiata a campione fa sempre bene.
>
>  Il discorso della certificazione sconvolgerebbe tutto 
> osm se fosse applicato: chi ha l'autorità di certificare? quali sono le 
> priorità per certificare? quali sono le tolleranze? L'approccio e la 
> peculiarità osm sono proprio nel non avere un'autorità centrale. Che ciascuno 
> possa essere creatore e controllore finora ha dato risultati non male, non 
> credi?
>
> Personalmente faccio (/fortemente/) il tifo per "taxon" che riunisce in 
> se i due termini (Genus + species) della classificazione binomiale [1] (es: 
> "Pinus nigra") e che si presta ad ulteriori specificazioni (es. "/Pinus 
> nigra/ var. /austriaca/")
>
>
> Sono 

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

P.S.: Nei dati vedo "cose" che temo ci creeranno ulteriori mal di testa: per 
esempio in un caso in Trentino vedo nella scheda un "Nome scientifico" definito 
come "/Insieme omogeneo di Larix decidua Mill. e Picea abies (L) H. Karst./". 
Che si fa???  :-/


On 2018-10-28 13:25, Sergio Manzi wrote:
>
> Ciao Giovanni,
>
> scusami, hai perfettamente ragione: parlando di "/certificazione/" dei dati 
> ho usato un termine assolutamente errato che capisco possa dare adito ad 
> infinite discussioni. Non era mia intenzione: avrei dovuto parlare di 
> "/affidabilità/" e in particolare intendevo riferirmi al fatto che la 
> precisione del dato GPS per quanto riguarda l'altezza può essere molto più 
> scadente di quella orizzontale (/ho visto coi miei occhi errori superiori ai 
> 20m/) e che per avere un dato ragionevolmente corretto servono strumentazioni 
> e tecniche di misura tipicamente al di fuori della nostra portata.
>
> ---
>
> Per quanto riguarda la tassonomia delle piante, neanche io sono un 
> professionista del settore, ma mi sembra proprio che il dato (estremamente 
> preciso) fornito dal mipaaf come "Nome scientifico" non debba essere in 
> nessun modo deteriorato, ma vada mantenuto "tale e quale".
>
> "Dove" inserire questo dato può essere opinabile:
>
>   * escluderei "genus" perché /genus /in biologia ha un significato ben 
> preciso, riconosciuto dal Wiki in [1], "/T//he scientific name of the *genus 
> *for a living or fossil organism./" cioè "/Il nome scientifico del *genere 
> *di un organismo vivente o fossile/" e con /genere /si intende "/una 
> categoria che _raggruppa le specie_, in quanto aventi caratteristiche comuni 
> tra loro/" [2].
>
>   * "species" potrebbe andare bene, visto che la definizione che ne da il 
> Wiki è proprio "/The scientific name of the species for a living or fossil 
> organism./" [3], "/Il nome scientifico //**della specie di un organismo 
> vivente o fossile/" e che /specie /rappresenta il /"livello tassonomico 
> obbligatorio gerarchicamente più basso"/ [4]. La mia sensazione, però, è che 
> nella prassi, probabilmente a causa di un Wiki men che chiaro, si sia diffusa 
> l'abitudine (/a mio avviso orribile/) di /spacchettare /il nome scientifico 
> (es. Quercus robur") in genus=Qurecus + species=Robur, o, come cita il Wiki, 
> ad errori quali "species=Oak" (/Oak è un termine Inglese, quindi non un nome 
> scientifico, e l'equivalente latino "Quercus" è un genus , non una species/)
>
>   * "taxon" [5], è ampiamente meno usato di "species" e non gode dello 
> "status: approved", ma solo di "status: in use". Il suo uso, però, mi sembra 
> rappresenti il tentativo di mettere un po' di ordine nelle cose e soprattutto 
> di spingere verso l'uso della nomenclatura scientifica (in latino) piuttosto 
> che quella in Inglese. Inoltre, con le sue sotto-chiavi, permette anche (dove 
> fosse necessario) di indicare "la precisione" con cui è stato identificato 
> l'oggetto. Se ho certezza che un certo albero sia del genere "Quercus", ma 
> non so identificare con esattezza di che specie si tratti, posso mettere 
> "taxon:genus=Quercus". In un secondo tempo qualcuno più bravo di me potrà 
> identificarlo come "Quercus robur" e aggiustare di conseguenza il taxon in 
> "taxon=Quercus robur". Inoltre taxon permette una identificazione ancora pù 
> precisa del livello di "specie", permettendo anche l'identificazione di 
> varietà, cultivar, o altro ancora. Ma, mi ripeto, l'aspetto che trovo più 
> importante è
> che utilizzando "taxon" in qualche modo /si assicura/ che si tratti di un 
> nome scientifico e non di un nome comune (/e da questo, poi, può derivare la 
> possibilità di effettuare look-up per "estrarre" ulteriore informazioni, 
> quali per esempio i nomi localizzati per le varie lingue/)
>
> Per questo motivo la mia proposta è di utilizzare per i nomi scientifici del 
> dataset mipaaf la chiave "taxon".
>
> Ciao,
>
> Sergio
>
> ---
>
> [1] https://wiki.openstreetmap.org/wiki/Key:genus
> [2] https://it.wikipedia.org/wiki/Genere_(tassonomia)
> [3] https://wiki.openstreetmap.org/wiki/Key:species
> [4] https://it.wikipedia.org/wiki/Specie
> [5] https://wiki.openstreetmap.org/wiki/Key:taxon
>
>
> On 2018-10-27 17:03, Cascafico Giovanni wrote:
>>
>> Il mio dubbio riguardo al dato "ele" è se (/non so.../) venga sempre 
>> visualizzato sulla mappa quando presente.
>>
>>
>> No, mi pare n

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Ignorare mi sembra un peccato, il fixme, ci può stare, direi.

Penso anche che non sarebbe male "portarsi dietro" l'ID_SCHEDA, forse in una 
"note" ("note=mipaaf ID Scheda: 01/H361/VI/05" oppure, con un po' di 
creatività, "note:mipaaf_id_scheda=01/H361/VI/05")


On 2018-10-28 14:34, Cascafico Giovanni wrote:
> "Insieme omogeneo" ce ne sono (pochi) anche in fvg. Si possono ignorare o 
> desidere di aggiugere un tag p.es <http://p.es>. fixme=redefine as polygon
>
> Il dom 28 ott 2018, 14:30 Sergio Manzi mailto:s...@smz.it>> ha 
> scritto:
>
> P.S.: Nei dati vedo "cose" che temo ci creeranno ulteriori mal di testa: 
> per esempio in un caso in Trentino vedo nella scheda un "Nome scientifico" 
> definito come "/Insieme omogeneo di Larix decidua Mill. e Picea abies (L) H. 
> Karst./". Che si fa???  :-/
>
>
> On 2018-10-28 13:25, Sergio Manzi wrote:
>>
>> Ciao Giovanni,
>>
>> scusami, hai perfettamente ragione: parlando di "/certificazione/" dei 
>> dati ho usato un termine assolutamente errato che capisco possa dare adito 
>> ad infinite discussioni. Non era mia intenzione: avrei dovuto parlare di 
>> "/affidabilità/" e in particolare intendevo riferirmi al fatto che la 
>> precisione del dato GPS per quanto riguarda l'altezza può essere molto più 
>> scadente di quella orizzontale (/ho visto coi miei occhi errori superiori ai 
>> 20m/) e che per avere un dato ragionevolmente corretto servono 
>> strumentazioni e tecniche di misura tipicamente al di fuori della nostra 
>> portata.
>>
>> ---
>>
>> Per quanto riguarda la tassonomia delle piante, neanche io sono un 
>> professionista del settore, ma mi sembra proprio che il dato (estremamente 
>> preciso) fornito dal mipaaf come "Nome scientifico" non debba essere in 
>> nessun modo deteriorato, ma vada mantenuto "tale e quale".
>>
>> "Dove" inserire questo dato può essere opinabile:
>>
>>   * escluderei "genus" perché /genus /in biologia ha un significato ben 
>> preciso, riconosciuto dal Wiki in [1], "/T//he scientific name of the *genus 
>> *for a living or fossil organism./" cioè "/Il nome scientifico del *genere 
>> *di un organismo vivente o fossile/" e con /genere /si intende "/una 
>> categoria che _raggruppa le specie_, in quanto aventi caratteristiche comuni 
>> tra loro/" [2].
>>
>>   * "species" potrebbe andare bene, visto che la definizione che ne da 
>> il Wiki è proprio "/The scientific name of the species for a living or 
>> fossil organism./" [3], "/Il nome scientifico //**della specie di un 
>> organismo vivente o fossile/" e che /specie /rappresenta il /"livello 
>> tassonomico obbligatorio gerarchicamente più basso"/ [4]. La mia sensazione, 
>> però, è che nella prassi, probabilmente a causa di un Wiki men che chiaro, 
>> si sia diffusa l'abitudine (/a mio avviso orribile/) di /spacchettare /il 
>> nome scientifico (es. Quercus robur") in genus=Qurecus + species=Robur, o, 
>> come cita il Wiki, ad errori quali "species=Oak" (/Oak è un termine Inglese, 
>> quindi non un nome scientifico, e l'equivalente latino "Quercus" è un genus 
>> , non una species/)
>>
>>   * "taxon" [5], è ampiamente meno usato di "species" e non gode dello 
>> "status: approved", ma solo di "status: in use". Il suo uso, però, mi sembra 
>> rappresenti il tentativo di mettere un po' di ordine nelle cose e 
>> soprattutto di spingere verso l'uso della nomenclatura scientifica (in 
>> latino) piuttosto che quella in Inglese. Inoltre, con le sue sotto-chiavi, 
>> permette anche (dove fosse necessario) di indicare "la precisione" con cui è 
>> stato identificato l'oggetto. Se ho certezza che un certo albero sia del 
>> genere "Quercus", ma non so identificare con esattezza di che specie si 
>> tratti, posso mettere "taxon:genus=Quercus". In un secondo tempo qualcuno 
>> più bravo di me potrà identificarlo come "Quercus robur" e aggiustare di 
>> conseguenza il taxon in "taxon=Quercus robur". Inoltre taxon permette una 
>> identificazione ancora pù precisa del livello di "specie", permettendo anche 
>> l'identificazione di varietà, cultivar, o altro ancora. Ma, mi ripeto, 
>> l'aspetto che trovo più
>> importante è che utilizzando "taxon" in qualche modo /si assicura/ 
>> che si tratti di un

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Rispetto la tua posizione, ma... puoi spiegarne i motivi? Quali sono i rischi, 
secondo te?

Comunque, /n /è pari a 5.3 (/quindi siamo ampiamente nello stesso ordine di 
grandezza/) e inoltre penso che i criteri di scelta debbano essere più 
qualitativi che quantitativi.

Prova anche a fare un overpass-turbo per /taxon /(/puoi limitarti ai nodes/) su 
Vienna, Londra o Parigi e vedi cosa salta fuori.

Ciao,

Sergio

On 2018-10-29 00:51, Martin Koppenhoefer wrote
>> On 28. Oct 2018, at 13:25, Sergio Manzi  wrote:
>>
>> Per questo motivo la mia proposta è di utilizzare per i nomi scientifici del 
>> dataset mipaaf la chiave "taxon".
> per un import escluderei l’ipotesi di appoggiare un tag usato n volte di meno.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Ciao Paolo,

grazie per il tuo supporto: incominciavo a sentirmi un po' Don Quixote...  :-)

Ti dirò anche che il nome della key, /taxon/, non è quello che io avrei 
preferito: penso che sarebbe stato preferibile qualcosa di più facile e 
universale comprensione, come, per esempio, "/scientific_name/", ma taxon è già 
usato (/poco meno di 200.000 volte/), e quindi mi sta bene vivere con taxon e 
promuoverne l'uso.

Sergio

P.S.: per le calli veneziane... sto preparando un documento e anche che si 
asciughino dall'ultima "acqua alta": porta pazienza!


On 2018-10-31 10:22, Paolo Monegato wrote:
> Il 30/10/2018 15:32, Sergio Manzi ha scritto:
>>
>> Inoltre un import come questo può essere l'occasione per *promuovere l'uso 
>> di taxon*, così come in passato hanno fatto altri (/che, a mio avviso, 
>> "hanno visto la luce/").
>>
> Il fatto è che è altamente sconsigliato in un import inserire nuovi tag o 
> usare i tag meno usati.
>
> Regola che ha un suo senso, ma è pur vero che grazie ad essa in sostanza si 
> tiene alto in modo artificioso il numero di tag obsoleti o non adatti a 
> descrivere al meglio un oggetto sulla mappa.
>
> Imho se un tag è migliore di un altro lo si dovrebbe usare in ogni caso. E 
> taxon è meglio di species.
>
> ciao
> Paolo M
>
> ps: quando la apri la discussione sulla classificazione delle calli veneziane?
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Solo per farvi sapere che ho formalizzato la mia proposta di utilizzare taxon 
invece di species, qui: 
https://wiki.openstreetmap.org/wiki/Talk:Import/Catalogue/AlberiMonumentali-RAFVG

Ciao a tutti,

Sergio





smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] case sparse vs localita'

[Sergio Manzi]

Citazione sbagliata: [1] deve essere: 
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix

On 2018-11-01 13:14, Sergio Manzi wrote:
>
> Ciao,
>
> penso che dovrebbe essere "abandoned:place=isolate_dwelling"
>
> "abandoned" non è una e vera propria key, ma un prefisso, tecnicamente un 
> "Lifecycle prefix" [1], che (mi sembra) può essere attribuito più o meno a 
> qualsiasi key.
>
> Oltre ad "abandoned" ci sono altri "prefissi" che puoi trovare sempre in [1], 
> che forse potrebbero anche essere più adatti a specifici casi (es. disused, 
> removed, demolished, razed).
>
> Sergio
>
> [1] https://wiki.openstreetmap.org/wiki/Key:abandoned:
>
>
> On 2018-11-01 11:24, Gabriele Sani wrote:
>> Proprio da qui viene il mio dubbio: se l'agglomerato è di 1/2 case sarebbe 
>> isolate_dwelling, ma se sono abbandonate?
>>
>> Il gio 1 nov 2018 10:12 Federico Cortese > <mailto:cortese...@gmail.com>> ha scritto:
>>
>> On Wed, Oct 31, 2018 at 6:45 PM Damjan Gerl > <mailto:dam...@damjan.net>> wrote:
>> >
>> > Direi che va bene usare locality, tranne che non vuoi nominare proprio 
>> quella casa/rudere e non tutta la zona circostante. Case sparse 
>> (place=isolated_dwelling) si dovrebbe usare per località amministrative, nel 
>> senso che ci sono uno o più numeri civici di quella località.
>> >
>>
>> Dalla wiki pare che place=isolated_dwelling
>> (https://wiki.openstreetmap.org/wiki/Tag:place%3Disolated_dwelling)
>> sia previsto dove esistono al massimo 2 abitazioni ("The whole
>> settlement must not consist of more than 2 households").
>> In Puglia vedo che è stato usato molto spesso per indicare masserie
>> isolate in campagna, anche abbandonate
>> (http://overpass-turbo.eu/s/Dho).
>>
>> Ciao,
>> Federico
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org <mailto: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
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Taggare formazioni montuose

[Sergio Manzi]

"arete" è estremamente specifico, per crinali di roccia, "affilati", di origine 
glaciale: usato meno di 2.000 volte contro le 64.000 di ridge


On 2018-11-01 13:36, Andreas Lattmann wrote:
> Ma i crinali non si taggano come natural=arete [1]? 
>
> E quando "rotondeggianti" natural=ridge [2]?
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:natural%3Darete
>
> [2] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dridge
>
>
> Il November 1, 2018 12:12:02 PM UTC, matteocalosi  ha 
> scritto:
>> "Costa" e "Serra" spesso si riferiscono a crinali, in questo caso il
>> tag è
>> natural=ridge sulla linea di spartiacque.
>> Una costa può essere anche invece un determinato versante di una
>> formazione,
>> in questo caso non credo ci sia di meglio di place=locality
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
> Andreas Lattmann




smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] case sparse vs localita'

[Sergio Manzi]

Ciao,

penso che dovrebbe essere "abandoned:place=isolate_dwelling"

"abandoned" non è una e vera propria key, ma un prefisso, tecnicamente un 
"Lifecycle prefix" [1], che (mi sembra) può essere attribuito più o meno a 
qualsiasi key.

Oltre ad "abandoned" ci sono altri "prefissi" che puoi trovare sempre in [1], 
che forse potrebbero anche essere più adatti a specifici casi (es. disused, 
removed, demolished, razed).

Sergio

[1] https://wiki.openstreetmap.org/wiki/Key:abandoned:


On 2018-11-01 11:24, Gabriele Sani wrote:
> Proprio da qui viene il mio dubbio: se l'agglomerato è di 1/2 case sarebbe 
> isolate_dwelling, ma se sono abbandonate?
>
> Il gio 1 nov 2018 10:12 Federico Cortese  > ha scritto:
>
> On Wed, Oct 31, 2018 at 6:45 PM Damjan Gerl  > wrote:
> >
> > Direi che va bene usare locality, tranne che non vuoi nominare proprio 
> quella casa/rudere e non tutta la zona circostante. Case sparse 
> (place=isolated_dwelling) si dovrebbe usare per località amministrative, nel 
> senso che ci sono uno o più numeri civici di quella località.
> >
>
> Dalla wiki pare che place=isolated_dwelling
> (https://wiki.openstreetmap.org/wiki/Tag:place%3Disolated_dwelling)
> sia previsto dove esistono al massimo 2 abitazioni ("The whole
> settlement must not consist of more than 2 households").
> In Puglia vedo che è stato usato molto spesso per indicare masserie
> isolate in campagna, anche abbandonate
> (http://overpass-turbo.eu/s/Dho).
>
> 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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

No, questo è errato: "taxon" _non dice di meno_, perché è il valore associato a 
taxon "a dire" di cosa stiamo parlando, non il nome del tag!


On 2018-10-30 15:12, Martin Koppenhoefer wrote:
>
> Ma il termine "taxon" è più flessibile, perché ci permette di 
> identificare un "individuo" come appartenente ad un livello qualsiasi della 
> gerarchia tassonomica, sia essa più generica o più specifica di "genus" o 
> "species".
>
>
> si, e di conseguenza dice anche di meno. Comunque, mi sembra di aver capito 
> che qui abbiamo una lista di alberi con la loro specie, perché non dirlo?
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

On 2018-10-30 14:36, Sergio Manzi wrote:
> come, per esempio, "family", "variety" o "form"

*Errore:* per consistenza (/nome del livello tassonomico in latino/) dovrebbero 
essere "/familia/", "/varietas/" o "/forma/"


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

... è, benché sia vero che abbiamo al 99% abbiamo indicate delle "species", 
guarda caso abbiamo anche delle cose tipo "Cedrus atlantica (Endl) Carrière 
*var. glauca*" che sarebbe _semanticamente errato indicare come species_.

Inoltre un import come questo può essere l'occasione per *promuovere l'uso di 
taxon*, così come in passato hanno fatto altri (/che, a mio avviso, "hanno 
visto la luce/").


On 2018-10-30 15:21, Sergio Manzi wrote:
>
> No, questo è errato: "taxon" _non dice di meno_, perché è il valore associato 
> a taxon "a dire" di cosa stiamo parlando, non il nome del tag!
>
>
> On 2018-10-30 15:12, Martin Koppenhoefer wrote:
>>
>> Ma il termine "taxon" è più flessibile, perché ci permette di 
>> identificare un "individuo" come appartenente ad un livello qualsiasi della 
>> gerarchia tassonomica, sia essa più generica o più specifica di "genus" o 
>> "species".
>>
>>
>> si, e di conseguenza dice anche di meno. Comunque, mi sembra di aver capito 
>> che qui abbiamo una lista di alberi con la loro specie, perché non dirlo?
>>
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Martin,

premesso che su queste cose (/la tassonomia/) gente ben più qualificata di me e 
(/suppongo/) te si scorna ormai da centinaia di anni senza arrivare a 
conclusioni definitive e che quindi sarà assai difficile arrivare ad un 
consenso, come ho già detto il mio criterio di preferenza di /taxon /su 
/species /non è di natura quantitativa, ma qualitativa e, ritengo, basato su 
solidi argomenti, che, mi scuserai, ritengo opportuno ripetere:

Inequivocabilmente si definisce come taxon "/un raggruppamento di organismi 
reali, distinguibili morfologicamente e geneticamente da altri e riconoscibili 
come unità sistematica, posizionata all'interno della struttura gerarchica 
della classificazione scientifica/" [1] e, sempre in [1], "/Fin da Carlo 
Linneo, per classificare gli organismi, la tassonomia utilizza un sistema 
gerarchico. In questo schema organizzativo, *ogni gruppo di organismi 
particolari è un taxón*, e il livello gerarchico nel quale lo si situa è la sua 
categoria.  ...  "famiglia", "genere" e "specie" sono categorie tassonomiche, 
mentre Rosaceae, "Rosa" e "Rosa canina" sono un esempio di taxa di queste 
categorie./"

"genus" e "species" sono solo due tra i vari livelli (/categorie tassonomiche/) 
che compongono questa organizzazione gerarchica. Utilizzarli, non è sbagliato, 
quando associati ad un valore congruente con quel particolare livello.

Ma il termine "taxon" è più flessibile, perché ci permette di identificare un 
"individuo" come appartenente ad un livello qualsiasi della gerarchia 
tassonomica, sia essa più generica o più specifica di "genus" o "species".

In alternativa dovremmo, oltre a "/genus/" e "/species/", prevedere altry tag 
corrispondenti ai vari livelli di categorizzazione tassonomica, come, per 
esempio, "family", "variety" o "form": mi sembra più semplice usare "taxon" e 
tanti saluti...

Ciao,

Sergio

[1] https://it.wikipedia.org/wiki/Taxon


On 2018-10-29 22:53, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 29. Oct 2018, at 11:17, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
>> Prova anche a fare un overpass-turbo per /taxon /(/puoi limitarti ai nodes/) 
>> su Vienna, Londra o Parigi e vedi cosa salta fuori.
>
>
> guardando l’andamento è ancora molto più chiaro che taxon quasi non è stato 
> usato tranne 2 imports:
>
> image1.png
>
> Ciao, Martin 
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Opera di presa acquedotto

[Sergio Manzi]

Bella domanda...

La cosa più simile che ho trovato sul wiki è questa 
*proposta*:**https://wiki.openstreetmap.org/wiki/Proposed_features/Hydropower_water_supplies#Water_intakes

Anche la semplice traduzione in Inglese di "opera di presa" (/questo sono.../) 
non è banale e, appunto, "water intake" mi sembra essere la più papabile...

Ciao!

On 2018-10-25 18:55, Massimo Taronna wrote:
> Ciao,
> mi potreste indicare come mappare un edificio, parzialmente interrato, 
> adibito a presa acquedotto.
> In montagna lungo i torrenti se ne trovano diversi, più o meno interrati.
>
> Grazie!
>
> Massimo Taronna
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] poliambulatorio e centro medicina dello sport

[Sergio Manzi]

No, è giusto: una /clinic/ Inglese/Americana/Ecc... è una "outpatient's 
facility", non prevede le degenze degenze, e quindi va benissimo in questo caso.

Vedi https://www.dictionary.com/browse/clinic

Ciao!


On 2018-10-27 09:58, scratera wrote:
> ...clinic non lo metterei...specificheresti che ci sono degenti e non mi pare
> il casospecificherei piuttosto con healthcare=centre
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Ciao Giovanni,


On 2018-10-27 10:58, Cascafico Giovanni wrote:
> il ref è del ministero ed usano lo stesso schema in tutti i documenti excel 
> delle regioni, per cui direi
> ref:mipaaft.

Può essere utile aggiungere un riferimento temporale (es.  mipaaft2018) per 
distinguere potenziali successivi import?

> Per ele, il datum non è idefinito. Suppongo sia stato quello che leggevano i 
> rilevatori sul gps. Vedrò di fare qualche campionamento.

Il mio dubbio riguardo al dato "ele" è se (/non so.../) venga sempre 
visualizzato sulla mappa quando presente. In tal caso ci sarebbe il rischio, 
credo, di "/confusionare/" un po' troppo il rendering (/sì, lo so, non si mappa 
per la mappa, ma.../). Inoltre, forse, è preferibile utilizzare questo dato 
solo quando sia certificato (/parliamo comunque di certezza umana.../), come 
nel caso dell'altezza delle montagne o degli aeroporti.

> Sull'uso di species o taxon, avevo inizialmente  considerato la prima, in 
> quanto composta da taxon+catalogatori... aspettiamo qualche altro parere.
> Tra l'altro, per generare taxon ho considerato le prime due parole di 
> species, metodo ok per gran parte dei casi, ma non universalmente applicabile.

Personalmente faccio (/fortemente/) il tifo per "taxon" che riunisce in se i 
due termini (Genus + species) della classificazione binomiale [1] (es: "Pinus 
nigra") e che si presta ad ulteriori specificazioni (es. "/Pinus nigra/ var. 
/austriaca/")

Ciao,

Sergio

[1] https://it.wikipedia.org/wiki/Nomenclatura_binomiale


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] poliambulatorio e centro medicina dello sport

[Sergio Manzi]

Ciao Volker!

Concordo... parzialmente: non mi sembra che l'esistenza di laboratori e/o 
strutture interventistiche sia necessaria a definire una "clinic". Per me una 
/clinic /è un luogo dove ci sono più medici (una "/shared practice/"). Credo si 
definisca /clinic /anche quello che in Italiano chiamiamo consulto/consultorio.

Sergio


On 2018-10-27 12:33, Volker Schmidt wrote:
> Il confine è fluido fra
>
>   * amenity=clinic e un posto con tanti medici, con laboratori, spesso anche 
> per interventi, ma senza letti per la notte (che in Italia spesso si chiamano 
> "day hospital", ma, attenzione, questo uso del termine inglese in italiano è 
> diverso. Il "day hospital" in UK e USA è tipicamente per anziani)
>   * amenity=doctors è un ambulatorio con almeno un medico, tipicamente senza 
> laboratori o possibilità per interventi
>
>
>
>
>
> On Fri, 26 Oct 2018 at 14:18, demon.box  > wrote:
>
> ciao, un poliambulatorio medico dove ci sono vari medici che effettuano
> visite specialistiche di vario genere (c'è un neurologo, un cardiologo,
> ecc.) lo taggo come amenity=clinic ?
>
> e nel caso invece di un centro con più dottori che eseguono però
> esclusivamente visite per il rilascio del certificato all'attività 
> sportiva
> agonistica e non agonistica, lo taggo come amenity=doctors ?
>
> grazie
>
> --enrico
>
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

D'accordo su tutta la linea, ma... ci vedi qualcosa di sbagliato nel mettere 
una "note"?


On 2018-10-26 23:31, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 26. Oct 2018, at 17:09, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
>> ma la tua stessa frase spiega perché sarebbe opportuno fornire *anche *un 
>> riferimento temporale alla misura: tu dici "/... puoi anche immaginare 5 
>> anni dopo che forse potrebbe essere cresciuto un po’ .../" e io ti chiedo 
>> "/5 anni dopo quando?/"
>
>
> Questo è un tipico problema con gli import: i dati sono sempre più vecchi 
> rispetto al nostro standard. Normalmente la data di caricamento è anche più o 
> meno la data del rilievo, mentre per gli import la data del rilievo è 1-50 
> anni prima del caricamento ;-)
>
> Comunque, una cosa è certa, i dati hanno sempre al minimo l’età del tempo 
> passato dal caricamento.
>
> Sono d’accordo con chi l’ha scritto sopra: i dati dei rilievi sono da 
> inserire nel changeset / wiki linkato dal changeset.
>
> Ciao, Martin 
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Evoluzione della mappa

[Sergio Manzi]

Esatto, ho provato anche io ed ho ricevuto i medesimi errori, anche su aree 
molto piccole...

Per quanto riguarda l'uso di Osmdiff, a parte la (/relativa/) complicazione 
nell'installazione (/vengono date indicazioni di massima per Linux, ma immagino 
si possa usare anche sotto Windows/Mac installando Perl/), vedo che richiede in 
input files .osm: come si possono ottenere, soprattutto per il passato? Il wiki 
di Osmdiff dice di utilizzare API/XAPI (/grazie.../) o geofabrik, ma 
quest'ultimo mi sembra fornisca solo files monolitici ed enormi per i vari 
continenti e solo quelli "/correnti/"...

Ciao,

Sergio


On 2018-11-04 11:40, liste DOT girarsi AT posteo DOT eu wrote:
> Il 04/11/18 11:15, Francesco Pelullo ha scritto:
>> Ciao a tutti,
>>
>> vorrei visualizzare qual era il contenuto del database in una certa data e
>> confrontarlo con il suo contenuto attuale, insomma vedere come si è evoluta
>> la "mappa" a partire da una certa data.
>>
>> Qual è il sito/servizio piu' semplice da utilizzare?
>> Scusate ma ho avuto un'amnesia.
>
>
> No, niente, vedo che va in eccesso di memoria anche su piccolissime aree, per 
> storici annuali.
>
> Ho visto che c'è questo:
>
> https://wiki.openstreetmap.org/wiki/Osmdiff
>
>
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Evoluzione della mappa

[Sergio Manzi]

Ciao Ale,

Grazie!


On 2018-11-04 12:39, Alessandro Sarretta wrote:
>
> Tramite overpass turbo: 
> https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example#OSM_data_at_a_certain_date
>
> Ale
>
> On 04/11/18 11:52, Sergio Manzi wrote:
>>
>> Esatto, ho provato anche io ed ho ricevuto i medesimi errori, anche su aree 
>> molto piccole...
>>
>> Per quanto riguarda l'uso di Osmdiff, a parte la (/relativa/) complicazione 
>> nell'installazione (/vengono date indicazioni di massima per Linux, ma 
>> immagino si possa usare anche sotto Windows/Mac installando Perl/), vedo che 
>> richiede in input files .osm: come si possono ottenere, soprattutto per il 
>> passato? Il wiki di Osmdiff dice di utilizzare API/XAPI (/grazie.../) o 
>> geofabrik, ma quest'ultimo mi sembra fornisca solo files monolitici ed 
>> enormi per i vari continenti e solo quelli "/correnti/"...
>>
>> Ciao,
>>
>> Sergio
>>
>>
>> On 2018-11-04 11:40, liste DOT girarsi AT posteo DOT eu wrote:
>>> Il 04/11/18 11:15, Francesco Pelullo ha scritto:
>>>> Ciao a tutti,
>>>>
>>>> vorrei visualizzare qual era il contenuto del database in una certa data e
>>>> confrontarlo con il suo contenuto attuale, insomma vedere come si è evoluta
>>>> la "mappa" a partire da una certa data.
>>>>
>>>> Qual è il sito/servizio piu' semplice da utilizzare?
>>>> Scusate ma ho avuto un'amnesia.
>>>
>>>
>>> No, niente, vedo che va in eccesso di memoria anche su piccolissime aree, 
>>> per storici annuali.
>>>
>>> Ho visto che c'è questo:
>>>
>>> https://wiki.openstreetmap.org/wiki/Osmdiff
>>>
>>>
>>>
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
> -- 
> -- 
>
> Alessandro Sarretta
>
> skype/twitter: alesarrett
> Web: ilsarrett.wordpress.com <http://ilsarrett.wordpress.com>
>
> Research information:
>
>   * Google scholar profile 
> <http://scholar.google.it/citations?user=IsyXargJ=it>
>   * ORCID <http://orcid.org/-0002-1475-8686>
>   * Research Gate <https://www.researchgate.net/profile/Alessandro_Sarretta>
>   * Impactstory <https://impactstory.org/AlessandroSarretta>
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] nomi vie con numeri romani

[Sergio Manzi]

-1


On 2018-10-19 12:13, Cascafico Giovanni wrote:
> Il giorno ven 19 ott 2018 alle ore 11:55 Marco_T  > ha scritto:
>
>
> In questo caso il nome del mese non è usato come nome comune ("in aprile
> arrivano le rondini") ma come nome proprio della via in quanto appellativo
> toponomastico unico ed individuale della strada all'interno del Comune.
> Pertanto a mio parere le iniziali vanno in maiuscolo. Come se una persona 
> si
> chiamsse Primo (nome), Agosto (cognome).
> Mia opinione.
>
>  
>
> +1
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

... in realtà è già in uso (/ma non molto, vedi/ [1]) una key "est_height", ma 
personalmente continuo a pensare che height:estimate sia preferibile...

[1] https://taginfo.openstreetmap.org/keys/est_height


On 2018-11-08 14:53, Sergio Manzi wrote:
>
> ... nel caso ci siano entrambe, forse si potrebbe fare: h_misurata->height e 
> h_stimata->height:estimate /(lo so, height:estimate sarebbe una "novità", ma 
> non mi sembra male e si potrebbe documentare sul wiki../.)
>
> Sergio
>
>
> On 2018-11-08 14:44, Sergio Manzi wrote:
>>
>> Giovanni,
>>
>> non capisco le relazioni h_stimata->height e h_misurata->height: non 
>> collidono? O forse nei dati originali l'esistenza di una misura implica 
>> l'assenza dell'altra?
>>
>> Ciao,
>>
>> Sergio
>>
>>
>> On 2018-11-08 14:30, Cascafico Giovanni wrote:
>>> Ho cercato di raccogliere i pareri di tutti sul tagging nella wiki [1] ed 
>>> ho aggiornato la mappa di revisione [2]. Domani vedo si compilarla... 
>>> potete partecipare tutti. Attenzione in particolare agli alberi con source 
>>> diversa da "Regione FVG". Nel dubbio, uno "skip" od un fixme non fa mai 
>>> male :-)
>>>
>>> Se questo piccol import va bene, possiamo clonarlo senza troppe difficoltà 
>>> per le altre regioni.
>>>
>>>
>>> [1] 
>>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlberiMonumentali-RAFVG-opendata#Record_format_and_tagging_plan
>>> [2] http://audit.osmz.ru/project/AM-RAFVG-OO/
>>>
>>>
>>> ___
>>> Talk-it mailing list
>>> Talk-it@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Giovanni,

non capisco le relazioni h_stimata->height e h_misurata->height: non collidono? 
O forse nei dati originali l'esistenza di una misura implica l'assenza 
dell'altra?

Ciao,

Sergio


On 2018-11-08 14:30, Cascafico Giovanni wrote:
> Ho cercato di raccogliere i pareri di tutti sul tagging nella wiki [1] ed ho 
> aggiornato la mappa di revisione [2]. Domani vedo si compilarla... potete 
> partecipare tutti. Attenzione in particolare agli alberi con source diversa 
> da "Regione FVG". Nel dubbio, uno "skip" od un fixme non fa mai male :-)
>
> Se questo piccol import va bene, possiamo clonarlo senza troppe difficoltà 
> per le altre regioni.
>
>
> [1] 
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlberiMonumentali-RAFVG-opendata#Record_format_and_tagging_plan
> [2] http://audit.osmz.ru/project/AM-RAFVG-OO/
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

... nel caso ci siano entrambe, forse si potrebbe fare: h_misurata->height e 
h_stimata->height:estimate /(lo so, height:estimate sarebbe una "novità", ma 
non mi sembra male e si potrebbe documentare sul wiki../.)

Sergio


On 2018-11-08 14:44, Sergio Manzi wrote:
>
> Giovanni,
>
> non capisco le relazioni h_stimata->height e h_misurata->height: non 
> collidono? O forse nei dati originali l'esistenza di una misura implica 
> l'assenza dell'altra?
>
> Ciao,
>
> Sergio
>
>
> On 2018-11-08 14:30, Cascafico Giovanni wrote:
>> Ho cercato di raccogliere i pareri di tutti sul tagging nella wiki [1] ed ho 
>> aggiornato la mappa di revisione [2]. Domani vedo si compilarla... potete 
>> partecipare tutti. Attenzione in particolare agli alberi con source diversa 
>> da "Regione FVG". Nel dubbio, uno "skip" od un fixme non fa mai male :-)
>>
>> Se questo piccol import va bene, possiamo clonarlo senza troppe difficoltà 
>> per le altre regioni.
>>
>>
>> [1] 
>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlberiMonumentali-RAFVG-opendata#Record_format_and_tagging_plan
>> [2] http://audit.osmz.ru/project/AM-RAFVG-OO/
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Giovanni, scusa se "rompo" ancora, ma...

vedo "cose" che, forse, potrebbero essere migliorate. Per esempio, per l'albero 
al nodo https://www.openstreetmap.org/node/2124618451 (/chiaramente 
preesistente.../) verremmo ad avere anche queste key:

genus=Tilia
genus:de=Linde
genus:it=tiglio
genus:sl=lipa
name:botanical=Tilia
type=broad_leaved

  * "name:botanical" (/usato circa 25000 volte, globalmente/) è chiaramente una 
key obsoleta: non si potrebbe cogliere l'occasione per eliminarla?
  * Idem per i vari genus: si potrebbe eliminare "genus" e "genus:it" (/forse 
mantenendo i genus stranieri, per rispetto.../).
  * Ho dubbi sul "type": magari è anche giusto, ma non è ridondante?


On 2018-11-08 14:30, Cascafico Giovanni wrote:
> Ho cercato di raccogliere i pareri di tutti sul tagging nella wiki [1] ed ho 
> aggiornato la mappa di revisione [2]. Domani vedo si compilarla... potete 
> partecipare tutti. Attenzione in particolare agli alberi con source diversa 
> da "Regione FVG". Nel dubbio, uno "skip" od un fixme non fa mai male :-)
>
> Se questo piccol import va bene, possiamo clonarlo senza troppe difficoltà 
> per le altre regioni.
>
>
> [1] 
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlberiMonumentali-RAFVG-opendata#Record_format_and_tagging_plan
> [2] http://audit.osmz.ru/project/AM-RAFVG-OO/
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Giovanni, mi sembra che tu ti stia confondendo:

in base al wiki e all'audit che hai citati, il nome volgare va in "species:it" 
(nome_volga -> species:it), non "genus:it" (/e concordo!/).

Sergio

On 2018-11-08 16:17, Cascafico Giovanni wrote:
> Se non mi è sfuggito qualche post, genus:it è l'unica chiave che abbiamo 
> trovato dove  poter ficcare il nome volgare. 
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Martin, Volker,

... mi arrendo di fronte all'evidenza dei fatti!   :-)

Ciao,

Sergio


On 2018-11-08 17:32, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 8. Nov 2018, at 15:02, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
>> ... in realtà è già in uso (/ma non molto, vedi/ [1]) una key "est_height", 
>> ma personalmente continuo a pensare che height:estimate sia preferibile...
>>
>> [1] https://taginfo.openstreetmap.org/keys/est_height
>>
>
>
> per me è preferibile est_height, che non va fortissimo da solo, è vero, ma 
> guardando tutti gli “est” possibili, vedi che est_width va forte:
> https://taginfo.openstreetmap.org/search?q=est
>
> Ciao, Martin 
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Concordo, mi ha convinro:  mi sembra ragionevole rimandare le attività di 
"/pulizia di primavera/" ad un fase successiva all'import.

Ciao!

On 2018-11-08 16:17, Cascafico Giovanni wrote:
> ...
> Sul name:botanical, direi che esula da questo import: se approvato, potrebbe 
> essere fatto facilmente con un mass edit.
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Sì, è a quello che mi riferisco...


On 2018-11-08 22:27, Cascafico Giovanni wrote:
> Rispetto all'inizio della discussione ho poi proseguito la compilazione di 
> questa [1] pagina. Essa è simile, ma riferita ad un dataset leggermente 
> diverso ed esplicitamente odbl.
>
> [1] 
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlberiMonumentali-RAFVG-opendata#Record_format_and_tagging_plan
>
> Il gio 8 nov 2018, 22:19 Sergio Manzi mailto:s...@smz.it>> ha 
> scritto:
>
> Giovanni, mi sembra che tu ti stia confondendo:
>
> in base al wiki e all'audit che hai citati, il nome volgare va in 
> "species:it" (nome_volga -> species:it), non "genus:it" (/e concordo!/).
>
> Sergio
>
> On 2018-11-08 16:17, Cascafico Giovanni wrote:
>> Se non mi è sfuggito qualche post, genus:it è l'unica chiave che abbiamo 
>> trovato dove  poter ficcare il nome volgare. 
>>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org <mailto: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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Continuo a  non essere in grado a partecipare alla discussione  nella ML 
"tagging, ma in "pipermail" vedo che qualcuno ha fatto un'ottima proposta che 
ritengo essere preferibile a quella che avevo inizialmente fatto io:

>/Le 09. 11. 18 à 10:57, Lionel Giard a écrit : />/> You can also use 
height=* for both and add a "souce:height=estimated / />/> measured" tag with 
that to have a value that is usable by the apps and />/> tools but still 
keeping the information that it was only estimated ! ;-) /

Chiaramente c'è un piccolo "/orrore di stompa/", ma mi sembra che sia 
validissima la soluzione di indicare "sou_*r*_ce:height=estimated" quando è il 
caso.

Sergio


On 2018-11-09 12:09, Sergio Manzi wrote:
>
> ... forse potresti darmi una mano rispondendo al tuo stesso messaggio 
> (/adesso la risposta dovrebbe arrivarmi.../) e citando il fatto che qualcuno 
> nella ML italiana ha suggerito l'uso della subkey ...
>
>
> On 2018-11-09 11:54, Sergio Manzi wrote:
>>
>> Ah! Ben fatto!
>>
>> Adesso mi sono iscritto pure io alla ML tagging e, onestamente, vorrei 
>> contribuire con la mia proposta di utilizzare la sub-key "estimated", ma 
>> essendomi iscritto in un momento successivo all'invio del tuo messaggio, non 
>> sono in grado di rispondere... hai idea di come possa fare?
>>
>> Ciao,
>>
>> Sergio
>>
>>
>> On 2018-11-09 11:45, Cascafico Giovanni wrote:
>>> Il giorno gio 8 nov 2018 alle ore 15:04 Sergio Manzi >> <mailto:s...@smz.it>> ha scritto:
>>>
>>> ... in realtà è già in uso (/ma non molto, vedi/ [1]) una key 
>>> "est_height", ma personalmente continuo a pensare che height:estimate sia 
>>> preferibile...
>>>
>>>
>>> Per redere le cosa difficili, ho anche lanciato il sasso [1] anche nello 
>>> "stagno" dellla ML di tagging. 
>>>
>>> [1] 
>>> https://lists.openstreetmap.org/pipermail/tagging/2018-November/040767.html
>>>
>>> ___
>>> Talk-it mailing list
>>> Talk-it@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Ciao a tutti/e,

On 2018-11-13 11:20, Martin Koppenhoefer wrote:
> per me sarebbe sufficiente mettere "height", perché l'altezza di un albero 
> non può essere che stimata. Gli alberi sono flessibili, qualche varianza è 
> assolutamente normale.
>
... e per di più sembra che le misure, anche le misure indicate come 
effettuate, non stimate, siano abbastanza vecchiotte...

Non ho quindi nessun problema a vedere tutte le misure messe direttamente in 
"height" (sempre che non ci siano conflitti, casi in cui entrambe le misure 
sono indicate, ma non penso che ce ne siano)

In linea generale, comunque, penso che "accuracy:height=estimated" o 
"height:accuracy=estimated" () siano il modo corretto per indicare 
situazioni del genere, non una nota...

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [OT] Confini Croazia

[Sergio Manzi]

In realtà esistono delle differenze: un esempio (/ma ce ne sono altri/) è che 
la legge penale di uno stato non si estende alle sue acque territoriali quando 
il fatto avvenga/sia avvenuto su una nave battente bandiera differente da 
quella dello stato stesso, a meno di alcuni specifici casi previsti dalla 
"/Convenzione delle Nazioni Unite sul diritto del mare/" [1].

Sul fatto se, in OSM, sia opportuno o meno includere le acque territoriali nei 
confini amministrativi degli stati, sinceramente ho dei dubbi, anche perché 
penso che la cosa potrebbe essere facile causa di vari "/incidenti 
diplomatici/".

Sicuramente penso che sarebbe opportuno avere*anche* indicazioni su quale sia 
la "linea di base", cioè la linea (legale) di costa dalla quale poi derivano i 
diritti sulla fascia di mare antistante.

[1] 
https://it.wikipedia.org/wiki/Convenzione_delle_Nazioni_Unite_sul_diritto_del_mare


On 2018-11-06 11:07, emmexx wrote:
> On 11/05/2018 03:35 PM, Luca Delucchi wrote:
>> direi di si, anche l'italia se guardi è così [0]
>> ben o male le acque territoriali ricadono sotto l'amministrazione di
>> uno stato. Se vorresti ottenere i confini della terra ferma dovresti
>> esportare i confini delle regioni
> Forse non mi sono spiegato.
>
> Il problema è se da un punto di vista legale in questi paesi non c'è
> differenza amministrativa, non parlo solo del livello amministrativo
> nazionale, tra terraferma e acque territoriali.
>
> ciao
>   maxx
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [OT] Confini Croazia

[Sergio Manzi]

D'accordissimo, Alessandro, e in nessun modo dico che sia errato indicare i 
limiti delle acque territoriali degli stati, ma mi pongo dei dubbi e 
soprattutto, come già detto, penso che sarebbe opportuno avere anche un profilo 
del territorio definito dalla linea di base, cosa che mi sembra capire oggi non 
ci sia: qualcuno ha detto che per avere quello dell'Italia bisognerbbe sommare 
quelli delle regioni...

Inoltre mi sembra che il wiki preveda tag specifiche per i confini marittimi 
(/vedi /[1]).

Ciao,

Sergio

[1] https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dmaritime


On 2018-11-06 12:17, Alessandro P. wrote:
> Il 06/11/18 12:03, Sergio Manzi ha scritto:
>>
>> In realtà esistono delle differenze: un esempio (/ma ce ne sono altri/) è 
>> che la legge penale di uno stato non si estende alle sue acque territoriali 
>> quando il fatto avvenga/sia avvenuto su una nave battente bandiera 
>> differente da quella dello stato stesso, a meno di alcuni specifici casi 
>> previsti dalla "/Convenzione delle Nazioni Unite sul diritto del mare/" [1].
>>
>> Sul fatto se, in OSM, sia opportuno o meno includere le acque territoriali 
>> nei confini amministrativi degli stati, sinceramente ho dei dubbi, anche 
>> perché penso che la cosa potrebbe essere facile causa di vari "/incidenti 
>> diplomatici/".
>
> Pensa sempre a OSM come una mappa as-is. Vedi i confini disputati tra Italia 
> e Francia sul Monte Bianco.
> Le UN iniziano a usare OSM ma la prima cosa che fanno è togliere i confini di 
> OSM e applicargli i loro.
>
> Alessandro
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

... forse potresti darmi una mano rispondendo al tuo stesso messaggio (/adesso 
la risposta dovrebbe arrivarmi.../) e citando il fatto che qualcuno nella ML 
italiana ha suggerito l'uso della subkey ...


On 2018-11-09 11:54, Sergio Manzi wrote:
>
> Ah! Ben fatto!
>
> Adesso mi sono iscritto pure io alla ML tagging e, onestamente, vorrei 
> contribuire con la mia proposta di utilizzare la sub-key "estimated", ma 
> essendomi iscritto in un momento successivo all'invio del tuo messaggio, non 
> sono in grado di rispondere... hai idea di come possa fare?
>
> Ciao,
>
> Sergio
>
>
> On 2018-11-09 11:45, Cascafico Giovanni wrote:
>> Il giorno gio 8 nov 2018 alle ore 15:04 Sergio Manzi > <mailto:s...@smz.it>> ha scritto:
>>
>> ... in realtà è già in uso (/ma non molto, vedi/ [1]) una key 
>> "est_height", ma personalmente continuo a pensare che height:estimate sia 
>> preferibile...
>>
>>
>> Per redere le cosa difficili, ho anche lanciato il sasso [1] anche nello 
>> "stagno" dellla ML di tagging. 
>>
>> [1] 
>> https://lists.openstreetmap.org/pipermail/tagging/2018-November/040767.html
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Alberi monumenmtali] Quale licenza?

[Sergio Manzi]

Volker,

mi sembra proprio che ci sia: data_rilie -> survey:date


On 2018-11-09 11:31, Volker Schmidt wrote:
> Giovanni,
> mi sono letto un po' tutto, ma non vedo nessun accenno a un'informazione 
> essenziale in tutta questa discussione: la data di rilevamento. Un albero 
> cresce in continuazione. L'altezza non ha nessun valore senza la data della 
> misura o stima.
> Volker
>
> On Wed, 17 Oct 2018 at 11:30, Cascafico Giovanni  > wrote:
>
> Dopo aver letto il certosino lavoro [1] fatto da Borruso nel portare un 
> po' d'ordine nei vari documenti excel pubblicati dal ministero, sto cercando 
> di capire qualse sia la licenza applicata.
>
> Nei pdf ministeriali [2] si scrive di approvazioni ed aggiornamenti che 
> le regioni sono demandate a trasmettere al mipaaf, ma non si fa alcun cenno 
> alla licenza.
>
> Così ho scaricato ed analizzato i dataset relativi al Friuli Venezia 
> Giulia nelle loro due origini: Mipaaf (licenza indefinita) e regione FVG 
> (public data).
>
> Sembra che il Mipaaf sia un sottoinsieme di quello della regione FVG: 
> quest'ultimo ha un paio di campi in più ed è stato arricchiito di ulteriori 
> alberi.
>
> Per la licenziabilità, secondo voi cosa si può dedurre?
>
> Potrei importare i dati "public" della regione FVG ma, nell'ottica di non 
> rifare il lavoro per altre regioni, preferirei attingere dal Mipaaf perchè 
> almeno ha le cose nello stesso posto e (per quanto in discutibili strutture 
> excel) parrebbe usare gli stessi campi.
>
> Per inquadrare l'import ho imbastito la wiki [3].
>
>
> [1] 
> https://medium.com/tantotanto/dove-sono-gli-alberi-monumentali-ditalia-ffd7d0d6d860
> [2] 
> https://www.politicheagricole.it/flex/cm/pages/ServeBLOB.php/L/IT/IDPagina/11260
> [3] 
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlberiMonumentali-RAFVG
> ___
> 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


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Ah! Ben fatto!

Adesso mi sono iscritto pure io alla ML tagging e, onestamente, vorrei 
contribuire con la mia proposta di utilizzare la sub-key "estimated", ma 
essendomi iscritto in un momento successivo all'invio del tuo messaggio, non 
sono in grado di rispondere... hai idea di come possa fare?

Ciao,

Sergio


On 2018-11-09 11:45, Cascafico Giovanni wrote:
> Il giorno gio 8 nov 2018 alle ore 15:04 Sergio Manzi  <mailto:s...@smz.it>> ha scritto:
>
> ... in realtà è già in uso (/ma non molto, vedi/ [1]) una key 
> "est_height", ma personalmente continuo a pensare che height:estimate sia 
> preferibile...
>
>
> Per redere le cosa difficili, ho anche lanciato il sasso [1] anche nello 
> "stagno" dellla ML di tagging. 
>
> [1] 
> https://lists.openstreetmap.org/pipermail/tagging/2018-November/040767.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

+1000!!

On 2018-11-09 11:39, Cascafico Giovanni wrote:
> Il giorno gio 8 nov 2018 alle ore 16:17 Cascafico Giovanni 
> mailto:cascaf...@gmail.com>> ha scritto:
>
> Se non mi è sfuggito qualche post, genus:it è l'unica chiave che abbiamo 
> trovato dove  poter ficcare il nome volgare. 
> Il type credo sia un errore... sarebbe leaf_type ed eventualmente il suo 
> compare leaf_cycle.
> Sul name:botanical, direi che esula da questo import: se approvato, 
> potrebbe essere fatto facilmente con un mass edit.
>
>
> Ho approfittato del problema segnalato sul "type" per natural=tree. Ho voluto 
> strafare con un mass edit [1].
>
> Nota a margine: il tag obsoleto "type" è un problema anche per il funzione si 
> selezione di JOSMm, che interpreta la query come tipo di elemento (nodo, way 
> e relazione).
>
>
> [1] https://www.openstreetmap.org/changeset/64320309
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Penso che in fin dei conti sia soprattutto importante arricchire il DB di 
informazioni utili, di buona qualità, e identificabili.

In questo caso, la scelta tra est_height (/non documentato, ma utilizzato/) o 
height:estimated (/sostanzialmento mai utilizzato, ma //a mio avviso 
sintatticamente preferibile/) non è poi così importante.

Un giorno o l'altro, chissà, qualcuno potrà decidere di mettere un po' d'ordine 
in casa e trasformare tutti gli est_height in height:estimated, o viceversa, a 
seconda di quel che si sarà deciso.


On 2018-11-09 08:49, Cascafico Giovanni wrote:
> A parte taginfo, non trovo nessuna documantazione su est_height. Credo siamo 
> in territorio "grigio" di OSM... qualcuno ha documentato est_width, ma 
> nessuno est_height ne' est_length. Che si fa?
>
> Il giorno gio 8 nov 2018 alle ore 15:04 Sergio Manzi  <mailto:s...@smz.it>> ha scritto:
>
> ... in realtà è già in uso (/ma non molto, vedi/ [1]) una key 
> "est_height", ma personalmente continuo a pensare che height:estimate sia 
> preferibile...
>
> [1] https://taginfo.openstreetmap.org/keys/est_height
>
>
> On 2018-11-08 14:53, Sergio Manzi wrote:
>>
>> ... nel caso ci siano entrambe, forse si potrebbe fare: 
>> h_misurata->height e h_stimata->height:estimate /(lo so, height:estimate 
>> sarebbe una "novità", ma non mi sembra male e si potrebbe documentare sul 
>> wiki../.)
>>
>> Sergio
>>
>>
>> On 2018-11-08 14:44, Sergio Manzi wrote:
>>>
>>> Giovanni,
>>>
>>> non capisco le relazioni h_stimata->height e h_misurata->height: non 
>>> collidono? O forse nei dati originali l'esistenza di una misura implica 
>>> l'assenza dell'altra?
>>>
>>> Ciao,
>>>
>>> Sergio
>>>
>>>
>>> On 2018-11-08 14:30, Cascafico Giovanni wrote:
>>>> Ho cercato di raccogliere i pareri di tutti sul tagging nella wiki [1] 
>>>> ed ho aggiornato la mappa di revisione [2]. Domani vedo si compilarla... 
>>>> potete partecipare tutti. Attenzione in particolare agli alberi con source 
>>>> diversa da "Regione FVG". Nel dubbio, uno "skip" od un fixme non fa mai 
>>>> male :-)
>>>>
>>>> Se questo piccol import va bene, possiamo clonarlo senza troppe 
>>>> difficoltà per le altre regioni.
>>>>
>>>>
>>>> [1] 
>>>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlberiMonumentali-RAFVG-opendata#Record_format_and_tagging_plan
>>>> [2] http://audit.osmz.ru/project/AM-RAFVG-OO/
>>>>
>>>>
>>>> ___
>>>> Talk-it mailing list
>>>> Talk-it@openstreetmap.org <mailto:Talk-it@openstreetmap.org>
>>>> https://lists.openstreetmap.org/listinfo/talk-it
>>>
>>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org <mailto: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


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Evoluzione della mappa

[Sergio Manzi]

Grazie Martin!


On 2018-11-04 15:27, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 4. Nov 2018, at 11:52, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
>> geofabrik, ma quest'ultimo mi sembra fornisca solo files monolitici ed 
>> enormi per i vari continenti e solo quelli "/correnti/"...
>
>
> geofabrik ha anche estratti più piccoli (tipo un terzo dell’Italia), con 
> osmium tool puoi ritagliare files grossi in aree più piccole, per poca roba 
> invece è preferibile overpass.
>
> Ciao, Martin 
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Giunto condotta forzata

[Sergio Manzi]

Quello direi che è un blocco di ancoraggio...

I giunti, che io sappia, servono a permettere le dilatazioni termiche della 
condotta (cosa che ovviamente non può avvenire all'interno del blocco di 
cemento).

Per esempio vedi qui: 
https://www.trevitec.com/giunti-di-dilatazione-a-cannocchiale.html

Ciao,

Sergio


On 2018-10-02 16:01, demon.box wrote:
> ciao, chiedo una "consulenza tecnica" visto che sono un ragioniere (mancato
> per fortuna...)
>
> il giunto della condotta forzata è quel blocco in cemento che si vede in
> questa foto?
>
>  
>
> grazie
>
> --enrico
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it




smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sentiero senza uscita

[Sergio Manzi]

Direi sia la 2) che la 3), ma non la 1)  perché la way che termina con il 
cancello non è di per se privata o quanto meno non è indicata come tale...


On 2018-09-29 00:47, Andrea Albani wrote:
>
>
> Il sab 29 set 2018, 00:38 demon.box  > ha scritto:
>
> 1) access=private sulla way?
> 2) noexit=yes sulla way?
>
> che dite?
>
>
> Voto per
>
> 3) barrier=gate e access=private sul nodo del cancello
>
> Che descrive in modo asettico la situazione. Altrimenti 
> 1) se proprio non vuoi far sfacchinare le persone per 800m
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Come li mappereste voi?

[Sergio Manzi]

Ciao!

Il secondo "oggetto" che hai segnalato 
(http://gis.19327.n8.nabble.com/file/t339261/lozio2.jpg) è senza dubbio un 
lavatoio, praticamente identico ad uno che conosco bene, a Predazzo (TN) 
https://www.openstreetmap.org/node/303826369 e che è mappato come 
amenity:drinking_water.

Sono anni che non lo vedo usato per la sua funzione originale (/ora ci sono le 
lavatrici!/) e senza dubbio la funzione attuale è quella di poterci bere.

Nel wiki non vedo nulla che possa assomigliare neanche vagamente a "lavatoio" e 
anche cercando su Taginfo per "wash" non salta fuori niente di buono: 
https://taginfo.openstreetmap.org/search?q=wash

Io lo taggerei come amenity:drinking_water.

Alcuni degli altri che hai segnalato sembrano essere cose diverse: abbeveratoi 
(/che pure taggerei come amenity:drinking_water/) e/o pozzetti dalla dubbia 
funzione...

Ancora ciao,

Sergio


On 2018-10-01 18:54, demon.box wrote:
> il problema è che tante volte ci sono piccole vasche che non sò se mappare
> come amenity=watering_place o cos'altro
> altra carrellata di esempi:
>
>  
>
>  
>
>  
>
>  
> (tralasciate la scritta "ACQUA NON POTABILE" cosa assolutamente non vera...)
>
> grazie
>
> --enrico
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Come li mappereste voi?

[Sergio Manzi]

Caspita, mi ero perso la segnalazione di Andrea: amenity:lavoir!!

Ci stà, senza dubbio, anche se come ti dicevo ora come ora probabilmente se ne 
è persa la funzione originale e servono... a bere (e forse può fare più comodo 
che sia segnalata questa funzione, piuttosto che quella di lavatoio...)


On 2018-10-01 19:15, Sergio Manzi wrote:
>
> Ciao!
>
> Il secondo "oggetto" che hai segnalato 
> (http://gis.19327.n8.nabble.com/file/t339261/lozio2.jpg) è senza dubbio un 
> lavatoio, praticamente identico ad uno che conosco bene, a Predazzo (TN) 
> https://www.openstreetmap.org/node/303826369 e che è mappato come 
> amenity:drinking_water.
>
> Sono anni che non lo vedo usato per la sua funzione originale (/ora ci sono 
> le lavatrici!/) e senza dubbio la funzione attuale è quella di poterci bere.
>
> Nel wiki non vedo nulla che possa assomigliare neanche vagamente a "lavatoio" 
> e anche cercando su Taginfo per "wash" non salta fuori niente di buono: 
> https://taginfo.openstreetmap.org/search?q=wash
>
> Io lo taggerei come amenity:drinking_water.
>
> Alcuni degli altri che hai segnalato sembrano essere cose diverse: 
> abbeveratoi (/che pure taggerei come amenity:drinking_water/) e/o pozzetti 
> dalla dubbia funzione...
>
> Ancora ciao,
>
> Sergio
>
>
> On 2018-10-01 18:54, demon.box wrote:
>> il problema è che tante volte ci sono piccole vasche che non sò se mappare
>> come amenity=watering_place o cos'altro
>> altra carrellata di esempi:
>>
>> <http://gis.19327.n8.nabble.com/file/t339261/IMG_0493_%281024_x_768%29.jpg> 
>>
>> <http://gis.19327.n8.nabble.com/file/t339261/IMG_0498_%281024_x_768%29.jpg> 
>>
>> <http://gis.19327.n8.nabble.com/file/t339261/IMG_0509_%281024_x_768%29.jpg> 
>>
>> <http://gis.19327.n8.nabble.com/file/t339261/IMG_0949_%281024_x_768%29.jpg> 
>> (tralasciate la scritta "ACQUA NON POTABILE" cosa assolutamente non vera...)
>>
>> grazie
>>
>> --enrico
>>
>>
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] SENTIERO NON PERCORRIBILE

[Sergio Manzi]

Mah... io inizialmente avevo capito che si doveva trattare di un oggetto (nodo) 
separato, ma sono andato a rivedermi il wiki [1] e vedo che è esplicitamente 
detto che: "Use only on already existing highway=* or waterway=*, since this is 
a property of the usability of the way. For separate ("wayless") obstacles 
please use the barrier=* key.", cioè va applicato esclusivamente a 
higway/waterway preesistenti.

SE così è, però, "obstacle" diventa solo un attributo della way (tutto il 
sentiero in questo caso?) e non ne viene data una precisa geolocalizzazione.

SE il sentiero è realmente interrotto in quel punto, quello che FORSE sarebbe 
corretto fare sarebbe di "spezzare" la way introducendo un nuovo segmento 
(lungo quanto è giusto...) che la separi nei due tronconi, assegnare a quella 
way lo stesso nome del sentiero, darle la key "obstacle" e mettere foot=no in 
modo da interrompere eventuali routing perché obstacle, di per se, indica solo 
una "ostruzione", difficoltà di passaggio, e non implica necessariamente una 
interruzione, almeno a quanto detto nella PROPOSTA della key [2] ("Objective 
obstacles in a path (or highways) that *difficult the passability*").

Riguardo all'uso di access=no, che effettivamente sembra più una restrizione di 
tipo legale-amministrativo, avevo trovato da qualche parte l'indicazione di 
usarla con obstacle, ma devo ammettere che allo stato attuale non sono più in 
grado di ricordarmi (Alzehimer?) dove, né di ri-trovarla...

[1] https://wiki.openstreetmap.org/wiki/Key:obstacle
[2] https://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle


On 2018-08-30 15:40, Roberto Brazzelli wrote:
> ok grazie, ma si crea nodo in corrispondenza dell'ostacolo o sulla way 
> aggiungo 
> il tag  obstacle=fallen_tree?
>
> Roberto
>
> Il giorno gio 30 ago 2018 alle ore 10:30 Alfredo Gattai 
> mailto:alfredo.gat...@gmail.com>> ha scritto:
>
> Piu' cose si mettono, piu' diventa oneroso mantenere il DB e piu' 
> problemi si creano alle varie app che usano i dati.
> Chi si trovera' a ripristinare la percorribilita' potrebbe non essere un 
> osmer quindi essere ignaro che esiste un DB da aggiornare.
> Anche se fosse un osmer potrebbe non accorgersi di tutti i tag da 
> modificare in base alla nuova condizione
> Invece se ci limitiamo a mettere obstacle=il tipo di ostacolo, chi 
> successivamente lo trovasse sgombro avrebbe vita facile a fare la modifica.
> Per quanto riguarda access=no, andrebbe messo solo se ci sono transenne 
> e/o cartelli che vietano l'accesso.
> Spesso poi accade che certe situazioni si risolvano col tempo a suon di 
> passare di lato all'ostruzione quindi i casi dove c'e' una vera interruzione 
> dove la soluzione di Volker si applica bene sono quelle dove sono franati 
> ponti o si sono create lunghe voragini inaggirabili.
>
> Alfredo
>
>
> Il gio, 30 agosto 2018 alle 9:54 Volker Schmidt 
> < vosc...@gmail.com > ha scritto:
>
> Io interromperei il sentiero in posizione dell'ostacolo, Per indicare 
> che non si passa con nessun modo di trasporto aggiungerei noexit=yes su 
> entrambi nuovi nodi finali.
>
>
>
> __ _
> mailing list Talk-it
> Talk-it@openstreetmap.org 
> https: //lists.openstreetmap. org / listinfo / Talk-it 
> 
>
> __ _
> mailing list Talk-it
> Talk-it@openstreetmap.org 
> https: //lists.openstreetmap.or g / listinfo / talk-it 
> 
>
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Samuel

[Sergio Manzi]

Ciao Samuel,

come probabilmente saprai OpenStreetMap (OSM per gli amici...) è un progetto 
collaborativo, un database geografico (GIS) alimentato principalmente dal 
lavoro di volontari che giornalmente si impegnano per arricchirlo di "oggetti": 
è possibile che quello che cerchi non sia ancora stato mappato qui.

Esistono dei "/derivati/" specializzati per settori di attività, come per 
esempio Waymarked Trails (per i *sentieri* da percorrere *a piedi*) o 
OpenCycleMap (https://www.opencyclemap.org/) per chi si muove in bicicletta (/e 
dove neppure è visibile il percorso che segnali e che è tracciato nel sito che 
hai citato/).

Tra l'altro il "tuo" sito prevede nella mappa anche un layer di OpenCycleMap, 
ma apparentemente hanno un incasinato po' le cose, perché evidentemente gli 
manca la chiave di accesso per poter visualizzare quel layer.

Quindi, qui, "in questo universo", allo stato attuale, mi sembra che non ci sia 
quel che cerchi, ma... quando farai il tuo giro, se ti va, potresti portarti 
dietro un GPS (o uno smartphone con adeguata applicazione) e raccogliere tu la 
traccia del percorso e poi contribuire a questo progetto aggiungendola.

In alternativa /qualcuno /potrebbe contattare i gestori di the.mtb.biker e 
verificare la loro disponibilità a contribuire a OpenStreetMap fornendo i dati 
di quel percorso che loro hanno tracciato e "rilasciandolo" secondo i termini 
della licenza di OSM (vedi https://it.wikipedia.org/wiki/OpenStreetMap#Licenza).

Buona giornata e buona pedalata (quando sarà...)

Sergio


On 2018-09-22 13:14, Samuel Liuzzo wrote:
> Le mando la mappa http://www.themtbbiker.com/tour-du-mont-blanc.html# 
>
>
> Inviato da iPhone
>
> Il giorno 22 set 2018, alle ore 12:24, liste DOT girarsi AT posteo DOT eu 
> mailto:liste.gira...@posteo.eu>> ha scritto:
>
>> Il 22/09/2018 11:51, Samuel Liuzzo ha scritto:
>>>  No,avrei bisogno un po’ di informazioni sui sentieri sul giro monte bianco 
>>> ,potete aiutarmi?
>>
>> Prova vedi qui:
>>
>> https://hiking.waymarkedtrails.org/#?map=13!45.8712!6.8701 
>> 
>>
>> -- 
>> _|_|_|_|_|_|_|_|_|_
>> |_|_|_|_|_|_|_|_|_|_|
>> Simone Girardelli
>>
>> ___
>> 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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [tagging] Bed e categorie

[Sergio Manzi]

La verità? Perché ne abbiamo le pa..e strapiene di B, bar, negozi di 
mascherine di carnevale (/albanesi o cinesi/), vetri del Marocco, trattorie 
venefiche e pizze al trancio di polistirolo...


On 2018-11-16 16:00, Martin Koppenhoefer wrote:
>
>
> Am Fr., 16. Nov. 2018 um 15:58 Uhr schrieb Sergio Manzi  <mailto:s...@smz.it>>:
>
> ... Taggandoli tutti, qui a Venezia la mappa diventerebbe un unico blob 
> di B
>
>
>
> già, ma questa è la vostra realtà, perché nasconderla ;-)
>
> Ciao,
> Martin
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [tagging] Bed e categorie

[Sergio Manzi]

Cosa posso dirti... capisco, ma anche se si tratta di fonte ufficiale io 
(/posizione personalissima.../) non li taggerei, anche perché in questo settore 
c'è una volatilità altissima e tenere i dati aggiornati diventerebbe "un 
lavoro".

Mi auguro solo che la Regione Veneto non pubblichi nulla del genere...

Ciao!

Sergio


On 2018-11-16 16:04, Cascafico Giovanni wrote:
> È una fonte ufficiale.
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/BB-RAFVG
>
> Il ven 16 nov 2018, 15:58 Sergio Manzi mailto:s...@smz.it>> ha 
> scritto:
>
> Mi sembra una proposta molto valida!
>
> Sergio
>
> P.S.: Personalmente ci andrei coi piedi di piombo a taggare i B (/e 
> forse, anzi, non li taggerei proprio/). Come minimo *_verificherei_* che il 
> B abbia una propria identità visibile (/targa fuori della porta/) e in 
> tutta sincerità penso sarebbe più utile taggare il n. civico (/se già non ci 
> fosse/) e basta. Taggandoli tutti, qui a Venezia la mappa diventerebbe un 
> unico blob di B
>
>
> On 2018-11-16 15:49, Martin Koppenhoefer wrote:
>>
>> ...
>>
>> chi le ha definite? Il mio "favorite" è uno schema bocciato anni fa, o 
>> al meno non ha preso piede ;-)
>> che va così:
>> award:=
>>
>> per esempio:
>> award:hotelstars=4stars
>>
>> (hotelstars è il nome di una ditta/associazione, non è una descrizione)
>>
>> https://taginfo.openstreetmap.org/search?q=award
>>
>> Ciao,
>> Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org <mailto: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


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [tagging] Bed e categorie

[Sergio Manzi]

Mi sembra una proposta molto valida!

Sergio

P.S.: Personalmente ci andrei coi piedi di piombo a taggare i B (/e forse, 
anzi, non li taggerei proprio/). Come minimo *_verificherei_* che il B abbia 
una propria identità visibile (/targa fuori della porta/) e in tutta sincerità 
penso sarebbe più utile taggare il n. civico (/se già non ci fosse/) e basta. 
Taggandoli tutti, qui a Venezia la mappa diventerebbe un unico blob di B


On 2018-11-16 15:49, Martin Koppenhoefer wrote:
>
> ...
>
> chi le ha definite? Il mio "favorite" è uno schema bocciato anni fa, o al 
> meno non ha preso piede ;-)
> che va così:
> award:=
>
> per esempio:
> award:hotelstars=4stars
>
> (hotelstars è il nome di una ditta/associazione, non è una descrizione)
>
> https://taginfo.openstreetmap.org/search?q=award
>
> Ciao,
> Martin


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Parchimetri a Perugia

[Sergio Manzi]

Ciao!

Direi che usare nuove chiavi come parcometro=* e settore=* è _senza dubbio_ da 
evitare: sarebbe preferibile fossero approvate dalla comunità, dopo adeguata 
proposta e votazione e devono essere in Inglese Britannico.

network=* mi sembra dedicato ad altri scopi [1]

Mi sembra bene il ref=10-135

Sergio


[1] https://wiki.openstreetmap.org/wiki/Key:network

On 2018-12-13 17:27, claudio62PG wrote:
> Varie proposte
>
> Parcometro=135
> amenity=vending_machine
> settore=10
> vending=parking_tickets
>
>
> amenity=vending_machine
> vending=parking_tickets
> ref=10-135
>
>
> amenity=vending_machine
> vending=parking_tickets
> ref=135
> network=10
>
>
> Opinioni ?
> ciao 
> Claudio
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] utilizzo di noexit=yes

[Sergio Manzi]

... manata in fronte! Ovvio, hai ragione!

Ma certo che bisogna essere un po' perversi, però...   :-)


On 2018-12-13 21:22, Andrea Albani wrote:
>
>
> Il giorno gio 13 dic 2018 alle ore 20:46 Sergio Manzi  <mailto:s...@smz.it>> ha scritto:
>
>
> Inoltre non riesco a capire perché a qualcuno sia venuto in mente di 
> ragionare in logica negata: noexit=yes === exit=no, che mi sembrerebbe di più 
> chiara ed immediata comprensione (/ma comunque inutile/).
>
> Penso derivi dal fatto che in inglese un cartello di strada chiusa è un "no 
> exit" sign
>  
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] utilizzo di noexit=yes

[Sergio Manzi]

La mia perplessità, nella frase che hai citato, era relativa al fatto che si è 
preferito usare una logica del tipo "(*è vero*) (che questa strada *non ha* 
uscita)" rispetto all'altra possibilità, equivalente, "(*non è vero*) (che 
questa strada *ha* una uscita)".

Per il resto, penso sarebbe preferibile un fixme=*

E' vero che in https://wiki.openstreetmap.org/wiki/Key:fixme si dice che si può 
(deve???) mappare "/noexit=no — For tagging incomplete ways (not completely 
surveyed) as such/", ma trovo la cosa assolutamente priva di senso: nexit=no, 
se la logica non è un'opinione, vuol dire che la strada ha una uscita.

Ciao!


On 2018-12-13 23:44, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 13. Dec 2018, at 20:46, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
>> Inoltre non riesco a capire perché a qualcuno sia venuto in mente di 
>> ragionare in logica negata: noexit=yes === exit=no, che mi sembrerebbe di 
>> più chiara ed immediata comprensione (/ma comunque inutile/).
>
>
> è un flag: Strada senza uscita -> si
>
> Non è del tutto inutile in quanto si tratta di un tag per altri mappatori: lì 
> è verificato che non ci sia altra uscita (vuol dire mappatura completa, 
> perché in OSM non sai mai se non c’è strada oppure non è mappata.) Nella 
> prassi, la situazione potrebbe essere cambiata, quindi che fai, non verifichi 
> comunque ;-)
>
>
> Ciao, Martin 
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] utilizzo di noexit=yes

[Sergio Manzi]

Trovata, qui: https://wiki.openstreetmap.org/wiki/Tag%3Anoexit%3Dno ed è 
deprecata, a favore di fixme=continue

Peccato, la hic_sunt_leones mi piaceva...

Ciao!


On 2018-12-14 00:34, Sergio Manzi wrote:
>
> Tra l'altro, nella pagina wiki per noexit [1] (/che dovrebbe essere 
> autoritativa per quella tag/), non si fa nessuna menzione dell'uso 
> esoterico/iniziatico di "noexit=no" ad indicare una way di cui... non si sa 
> dove vada a finire.
>
> Nell'orma della migliore tradizione cartografica, potremmo proporre una nuova 
> chiave here_be_dragons=yes [2] oppure hic_sunt_leones=yes [3] come valida 
> alternativa per quelle situazioni...   :-))
>
> Ciao!
>
> [1] https://wiki.openstreetmap.org/wiki/Key:noexit
> [2] https://en.wikipedia.org/wiki/Here_be_dragons
> [3] https://it.wikipedia.org/wiki/Hic_sunt_leones
>
>
> On 2018-12-13 23:58, Sergio Manzi wrote:
>>
>> La mia perplessità, nella frase che hai citato, era relativa al fatto che si 
>> è preferito usare una logica del tipo "(*è vero*) (che questa strada *non 
>> ha* uscita)" rispetto all'altra possibilità, equivalente, "(*non è vero*) 
>> (che questa strada *ha* una uscita)".
>>
>> Per il resto, penso sarebbe preferibile un fixme=*
>>
>> E' vero che in https://wiki.openstreetmap.org/wiki/Key:fixme si dice che si 
>> può (deve???) mappare "/noexit=no — For tagging incomplete ways (not 
>> completely surveyed) as such/", ma trovo la cosa assolutamente priva di 
>> senso: nexit=no, se la logica non è un'opinione, vuol dire che la strada ha 
>> una uscita.
>>
>> Ciao!
>>
>>
>> On 2018-12-13 23:44, Martin Koppenhoefer wrote:
>>>
>>>
>>> sent from a phone
>>>
>>> On 13. Dec 2018, at 20:46, Sergio Manzi mailto:s...@smz.it>> 
>>> wrote:
>>>
>>>> Inoltre non riesco a capire perché a qualcuno sia venuto in mente di 
>>>> ragionare in logica negata: noexit=yes === exit=no, che mi sembrerebbe di 
>>>> più chiara ed immediata comprensione (/ma comunque inutile/).
>>>
>>>
>>> è un flag: Strada senza uscita -> si
>>>
>>> Non è del tutto inutile in quanto si tratta di un tag per altri mappatori: 
>>> lì è verificato che non ci sia altra uscita (vuol dire mappatura completa, 
>>> perché in OSM non sai mai se non c’è strada oppure non è mappata.) Nella 
>>> prassi, la situazione potrebbe essere cambiata, quindi che fai, non 
>>> verifichi comunque ;-)
>>>
>>>
>>> Ciao, Martin 
>>>
>>>
>>>
>>> ___
>>> Talk-it mailing list
>>> Talk-it@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] utilizzo di noexit=yes

[Sergio Manzi]

Ciao a tutti/e,

Sinceramente noexit=yes mi sembra un tagging assurdo: la topologia non è 
un'opinione e se una strada abbia o meno una uscita (/e per quali mezzi di 
trasporto!/) lo si desume tranquillamente dalle relazioni con le altre ways.

Inoltre non riesco a capire perché a qualcuno sia venuto in mente di ragionare 
in logica negata: noexit=yes === exit=no, che mi sembrerebbe di più chiara ed 
immediata comprensione (/ma comunque inutile/).

Per quanto riguarda sentieri/piste a tratti invisibili, sono totalmente 
d'accordo con Volker: vanno mappati ed indicati con trail_visibility=no, perché 
in caso contrario si interromperebbe un utilissimo e validissimo "routing" 
(/sia che sia automatizzato o "ad occhio"/).

Sergio


On 2018-12-13 16:59, Max1234Ita wrote:
> Andrea Albani wrote
>> noexit è un tag che, pur avendolo usato qualche volta, mi ha sempe
>> lasciato
>> freddo e per me non è così scontato che si debba per forza mettere quando
>> una strada termina.
>>
>> E' un dato di fatto che una strada finisce sull'ultimo nodo non connesso
>> della way che la rappresenta, e questo i motori di routing immagino lo
>> sappiano bene.
>>
>> Ci rimane il fattore rendering, ovvero comunicare visivamente ad un utente
>> questo dead-end. Quindi nel caso di questo tag posso mappare per il
>> rendering ?
> Non è solo mappare per il rendering, è anche un'informazione utile che dai
> anche all'utente ed al routing, ad esempio nel caso in cui la strada termina
> ma a poca distanza ce n'è un'altra percorribile, ad esempio una via che è
> tagliata alla fine da un fosso ma oltre il fosso corre la Strada
> Provinciale: poco importa se con un salto un pedone un po' agile può
> riuscire a passare dall'altra parte...
> In questo caso noexit indica espressamente che non c'è via d'uscita e non si
> tratta di un problema di scarsa/nulla mappatura...
>
> Per i casi "liquidi", invece, di solito preferisco tracciare il sentiero fin
> dove lo si può vedere, e po lasciarlo aperto, a finire "nel nulla"... come
> in effetti è.
>
> Ciao,
> Max
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] utilizzo di noexit=yes

[Sergio Manzi]

Certo, è di quello che si stava parlando!

Il noexit=yes, invece, è topologicamente inutile. Ma se a qualcuno piace 
tanto... che faccia pure: no problem per me!

Sergio


On 2018-12-20 12:59, Martin Koppenhoefer wrote:
>
>
> Am Mi., 19. Dez. 2018 um 12:10 Uhr schrieb Sergio Manzi  <mailto:s...@smz.it>>:
>
> ... e, come già segnalato, da tempo deprecato a favore del 
> fixme=continue: https://wiki.openstreetmap.org/wiki/Tag%3Anoexit%3Dno
>
> In teoria, poi, sì che col tempo dovrebbero "andare via", visto che erano 
> utilizzati ad indicare situazioni di mappatura incompleta, che mi auguro 
> tenderanno ad essere risolte.
>
>
>
>
> quello che è deprecato è il tag noexit=no, un tag privo di senso.
> noexit=yes non è deprecato, è usato mezzo millione di volte e cresce sempre.
> https://wiki.openstreetmap.org/wiki/Key:noexit
>
> Ciao,
> Martin
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Caricamento JOSM in ambiente MAc

[Sergio Manzi]

Ah... :-(

Sorry, lo proverò...

Per me è importante avere il browser "de-javizzato"...

Sergio


On 2018-12-20 15:01, Andrea Musuruane wrote:
> Guardate che avete una errata comprensione di Java Web Start: 1) non richiede 
> di aver alcun plugin installato nel browser 2) non dovete usare un browser 
> dopo il primo avvio.
>
> Ciao,
>
> Andrea
>
>
> On Thu, Dec 20, 2018 at 2:56 PM Sergio Manzi  <mailto:s...@smz.it>> wrote:
>
> ... aspetto su cui concordo totalmente!
>
> On 2018-12-20 14:53, Martin Koppenhoefer wrote:
> > e non devo attivare java nel browser, ne avviare un web browser.
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org <mailto: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


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Caricamento JOSM in ambiente MAc

[Sergio Manzi]

... aspetto su cui concordo totalmente!

On 2018-12-20 14:53, Martin Koppenhoefer wrote:
> e non devo attivare java nel browser, ne avviare un web browser.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it