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

Lorenzo "Beba" Beltrami lorenzo.beba a gmail.com
Mer 23 Gen 2013 08:04:30 GMT


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 <kinetocore86 a gmail.com> 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<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/<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<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<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 a openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-it<http://lists.openstreetmap.org/listinfo/talk-it>
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.openstreetmap.org/pipermail/talk-it/attachments/20130123/ed9258de/attachment.html>


Maggiori informazioni sulla lista Talk-it