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 <kinetocor...@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@openstreetmap.org > http://lists.openstreetmap.**org/listinfo/talk-it<http://lists.openstreetmap.org/listinfo/talk-it> >
_______________________________________________ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
