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

[Gabriele Sani]

Ok, quindi una casa singola che ha un nome ma e' abbandonata posso usare
locality?

Il giorno mer 31 ott 2018 alle ore 18:47 Volker Schmidt 
ha scritto:

> Certo, il place= locality o abandoned:place=hamlet non va sugli edifici.
> E' un nodo assestante nel centro di questo gruppo di case più o meno
> crollati.
>
> On Wed, 31 Oct 2018 at 18:41, aldoct  wrote:
>
>> Il wiki così recita: "locality" Località non abitata identificabile con un
>> nome. Parla dunque di località e non di edifici. Ritengo sia corretto
>> attribuire tale TAG alle "contrade" e non a singoli edifici,
>> Saluti
>>
>>
>>
>> --
>> 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
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Volker Schmidt]

Certo, il place= locality o abandoned:place=hamlet non va sugli edifici. E'
un nodo assestante nel centro di questo gruppo di case più o meno crollati.

On Wed, 31 Oct 2018 at 18:41, aldoct  wrote:

> Il wiki così recita: "locality" Località non abitata identificabile con un
> nome. Parla dunque di località e non di edifici. Ritengo sia corretto
> attribuire tale TAG alle "contrade" e non a singoli edifici,
> Saluti
>
>
>
> --
> 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

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

[Damjan Gerl]

  
  
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à.
  
  Damjan
   
  
  31.10.2018 - 18:10 - danbag:


  
  In VCO usiamo proprio locality nei casi che tu hai citato. Anche
  noi abbiamo molti alpeggi alcuni solo ruderi altri abitati solo
  per villeggiatura ed entrambi li taggo con locality.
  Ciao
  
  
  
 Messaggio originale 
Da: Gabriele Sani  
Data: 31/10/18 16:42 (GMT+01:00) 
A: openstreetmap list - italiano
   
Oggetto: [Talk-it] case sparse vs localita' 


  
  

  Buonasera, una rapida domanda prima di fare modifiche:
  capita spesso nelle zone appenniniche vicino a dove vivo
di imbattersi in vecchie case/ville abbandonate. Alcune sono
in buono stato, ma non abitate, altre sono praticamente
crollate e rimangono i muri e poco piu'. Molte di queste
sono taggate come locality... e' il tag piu' corretto?
  Vedo sulla wiki [1] che c'e'/c'era l'abitudine ad usarla
per obbligare il renderer a mostrarla... cosa ne pensate?
  
  
  Grazie mille
  
  
  [1] https://wiki.openstreetmap.org/wiki/Tag:place=locality#Don.27t_use_place.3Dlocality_just_to_force_a_name_to_appear_on_a_featur
  

  
  


  


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

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

[aldoct]

Il wiki così recita: "locality" Località non abitata identificabile con un
nome. Parla dunque di località e non di edifici. Ritengo sia corretto
attribuire tale TAG alle "contrade" e non a singoli edifici,
Saluti



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

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

[Volker Schmidt]

place=locality è ampiamente utilizzato negli USA per indicare dei ghost
towns *senza* resti.(uno che ho "visitato" due o tre volte è Bagdad,
California , famoso dal film
"Bagdad Café", se vai alle foto Maillary del posto puoi vedere quanto vuoto
è)
Nel tuo caso ci sono ancora ruderi, ma non di un village, ma di un hamlet,
quindi abandoned:place=hamlet (4k usi in taginfo) mi sembra una buon
approccio

On Wed, 31 Oct 2018 at 18:10, danbag  wrote:

