Re: [Talk-it] Import Utilizzo del Suolo dal Geoportale Veneto

[Martin Koppenhöfer]

Am 24.01.2013 um 16:23 schrieb Lorenzo Beba Beltrami :

> (tranne quelli confinanti con le strade, dato che le loro aree non
> > verrebbero caricate).
> 
> 
> perchè? Sarei a favore di caricare le aree delle strade
> 
> Perché non esiste ancora un tag (o almeno non l'ho mai trovato...) per 
> identificare l'area "legale" e le strade al momento sono linee.
> Anche se si potrebbe marcarle con qualcosa come landuse=highway, poi magari 
> un giorno sarà quello e amen, altrimenti lo si cambierà. =P


+1, landuse=highway per l'area legale della strada (è stato detto tante volte 
da svariate persone in svariate liste, ma non è utilizzato quasi per niente). 
Per l'area della strada stessa (carreggiata) c'è un tag "area:highway=*" se non 
riccordo male.
Tutti i tags che abbiamo esistono perchè qualcuno gli ha utilizzato per la 
prima volta ;-)

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

Re: [Talk-it] Import Utilizzo del Suolo dal Geoportale Veneto

[Lorenzo "Beba" Beltrami]

Il giorno 24 gennaio 2013 15:09, Martin Koppenhoefer  ha scritto:

> 2013/1/24 Groppo O :
> > il fatto è che, anche se tecnicamente fattibile, in questo modo tutti i
> > poligoni importati sarebbero inseriti come multipoligoni, anche uno con 4
> > nodi
>
>
> si, ma non è un problema ;-) Se devi editare geometricamente una
> situazione è quasi sempre meglio trovare un multipoligono che 2 o più
> way sovraposte (al meno in JOSM).
>
+1
Almeno per quanto riguarda JOSM. Ed è quello che infatti ho fatto io.
Risultato: un treno di way che appartengono a tanti multipoligoni tranne
quando ho un semplice inner isolato.
E' corretto, ma mi rendo conto che magari modificarlo non è banale per un
utente alle prime armi...


>
>
> (tranne quelli confinanti con le strade, dato che le loro aree non
> > verrebbero caricate).
>
>
> perchè? Sarei a favore di caricare le aree delle strade
>
> Perché non esiste ancora un tag (o almeno non l'ho mai trovato...) per
identificare l'area "legale" e le strade al momento sono linee.
Anche se si potrebbe marcarle con qualcosa come landuse=highway, poi magari
un giorno sarà quello e amen, altrimenti lo si cambierà. =P

Ciao a tutti!
Lollo
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Import Utilizzo del Suolo dal Geoportale Veneto

[Martin Koppenhoefer]

2013/1/24 Groppo O :
> il fatto è che, anche se tecnicamente fattibile, in questo modo tutti i
> poligoni importati sarebbero inseriti come multipoligoni, anche uno con 4
> nodi


si, ma non è un problema ;-) Se devi editare geometricamente una
situazione è quasi sempre meglio trovare un multipoligono che 2 o più
way sovraposte (al meno in JOSM).


(tranne quelli confinanti con le strade, dato che le loro aree non
> verrebbero caricate).


perchè? Sarei a favore di caricare le aree delle strade

ciao,
Martin

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

Re: [Talk-it] Import Utilizzo del Suolo dal Geoportale Veneto

[Groppo O]

Il giorno 24 gennaio 2013 14:09, Giovanni Caudullo <
giovanni.caudu...@gmail.com> ha scritto:

> Ciao
> Per evitare le doppie way in file topologici dove tutti i poligoni sono
> adiacenti, si potrebbe convertire lo shapefile da poligoni a polilinee.
>
...

> Non facilissimo e volece, ma fattibile.
>
> Ciao,

il fatto è che, anche se tecnicamente fattibile, in questo modo tutti i
poligoni importati sarebbero inseriti come multipoligoni, anche uno con 4
nodi (tranne quelli confinanti con le strade, dato che le loro aree non
verrebbero caricate).