> In VCO usiamo proprio locality nei casi che tu hai citato. Anche noi
> abbiamo molti alpeggi alcuni solo ruderi altri abitati solo per
> villeggiatura ed entrambi li taggo con locality.
> Ciao
>
>  Messaggio originale 
> Da: Gabriele Sani 
> Data: 31/10/18 16:42 (GMT+01:00)
> A: openstreetmap list - italiano 
> Oggetto: [Talk-it] case sparse vs localita'
>
> Buonasera, una rapida domanda prima di fare modifiche:
> capita spesso nelle zone appenniniche vicino a dove vivo di imbattersi in
> vecchie case/ville abbandonate. Alcune sono in buono stato, ma non abitate,
> altre sono praticamente crollate e rimangono i muri e poco piu'. Molte di
> queste sono taggate come locality... e' il tag piu' corretto?
> Vedo sulla wiki [1] che c'e'/c'era l'abitudine ad usarla per obbligare il
> renderer a mostrarla... cosa ne pensate?
>
> Grazie mille
>
> [1]
> https://wiki.openstreetmap.org/wiki/Tag:place=locality#Don.27t_use_place.3Dlocality_just_to_force_a_name_to_appear_on_a_featur
> ___
> 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] Taggare formazioni montuose

[aldoct]

Come consigliate di taggare quelle formazioni montuose che non hanno una
cima? Quelle che nel toponimo sono indicate come "serra" o "costa".
Saluti



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

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

[danbag]

In VCO usiamo proprio locality nei casi che tu hai citato. Anche noi abbiamo 
molti alpeggi alcuni solo ruderi altri abitati solo per villeggiatura ed 
entrambi li taggo con locality.Ciao
 Messaggio originale Da: Gabriele Sani 
 Data: 31/10/18  16:42  (GMT+01:00) A: openstreetmap 
list - italiano  Oggetto: [Talk-it] case sparse vs 
localita' 
Buonasera, una rapida domanda prima di fare modifiche:capita spesso nelle zone 
appenniniche vicino a dove vivo di imbattersi in vecchie case/ville 
abbandonate. Alcune sono in buono stato, ma non abitate, altre sono 
praticamente crollate e rimangono i muri e poco piu'. Molte di queste sono 
taggate come locality... e' il tag piu' corretto?Vedo sulla wiki [1] che 
c'e'/c'era l'abitudine ad usarla per obbligare il renderer a mostrarla... cosa 
ne pensate?
Grazie mille
[1] 
https://wiki.openstreetmap.org/wiki/Tag:place=locality#Don.27t_use_place.3Dlocality_just_to_force_a_name_to_appear_on_a_featur

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

[Talk-it] case sparse vs localita'

[Gabriele Sani]

Buonasera, una rapida domanda prima di fare modifiche:
capita spesso nelle zone appenniniche vicino a dove vivo di imbattersi in
vecchie case/ville abbandonate. Alcune sono in buono stato, ma non abitate,
altre sono praticamente crollate e rimangono i muri e poco piu'. Molte di
queste sono taggate come locality... e' il tag piu' corretto?
Vedo sulla wiki [1] che c'e'/c'era l'abitudine ad usarla per obbligare il
renderer a mostrarla... cosa ne pensate?

Grazie mille

[1]
https://wiki.openstreetmap.org/wiki/Tag:place=locality#Don.27t_use_place.3Dlocality_just_to_force_a_name_to_appear_on_a_featur
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Import civici Milano - preview

[Andrea Musuruane]

Ciao,

On Wed, Oct 31, 2018 at 2:40 PM cascafico  wrote:

> Una preview del dataset ds634 del Comune di Milano la trovate qui [1].
>
> Pin verdi, l'import li crea;
> Pin blu, l'import li modifica, anche solo per mettere in fixme che
> significa:
>   indirizzo non presente nel dataset da importare
>   indirizzo non presente in un raggio di x metri dal nodo da importare
>

Non so quanto OSM Conflator sia efficace in un import di numeri civici.

Sicuramente è più facile da usare di JOSM (e del plugin Conflation). Però è
anche molto meno flessibile.

Nell'esempio che riporti, sembra che preferisci sempre la posizione di OSM
a quella del Comune di Milano. Guardando i dati, questa supposizione mi
sembra errata.

Inoltre, non sono stati trovati civici identici, come qui:
http://audit.osmz.ru/map/MI-addr#19/45.45369/9.15650

Ciao,

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

Re: [Talk-it] Import civici Milano - regole di traduzione

[Andrea Musuruane]

Ciao Martin,

On Wed, Oct 31, 2018 at 11:31 AM Martin Koppenhoefer 
wrote:

> Am Fr., 31. Aug. 2018 um 12:16 Uhr schrieb Andrea Musuruane <
> musur...@gmail.com>:
>
>> La traduzione funziona secondo le seguenti regole:
>>
>>- *loc_ref* contiene *IDMASTER*. Questo è l'ID ufficiale del civico e
>>sarà usato per fare la conflation in import futuri. Il tag loc_ref è già
>>usato a Milano sulle highway per indicare il codice arco AMAT.
>>
>>
> per me è inutile. L'indirizzo dovrebbe essere sufficiente per future
> verifiche per capire di quale oggetto si parla. In più avremmo la lista di
> tutti gli oggetti caricati con questo import (dalla lista dei changesets
> del caricamento nella documentazione del import nel wiki), quindi si potrà
> vedere cosa è successo con gli oggetti caricati, senza dover ricorrere a
> degli ID esterni.
>

Il tempo dedicato alla conflation è molto elevato: amalgamare due data set
differenti non è semplice anche avendo a disposizione degli ottimi tool a
supporto. L'indirizzo infatti non è sufficiente a riconciliare due civici
(spesso la strada è scritta in OSM e nel dataset di origine in modo
differente, a volte anche il civico è scritto in modo differente, ecc).

Il campo loc_ref non è un semplice ID esterno, ma è l'ID ufficiale del
civico generato dal Comune di Milano. Senza il Comune di Milano quel dato
non esiste. Ed è lo stesso ente che decide quando decade.

Dato che il Comune di Milano aggiorna regolarmente il dataset dei civici,
avere a disposizione l'ID ufficiale del civico, permetterà import futuri
più veloci e precisi perché semplificherà notevolmente la fase di
conflation.


>>- *addr:housenumber* contiente *NUMEROCOMPLETO* convertito in
>>minuscolo (per l'esponente).
>>- *addr:street* contiene il toponimo OSM della strada identificata da
>>*CODICE_VIA* nello stradario generato precedentemente. Se *CODICE_VIA*
>>non ha una corrispondenza, viene aggiungo un tag *fixme*.
>>- *addr:city* contiene *Milano*. I confini amministrativi ISTAT sono
>>spesso imprecisi ed è meglio sempre specificare la città per evitare casi
>>dubbi.
>>
>> Inoltre, vengono scartati anche tutti i civici soppressi.
>>
>
>
> soppressi significa che non ci sono più i cartelli in loco?
>

Sì.


> Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa
> si fa?
>

Elimini i civici perché non esistono più.


> Dal dato si capisce a cosa si riferisce il civico (ingresso ad un
> fabbricato, cancello nel perimetro, ecc.)?
>

C'è l'indicazione del fatto che sia anche un passo carraio.

Ciao,

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

Re: [Talk-it] Import civici Milano - regole di traduzione

[Andrea Musuruane]

Ciao Giovanni,
grazie per aver ripreso questo thread.

Visto il poco interesse da parte di mapper milanesi, l'attività si è un po'
arenata. Maurizio, coordinatore OSM per la Lombardia, sta cercando
partecipanti.


On Wed, Oct 31, 2018 at 11:18 AM cascafico  wrote:

> Andrea Musuruane wrote
> >- *addr:housenumber* contiente *NUMEROCOMPLETO* convertito in
> minuscolo
> >(per l'esponente).
>
> Sto facendi delle prove per impostare una conflation collaborativa via
> browser. Come è stato deciso di comporre l'indirizzo? Per esempio:
>
> NUMERO+lowercase(LETTERA)+"/"+BARRA
> NUMERO+uppercase(LETTERA)+"/"+BARRA
> NUMERO+" "+uppercase(LETTERA)+"/"+BARRA
> ...
>
>
Il campo addr:housenumber conterrà il valore di NUMEROCOMP, con le
eventuali lettere convertite in minuscolo.

NUMEROCOMP, seguendo quanto descritot nel file Istruzioni tecniche per
l'utilizzo dei dati_CIVICI.pdf è: NUMERO+LETTERA+BARRA

Lo slash non viene usato se non per separare gli esponenti numerici.



> Avrebbe senso usare un ref che indichi il dataset sorgente? Per esempio
> ref:MI_ds634
>


L'uso di loc_ref mi sembra coerente con quello che già avviene per le
strade. Non mi sembra il caso di usare altri tag.

Ciao,

Andrea
___
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

[Talk-it] Import civici Milano - preview

[cascafico]

Una preview del dataset ds634 del Comune di Milano la trovate qui [1]. 

Pin verdi, l'import li crea;
Pin blu, l'import li modifica, anche solo per mettere in fixme che
significa:
  indirizzo non presente nel dataset da importare
  indirizzo non presente in un raggio di x metri dal nodo da importare




[1] http://audit.osmz.ru/map/MI-addr



-

--
cascafico.altervista.org
twitter.com/cascafico
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

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

[cascafico]

dieterdreist wrote
> qualcuno ha fatto una verifica a campione sulla bontà dei dati? Si vedono
> alberi all'esatta posizione nelle foto aeree? Sennò (se la precisione
> delle
> coordinate è qualcosa come 100 metri) la conflation sarebbe impossibile da
> gestire. 

Nella pagina wiki [1] trovi il link alla mappa audit, che serve anche al
controllo visuale preliminare che auspichi.



dieterdreist wrote
> Ho capito bene, parliamo di 200 alberi, solo nel FVG? Che tanto lì
> ci sono ancora i resti delle precedenti imports, 200 alberi più o meno non
> cambiano niente ;-)