Non sarebbe sbagliato, ma visto che gli editor non permettono ancora un uso
trasparente delle relazioni, come avevo descritto prima, forse la loro
gestione potrebbe essere difficile per nuovi mappers.
Per questo ipotizzavo il doppio approccio, importare landuse piccoli come
poligoni adiacenti con nodi in comune, e trasformare i poligoni grandi in
multipoligoni, con lunghe way in comune (boschi e laguna, anche se nella
seconda ci sono già dati importati). In questo caso bisogna fare il lavoro
a mano in JOSM, giudicando zona per zona dove è meglio trasformare in
multipoligoni.


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

Re: [Talk-it] Import Utilizzo del Suolo dal Geoportale Veneto

[Martin Koppenhoefer]

2013/1/24 Groppo O :
> Forse è inevitabile raggiungere il 100 % di copertura, prima o poi, anche in
> OSM.


finchè non si concorda un tag per le aree del highway (e forse un
landuse tag per le aree del highway che comprendono l'area "legale"
del highway, quindi le zone adiascenti) non ha molto senso (secondo
me).

ciao,
Martin

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

Re: [Talk-it] Import Utilizzo del Suolo dal Geoportale Veneto

[Stefano Salvador]

> Per evitare le doppie way in file topologici dove tutti i poligoni sono
> adiacenti, si potrebbe convertire lo shapefile da poligoni a polilinee.
> Utilizzando questo algoritmo:
> http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//0017003t00
> è possibile ridurre tutto in linee singole e con l'opzione
> "IDENTIFY_NEIGHBORS" rimane traccia a quali poligoni appartenevano, quindi è
> possibile associarci la relazione. Qualora una linea fosse unica, chiusa e
> con una sola doppia relazione, sarebbe un "inner".
> Non facilissimo e volece, ma fattibile.


Ai tempi dell'importazione dei confini amministrativi in FVG avevo
fatto questo lavoro con PostGIS. Se i dati di partenza sono buoni
(leggi topologicamente corretti) è abbastanza facile.

Se interessa vedo di recuperare gli script SQL.

Ciao,

Stefano

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

Re: [Talk-it] Import Utilizzo del Suolo dal Geoportale Veneto

[Giovanni Caudullo]

Ciao
Per evitare le doppie way in file topologici dove tutti i poligoni sono
adiacenti, si potrebbe convertire lo shapefile da poligoni a polilinee.
Utilizzando questo algoritmo:
http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//0017003t00
è possibile ridurre tutto in linee singole e con l'opzione "
IDENTIFY_NEIGHBORS" rimane traccia a quali poligoni appartenevano, quindi è
possibile associarci la relazione. Qualora una linea fosse unica, chiusa e
con una sola doppia relazione, sarebbe un "inner".
Non facilissimo e volece, ma fattibile.


Il giorno 24 gennaio 2013 12:45, Groppo O  ha scritto:

> Il giorno 22 gennaio 2013 22:25, Leonardo  ha
> scritto:
>
>> Ciao,
>>
>>
>> scrivo alla mailing list per esporre una possibile idea di import per i
>> dati riguardanti l'utilizzo del suolo in Veneto
>>
> ...
>
>> Questo sarebbe il possibile piano di import ma prima vorrei sentire i
>> vostri pareri, favorevoli, contrari, dubbi, ecc...
>>
>
> Ciao,
>
> ho dato un'occhiata al file. Nelle zone urbane mi sembra più accurata la
> CTR, che (a volte) ha anche le pertinenze dei singoli edifici.
> Per le zone alpine ed agricole, invece, i file sembrano più dettagliati e
> le way più accurate della CTR, quindi anch'io sono favorevole a degli
> import locali. Usando file divisi per comune si potrebbero confrontare
> meglio i dati ed evitare alcune zone, come i centri urbani.
>
> Spesso i poligoni sono composti da way più lunghe del limite di 2000 nodi
> ed andranno quindi tagliati e trasformati in multipoligoni.
>
> Mi chiedo anch'io come si possa gestire al meglio dei poligoni con
> copertura al 100 %, quindi composti da way che hanno sempre dei tratti in
> comune con altre.
>
> Immagino che per il momento la soluzione migliore sia quella mista:
> - creare way sovrapposte, con i nodi in comune, per poligoni adiacenti
> piccoli
> - creare multipoligoni per poligoni adiacenti molto estesi, con una sola
> way di confine usata in entrambe le relazioni, es. boschi estesi.
>
> Osservazione a parte.
> Forse è inevitabile raggiungere il 100 % di copertura, prima o poi, anche
> in OSM.
> L'ideale sarebbe avere degli editor (si dice topologici?) che creano
> automaticamente una relazione quando serve, in modo trasparente. Ad es.
> tracciando una way con dei nodi in comune ad un'altra l'editor trasforma da
> solo il poligono in un multipoligono, senza creare una nuova way
> sovrapposta.
>
>
> Ciao,
> Groppo
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Import Utilizzo del Suolo dal Geoportale Veneto