Nella wiki [2]  trovi scritto "This import has been set on a regional size,
as a pilot for other italian regions (admin_level=4)"

[1]
https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlberiMonumentali-RAFVG#About
[2]
https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlberiMonumentali-RAFVG#Goals




-

--
cascafico.altervista.org
twitter.com/cascafico
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-it] Import civici Milano - regole di traduzione

[Martin Koppenhoefer]

Am Mi., 31. Okt. 2018 um 12:23 Uhr schrieb Alessandro Palmas <
alessandro.pal...@wikimedia.it>:

> Non commettiamo l'errore già fatto in precedenza.
> Tenere un campo ref del database di origine in caso di future probabili
> rielaborazioni/aggiornamenti ecc.. eviterebbe un pesante lavoro di
> ricostruzione del passato.
>


solo se ti fidi cecamente del "aggiornamento"
Quanto sia pesante il lavoro di ricostruzione del passato dipende in primis
quanto è stato organizzato e documentato bene l'import. Con la lista dei
changesets completa è un gioco di ragazzi risalire a tutti gli oggetti. In
più, con gli indirizzi la situazione è diversa che per tante altre cose,
perché il civico già dice molto bene dove si trova (nel insieme di tutti
gli altri civici), e dovrebbe essere univoco (al livello di dati pubblici
sui civici, in OSM naturalmente lo stesso indirizzo (di un POI, di
qualcosa) può occorere infinite volte).



> Già con la conflation molti civici non saranno inseriti; quando tra
> qualche anno quei dati verranno ripresi nel frattempo chissà quante
> volte saranno stati spostati, magari cancellati e ripristinati.
>


certamente. E cosa faremmo quindi? Buttiamo via tutti questi spostamenti,
cancellazioni e ripristinazioni? Probabilmente no, quindi l'ipotetico
confronto con un aggiornamento del dataset esterno sarà molto oneroso con
ID e senza ID. Per identificare un civico non serve un ID. Il civico stesso
è un ID.



>
> Vogliamo fare i puri ad ogni costo? Però ai vicini francesi nessuno ha
> fatto cancellare *ad ogni geometria importata* dal catasto il tag
> source="cadastre-dgi-fr source : Direction Générale des Impôts -
> Cadastre. Mise à jour : 2011"



credo nessuno abbia fatto gli applausi a questa scemenza. Di lamentele su
questo ne abbiamo sentite tante invece.

Ciao,
Martin
___
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?)

[Martin Koppenhoefer]

qualcuno ha fatto una verifica a campione sulla bontà dei dati? Si vedono
alberi all'esatta posizione nelle foto aeree? Sennò (se la precisione delle
coordinate è qualcosa come 100 metri) la conflation sarebbe impossibile da
gestire. Ho capito bene, parliamo di 200 alberi, solo nel FVG? Che tanto lì
ci sono ancora i resti delle precedenti imports, 200 alberi più o meno non
cambiano niente ;-)


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

Re: [Talk-it] Import civici Milano - regole di traduzione

[Alessandro Palmas]

Il 31/10/18 11:29, Martin Koppenhoefer ha scritto:
Am Fr., 31. Aug. 2018 um 12:16 Uhr schrieb Andrea Musuruane 
mailto:musur...@gmail.com>>:



...


La traduzione funziona secondo le seguenti regole:

  * *loc_ref* contiene *IDMASTER*. Questo è l'ID ufficiale del
civico e sarà usato per fare la conflation in import futuri. Il
tag loc_ref è già usato a Milano sulle highway per indicare il
codice arco AMAT. 



per me è inutile. L'indirizzo dovrebbe essere sufficiente per future 
verifiche per capire di quale oggetto si parla. In più avremmo la lista 
di tutti gli oggetti caricati con questo import (dalla lista dei 
changesets del caricamento nella documentazione del import nel wiki), 
quindi si potrà vedere cosa è successo con gli oggetti caricati, senza 
dover ricorrere a degli ID esterni.



Non commettiamo l'errore già fatto in precedenza.
Tenere un campo ref del database di origine in caso di future probabili 
rielaborazioni/aggiornamenti ecc.. eviterebbe un pesante lavoro di 
ricostruzione del passato.
Già con la conflation molti civici non saranno inseriti; quando tra 
qualche anno quei dati verranno ripresi nel frattempo chissà quante 
volte saranno stati spostati, magari cancellati e ripristinati.
Sì, tecnicamente nel db OSM si ritrova tutto, ma se abbiamo un campo che 
ci facilità l'interoperabilità con un db esterno trovo masochista il 
volerlo togliere.
Quale sarebbe il vantaggio, avere un estratto dell'Italia di qualche 
kilobyte più leggero?


Vogliamo fare i puri ad ogni costo? Però ai vicini francesi nessuno ha 
fatto cancellare *ad ogni geometria importata* dal catasto il tag
source="cadastre-dgi-fr source : Direction Générale des Impôts - 
Cadastre. Mise à jour : 2011"



Alessandro

___
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] Editing di strada all'interno di un bosco

[Max1234Ita]

cascafico wrote
> Spezzare più che un problema è un vantaggio... 

Verissimo, e sono d'accordo con te.

Quello che intendevo dire è che spezzare quei multipoligoni di dimensioni
mostruose diventa problematico nel momento in cui devi farlo, specialmente
se da essi nascono oggetti di dimensioni ridotte ma che sono sempre
multipoligoni... 

Finisce sempre che ti ritrovi  con outer way che risultano "aperte" e/o
inner "esterne"... perchè ora appartengono alla nuova relazione ma vanno
rimosse da quella originaria!

*Dopo* è sicuramente un vantaggio, ma mentre lo stai facendo è un incubo...
:)

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

[Talk-it] troppa attribuzione

[Martin Koppenhoefer]

Visto che qui si parla spesso di mancata attribuzione, sono lieto di
presentarvi un esempio di attribuzione ben visibile, dove in realtà da noi
ci sono pocchissimi dati (linee di costa, qualche punto per la posizione
delle città):

http://www.spiegel.de/politik/ausland/bild-1235495-1335916.html


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

Re: [Talk-it] Import civici Milano - regole di traduzione

[Martin Koppenhoefer]

Am Fr., 31. Aug. 2018 um 12:16 Uhr schrieb Andrea Musuruane <
musur...@gmail.com>:

> Ciao,
> oggi vediamo come tradurre i dati dei civici dal formato originario a
> quello OSM.
>
> Caricate i dati in QGIS per mezzo della funzione "Layer -> Aggiungi layer
> -> Aggiungi layer testo delimitato". Come "Campo X" e "Campo Y" scegliete
> rispettivamente WGS84_X e WGS84_Y. Come proiezione "WGS 84 / UTM zone 32N
> (EPGS:32632)".
>
> Salvate quindi il layer così ottenuto in uno shapefile (io ho usato per
> comodità lo stesso nome del file CSV ovvero Civici_20180718) avendo cura di
> usare la stessa proiezione.
>
> Per convertire i dati dal formato shapefile al formato OSM, usiamo ogr2osm
> con la seguente regola di traduzione.
> https://github.com/musuruan/osm_imports/blob/master/milano/civici.py
>
> La traduzione funziona secondo le seguenti regole:
>
>- *loc_ref* contiene *IDMASTER*. Questo è l'ID ufficiale del civico e
>sarà usato per fare la conflation in import futuri. Il tag loc_ref è già
>usato a Milano sulle highway per indicare il codice arco AMAT.
>
>
per me è inutile. L'indirizzo dovrebbe essere sufficiente per future
verifiche per capire di quale oggetto si parla. In più avremmo la lista di
tutti gli oggetti caricati con questo import (dalla lista dei changesets
del caricamento nella documentazione del import nel wiki), quindi si potrà
vedere cosa è successo con gli oggetti caricati, senza dover ricorrere a
degli ID esterni.