[Groppo O]

Il giorno 22 gennaio 2013 22:25, Leonardo  ha
scritto:

> Ciao,
>
> scrivo alla mailing list per esporre una possibile idea di import per i
> dati riguardanti l'utilizzo del suolo in Veneto
>
...

> Questo sarebbe il possibile piano di import ma prima vorrei sentire i
> vostri pareri, favorevoli, contrari, dubbi, ecc...
>

Ciao,

ho dato un'occhiata al file. Nelle zone urbane mi sembra più accurata la
CTR, che (a volte) ha anche le pertinenze dei singoli edifici.
Per le zone alpine ed agricole, invece, i file sembrano più dettagliati e
le way più accurate della CTR, quindi anch'io sono favorevole a degli
import locali. Usando file divisi per comune si potrebbero confrontare
meglio i dati ed evitare alcune zone, come i centri urbani.

Spesso i poligoni sono composti da way più lunghe del limite di 2000 nodi
ed andranno quindi tagliati e trasformati in multipoligoni.

Mi chiedo anch'io come si possa gestire al meglio dei poligoni con
copertura al 100 %, quindi composti da way che hanno sempre dei tratti in
comune con altre.

Immagino che per il momento la soluzione migliore sia quella mista:
- creare way sovrapposte, con i nodi in comune, per poligoni adiacenti
piccoli
- creare multipoligoni per poligoni adiacenti molto estesi, con una sola
way di confine usata in entrambe le relazioni, es. boschi estesi.

Osservazione a parte.
Forse è inevitabile raggiungere il 100 % di copertura, prima o poi, anche
in OSM.
L'ideale sarebbe avere degli editor (si dice topologici?) che creano
automaticamente una relazione quando serve, in modo trasparente. Ad es.
tracciando una way con dei nodi in comune ad un'altra l'editor trasforma da
solo il poligono in un multipoligono, senza creare una nuova way
sovrapposta.


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

Re: [Talk-it] Import Utilizzo del Suolo dal Geoportale Veneto

[Lorenzo "Beba" Beltrami]

Anche io, che ho fatto prove in zona Reggio Emilia, ho tolto il landuse per
le highway (ma non per le railway). L'unico "problema" è come usano i
multipoligoni in regione, ovvero occupando TUTTO lo spazio possibile. E'
l'unico punto su cui ho sempre avuto un po' di remore perché crea dei
multipoligoni ENORMI e di conseguenza approssimativi e difficili da
manutenere... =S

Un'altra cosa che avevo fatto era togliere i landuse=greenfield e simili
(le aree in costruzione) perché essendo dati vecchi magri ora hanno già
finito... =P

Just my 2 cent.
Lollo

Il giorno 22 gennaio 2013 22:25, Leonardo  ha
scritto:

> Ciao,
>
> scrivo alla mailing list per esporre una possibile idea di import per i
> dati riguardanti l'utilizzo del suolo in Veneto. Io e l'utente joecow (
> http://www.openstreetmap.org/**user/joecow)
> abbiamo cominciato a dare un'occhiata ai dati presenti sul geoportale e a
> formulare un piano di import per chi fosse interessato.
>
> Innanzitutto, per quanto riguarda la licenza siamo a posto dato che il
> database usa la IODL 2.0, compatibile con la OdBL.
>
> Il database è raggiungibile dal solito link (
> http://idt.regione.veneto.it/**app/metacatalog/),
> scegliendo 01 - Dati Territoriali della Regione Veneto->c05_Suolo e
> Sottosuolo->c0506_Uso del Suolo->c0506021_CopSuolo, suddiviso in Province e
> relativi Comuni.
>
> La data del metadato riportata è 2009-06-30, più recente di quella
> contenuta nei singoli file della CRT (i più nuovi arrivano al 2008).
>
> Li shape dei singoli comuni sembrano essere in ottimo stato, ben disegnati
> e senza particolari errori segnalati da QGIS (per ora solo pochi poligoni
> intersecati).
>
> L'idea è quella di applicare lo stesso procedimento di import descritto
> nella wikia OSM Veneto per gli shape della CRT, ovviamente con un nuovo set
> di regole da usare con shp-to-osm. Ed è in questo punto che l'aiuto della
> comunità della mailing list interverrebbe: joecow ha analizzato tutte le
> province e estratto i singoli elementi che caratterizzano i vari poligoni e
> li ha ordinati in un bel file excel che potete trovare a questo link (
> https://www.dropbox.com/sh/**1kj9faps6j1d1i4/L5WEDViPmS
> ).
>
> Sono in totale 174 voci che necessitano di una regola ma molte sono
> "simili", per esempio Betuleto,Castagneto con frassino, Castagneto dei
> substrati magmatici, Rovereto dei substrati magmatici, Faggeta altimontana
> potrebbero essere tutti taggati come natural=wood e per differenziarle
> usare wood=* dove * sta per la specie. Stessa cosa per le coltivazioni,
> sulla wiki di OSM ci sono già le indicazioni per fare le distinzioni. La
> base di partenza per le regole sarebbe la pagina dei landuse sulla wiki (
> http://wiki.openstreetmap.**org/wiki/Key:landuse
> ).
>
> Ora credo sorga una domanda: perchè fare questo anziché continuare con
> l'import della vegetazione (i file veget_a della CTR)? Opinione mia
> personale:
>
> 1)Gli shape sono molto più ordinati, aggiornati e dettagliati di quelli
> contenuti nella CTR. Durante gli import che ho effettuato dalla CTR ho
> notato certe zone in cui le geometrie degli shape della vegetazione sono
> completamente sballati quando vengono aperti in QGIS, obbligando
> l'importatore a un lunghissimo lavoro di correzione manuale. Inoltre certe
> zone non hanno dati riguardanti i campi e i boschi, nonostante questi siano
> visibilissimi sulle ortofoto PNC2006.
>
> 2)Dato che in Veneto l'import della vegetazione è molto più indietro
> rispetto all'import degli edifici, partiamo già con un territorio
> abbastanza "pulito" senza dover prima eliminare la precedente vegetazione
> già importata. Quella già presente può rimanere e venire integrata con
> questi dati.
>
> 3)L'import avverrebbe in maniera molto più organizzata dato che
> caricheremmo non per riquadri ma per comuni.
>
> Ovviamente possiamo escludere alcuni elementi dalla conversione come i
> landuse per le highway.
>
> Questo sarebbe il possibile piano di import ma prima vorrei sentire i
> vostri pareri, favorevoli, contrari, dubbi, ecc... e se qualcuno fosse
> interessato alla discussione per la creazione del file di regole. Vorrei
> che quest'ultimo fosse il più corretto possibile proprio per evitare lavori
> post-import di correzione errori massivi.  A voi la parola :)
>
> Leonardo
>
>
>
>
> __**_
> Talk-it mailing list
> Talk-it@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it