>- *addr:housenumber* contiente *NUMEROCOMPLETO* convertito in
>minuscolo (per l'esponente).
>- *addr:street* contiene il toponimo OSM della strada identificata da
>*CODICE_VIA* nello stradario generato precedentemente. Se *CODICE_VIA*
>non ha una corrispondenza, viene aggiungo un tag *fixme*.
>- *addr:city* contiene *Milano*. I confini amministrativi ISTAT sono
>spesso imprecisi ed è meglio sempre specificare la città per evitare casi
>dubbi.
>
> Inoltre, vengono scartati anche tutti i civici soppressi.
>


soppressi significa che non ci sono più i cartelli in loco?
Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa
si fa?

Dal dato si capisce a cosa si riferisce il civico (ingresso ad un
fabbricato, cancello nel perimetro, ecc.)?

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

Re: [Talk-it] Import civici Milano - regole di traduzione

[cascafico]

Andrea Musuruane wrote
>- *addr:housenumber* contiente *NUMEROCOMPLETO* convertito in minuscolo
>(per l'esponente).

Sto facendi delle prove per impostare una conflation collaborativa via
browser. Come è stato deciso di comporre l'indirizzo? Per esempio:

NUMERO+lowercase(LETTERA)+"/"+BARRA
NUMERO+uppercase(LETTERA)+"/"+BARRA
NUMERO+" "+uppercase(LETTERA)+"/"+BARRA
...

Avrebbe senso usare un ref che indichi il dataset sorgente? Per esempio
ref:MI_ds634





-

--
cascafico.altervista.org
twitter.com/cascafico
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-it] Editing di strada all'interno di un bosco

[cascafico]

Max1234Ita wrote
> IMHO, dipende dai casi.
> Per quanto ho potuto imparare col tempo, potrebbe andar bene anche unire i
> due boschi e tracciare la way della strada attraverso di essi: è un modo
> spiccio e pratico se il bosco è piccolo(*).
> Però mi vengono in mente anche casi in cui gestire il bosco come entità
> singola è a dir poco complicato.

Spezzare più che un problema è un vantaggio... Mi sono ricordato che, quando
mappai parecchi boschi della mia zona, spesso mi trovai col problemia dei
2000 nodi. Sono ricorso agli elettrodotti (anche quelli minori) per spezzare
i poligoni estesi. Eppoi, come già detto, semplifica la gestione dei
multipoligoni (le radure in mezzo al bosco).

Spezzare è fattibile anche senza separazione: il lato in comune dei due
boschi potrebbe causare qualche piccolo sfarfallìo in alcuni renderer, ma
concettualmente non è un errore... eppoi cìè il solito mantra del "non si
mappa per il rendering".





-

--
cascafico.altervista.org
twitter.com/cascafico
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

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

[Paolo Monegato]

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?


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

Re: [Talk-it] Servizio come Google places API

[Martin Koppenhoefer]

Am Mi., 31. Okt. 2018 um 10:16 Uhr schrieb Gian Luca Gaiba <
gian.luca.gaib...@gmail.com>:

> Grazie
> scusa la mia incompetenza... Volevo capire un'ultima cosa:
> c'e' una lista dei servizi pubblicati?
> all'indirizzo
> https://nominatim.openstreetmap.org
> oltre a
> /reverse.php
>
> ci sono altri servizi?
> dove trovo la lista?
>



c'era il link sopra: https://wiki.openstreetmap.org/wiki/Nominatim

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

Re: [Talk-it] Servizio come Google places API

[Gian Luca Gaiba]

Grazie
scusa la mia incompetenza... Volevo capire un'ultima cosa:
c'e' una lista dei servizi pubblicati?
all'indirizzo
https://nominatim.openstreetmap.org
oltre a
/reverse.php

ci sono altri servizi?
dove trovo la lista?

scusate ancora
ciao


On Wed, Oct 31, 2018 at 9:41 AM Francesco Frassinelli 
wrote:

> Il giorno mer 31 ott 2018 alle ore 09:26 Gian Luca Gaiba <
> gian.luca.gaib...@gmail.com> ha scritto:
> > Salve
> >
> > ho un problema da neofita:
> > vorrei togliermi di torno il servizio di google che mi fa l'inverse
> geocoding
> > (in realta' vorrei sostituire tutti i servizi di geocoding di google ma
> una cosa per volta)
> > cioe data una lat/lon
> > avere un address dictionary
> >
> > quello per intenderci al url:
> >
> > $url = "https://maps.google.com/maps/api/geocode/json"; .
> >   "?latlng=$latitude,$longitude" .
> >   "&result_type=street_address" .
> >   "&key=";
> >
> >
> > C'e' qualcosa di analogo in OMS? Da dove vi accedo?
>
> Certo. Se cerchi "OSM reverse geocoding" su un motore di ricerca lo trovi
> nei primi 2-3 risultati.
> https://wiki.openstreetmap.org/wiki/Nominatim#Reverse_Geocoding
>
>
> Buona giornata,
> Frafra
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Editing di strada all'interno di un bosco

[Simone Saviolo]

Il giorno mer 31 ott 2018 alle ore 09:21 Alessandro Palmas <
alessandro.pal...@wikimedia.it> ha scritto:

> Il 31/10/18 09:14, Simone Saviolo ha scritto:
> > Il giorno lun 29 ott 2018 alle ore 16:15 Alessandro Sarretta
> > mailto:alessandro.sarre...@gmail.com>>
> > ha scritto:
> >
> > In realtà, indipendentemente dall'esatta localizzazione della
> > strada, chiedevo essenzialmente se abbia senso lasciare un "buco"
> > nella mappatura di un landuse=forest in corrispondenza di una
> > strada. Mi sembra poco utile, poco realistico e assai poco
> gestibile...
> >
> > Sono anch'io favorevole a spezzare la foresta, per motivi tecnici
> > (limiti di numero di nodi, manutenzione, etc.) ma anche topologici: lì
> > c'è la strada, non la foresta.
> >
> > Traccerei la strada "dentro" alla foresta soltanto nel caso si trattasse
> > di un sentiero, un percorso piccolo e "integrato" nella foresta stessa.
> > Ma una provinciale sicuramente non è "integrata": per terra c'è
> > l'asfalto, non ci sono alberi in mezzo alla strada...
> >
>
> A sostegno di questa posizione aggiungo che una strada può fungere,
> almeno parzialmente, da corridoio tagliafuoco. Per chi gestisce gli
> incendi riuscire a vederlo può essere un'informazione utile.


Un caso come quello che descrivi l'ho descritto qui:
https://www.openstreetmap.org/#map=16/45.5707/8.2408

Ciao,

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

Re: [Talk-it] Servizio come Google places API

[Francesco Frassinelli]

Il giorno mer 31 ott 2018 alle ore 09:26 Gian Luca Gaiba <
gian.luca.gaib...@gmail.com> ha scritto:
> Salve
>
> ho un problema da neofita:
> vorrei togliermi di torno il servizio di google che mi fa l'inverse
geocoding
> (in realta' vorrei sostituire tutti i servizi di geocoding di google ma
una cosa per volta)
> cioe data una lat/lon
> avere un address dictionary
>
> quello per intenderci al url:
>
> $url = "https://maps.google.com/maps/api/geocode/json"; .
>   "?latlng=$latitude,$longitude" .
>   "&result_type=street_address" .
>   "&key=";
>
>
> C'e' qualcosa di analogo in OMS? Da dove vi accedo?

Certo. Se cerchi "OSM reverse geocoding" su un motore di ricerca lo trovi
nei primi 2-3 risultati.
https://wiki.openstreetmap.org/wiki/Nominatim#Reverse_Geocoding


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

[Talk-it] Servizio come Google places API

[Gian Luca Gaiba]

Salve

ho un problema da neofita:
vorrei togliermi di torno il servizio di google che mi fa l'inverse
geocoding
(in realta' vorrei sostituire tutti i servizi di geocoding di google ma una
cosa per volta)
cioe data una lat/lon
avere un address dictionary

quello per intenderci al url:

$url = "https://maps.google.com/maps/api/geocode/json"; .
  "?latlng=$latitude,$longitude" .
  "&result_type=street_address" .
  "&key=";


C'e' qualcosa di analogo in OMS? Da dove vi accedo?


Grazie mille e scusate la domanda banale...
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Editing di strada all'interno di un bosco

[Alessandro Palmas]

Il 31/10/18 09:14, Simone Saviolo ha scritto:
Il giorno lun 29 ott 2018 alle ore 16:15 Alessandro Sarretta 
mailto:alessandro.sarre...@gmail.com>> 
ha scritto:


In realtà, indipendentemente dall'esatta localizzazione della
strada, chiedevo essenzialmente se abbia senso lasciare un "buco"
nella mappatura di un landuse=forest in corrispondenza di una
strada. Mi sembra poco utile, poco realistico e assai poco gestibile...

Sono anch'io favorevole a spezzare la foresta, per motivi tecnici 
(limiti di numero di nodi, manutenzione, etc.) ma anche topologici: lì 
c'è la strada, non la foresta.


Traccerei la strada "dentro" alla foresta soltanto nel caso si trattasse 
di un sentiero, un percorso piccolo e "integrato" nella foresta stessa. 
Ma una provinciale sicuramente non è "integrata": per terra c'è 
l'asfalto, non ci sono alberi in mezzo alla strada...




A sostegno di questa posizione aggiungo che una strada può fungere, 
almeno parzialmente, da corridoio tagliafuoco. Per chi gestisce gli 
incendi riuscire a vederlo può essere un'informazione utile.


Alessandro

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

Re: [Talk-it] Editing di strada all'interno di un bosco

[Simone Saviolo]

Il giorno lun 29 ott 2018 alle ore 16:15 Alessandro Sarretta <
alessandro.sarre...@gmail.com> ha scritto:

> In realtà, indipendentemente dall'esatta localizzazione della strada,
> chiedevo essenzialmente se abbia senso lasciare un "buco" nella mappatura
> di un landuse=forest in corrispondenza di una strada. Mi sembra poco utile,
> poco realistico e assai poco gestibile...
>
Sono anch'io favorevole a spezzare la foresta, per motivi tecnici (limiti
di numero di nodi, manutenzione, etc.) ma anche topologici: lì c'è la
strada, non la foresta.

Traccerei la strada "dentro" alla foresta soltanto nel caso si trattasse di
un sentiero, un percorso piccolo e "integrato" nella foresta stessa. Ma una
provinciale sicuramente non è "integrata": per terra c'è l'asfalto, non ci
sono alberi in mezzo alla strada...

Ciao,

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