[Gfoss] Riproiezione di un raster

Buongiorno a tutti, scrivo per esporvi alcuni dubbi che mi sono venuti
relativamente alla riproiezione di un raster. In ufficio, per alcuni indici
di vegetazione, abbiamo la necessità di visualizzare in un diagramma a barre
quanta superficie del raster in esame rientra in un certo range di valori.
Mi spiego meglio: posti tre range x, y e z, vogliamo sapere quanti pixel
rientrano in ognuno dei range e quale è la superficie totale di ognuno dei
range. Ad esempio: nel range x rientrano 20 pixel, la dimensione di ogni
pixel è 10x10 metri, quindi la superficie totale di x è 10x10x20=2000mq

Mettendo da parte i perchè, si è scelto di lavorare in questo modo:
1 - vettorializzazione del raster dell'indice di vegetazione
2 - calcolo della superficie di ogni poligono del vettore(ogni poligono
corrisponderà al singolo pixel del raster al punto 1)
3 - raggruppamento delle ricorrenze dei pixel secondo i range e sommatoria
delle aree

Il dato di partenza è in 4326 con dimensione del singolo pixel pari a
0.000112148462163201668 x 0.000112148462163201668

Uno sviluppatore si sta occupando di creare il flusso di lavoro in python,
io con QGIS ho fatto una verifica sui suoi risultati partendo da uno degli
indici calcolati.

Usando /Polygonize(raster to vector)/ ho ottenuto un vettore con una colonna
DN che contiene il valore di indice per ogni poligono. Ho a questo punto
aggiunto una colonna che ho chiamato area_mq con cui tramite field
calculator ho calcolato la superficie di ogni poligono: *area( transform(
$geometry, 'EPSG:4326', 'EPSG:3857'))*. Il risultato è pari a circa 206 mq
per ogni pixel.

Lo sviluppatore usando rasterio ha riproiettato il raster in 3857 e si è poi
calcolato l'estensione di ogni pixel che gli risulta pari a circa 175 mq con
pixel di dimensioni 13.26663473960738138 x 13.26663473960738138 m.

Per capire il perchè di queste differenze ho esportato il mio raster in
3857(Export -> Save as..) trovandomi con pixel di dimensioni
12.48430981132078799 x 16.5115487603316744 e quindi la superficie di ogni
pixel è circa 206 mq. Mi trovo con il risultato che mi sono calcolato in
precedenza ma non con il risultato dello sviluppatore.

Secondo test: ho usato /Warp/ per riproiettare il raster e mi trovo con le
dimensioni in pixel dello sviluppatore.

Ora, posto che ho sempre riproiettato un raster nello stesso modo con cui si
riproietta un vettore non avendo mai riscontrato problemi di
riposizionamento vorrei capire il perchè di quello che sembra essere un mio
errore metodologico.

-----
Consulente GIS, Formatore, Blogger e Ciclista Urbano
email: info@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/

Come hai detto giustamente, "Mettendo da parte i perchè, si è scelto di
lavorare in questo modo" perché lo trovo davvero poco efficace.
Comunque, hai controllato che il resampling method sia lo stesso?

Il giorno mar 17 mar 2020 alle ore 09:52 Massimiliano Moraca <
info@massimilianomoraca.it> ha scritto:

Buongiorno a tutti, scrivo per esporvi alcuni dubbi che mi sono venuti
relativamente alla riproiezione di un raster. In ufficio, per alcuni indici
di vegetazione, abbiamo la necessità di visualizzare in un diagramma a
barre
quanta superficie del raster in esame rientra in un certo range di valori.
Mi spiego meglio: posti tre range x, y e z, vogliamo sapere quanti pixel
rientrano in ognuno dei range e quale è la superficie totale di ognuno dei
range. Ad esempio: nel range x rientrano 20 pixel, la dimensione di ogni
pixel è 10x10 metri, quindi la superficie totale di x è 10x10x20=2000mq

Mettendo da parte i perchè, si è scelto di lavorare in questo modo:
1 - vettorializzazione del raster dell'indice di vegetazione
2 - calcolo della superficie di ogni poligono del vettore(ogni poligono
corrisponderà al singolo pixel del raster al punto 1)
3 - raggruppamento delle ricorrenze dei pixel secondo i range e sommatoria
delle aree

Il dato di partenza è in 4326 con dimensione del singolo pixel pari a
0.000112148462163201668 x 0.000112148462163201668

Uno sviluppatore si sta occupando di creare il flusso di lavoro in python,
io con QGIS ho fatto una verifica sui suoi risultati partendo da uno degli
indici calcolati.

Usando /Polygonize(raster to vector)/ ho ottenuto un vettore con una
colonna
DN che contiene il valore di indice per ogni poligono. Ho a questo punto
aggiunto una colonna che ho chiamato area_mq con cui tramite field
calculator ho calcolato la superficie di ogni poligono: *area( transform(
$geometry, 'EPSG:4326', 'EPSG:3857'))*. Il risultato è pari a circa 206 mq
per ogni pixel.

Lo sviluppatore usando rasterio ha riproiettato il raster in 3857 e si è
poi
calcolato l'estensione di ogni pixel che gli risulta pari a circa 175 mq
con
pixel di dimensioni 13.26663473960738138 x 13.26663473960738138 m.

Per capire il perchè di queste differenze ho esportato il mio raster in
3857(Export -> Save as..) trovandomi con pixel di dimensioni
12.48430981132078799 x 16.5115487603316744 e quindi la superficie di ogni
pixel è circa 206 mq. Mi trovo con il risultato che mi sono calcolato in
precedenza ma non con il risultato dello sviluppatore.

Secondo test: ho usato /Warp/ per riproiettare il raster e mi trovo con le
dimensioni in pixel dello sviluppatore.

Ora, posto che ho sempre riproiettato un raster nello stesso modo con cui
si
riproietta un vettore non avendo mai riscontrato problemi di
riposizionamento vorrei capire il perchè di quello che sembra essere un mio
errore metodologico.

-----
Consulente GIS, Formatore, Blogger e Ciclista Urbano
email: info@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

--
*Dott. For. Ludovico Frate, Ph.D.*

*Via Kennedy 80, 86170 - Isernia - ITALIA.*
*Via Montalto 17, 86087 - Rionero Sannitico (IS) - ITALIA.*
Studio Tecnico Forestale e GIS *FORGIS* <http://www.forgis.it/&gt;
*Collaboratore presso Studio Associato Ecoview <http://www.ecoview.it/&gt;\*
*Collaboratore presso Unimol EnviXlab <http://envixlab.unimol.it/&gt;\*

*Docente GIS presso lezionigis.it <https://www.lezionigis.it>*
*Cel: ++39 3333767557*

*P.IVA 00960030948E-mail: *frateludovico@gmail.com*|*
ludovicofrate@hotmail.it
*Research Gate
<https://www.researchgate.net/profile/Ludovico_Frate?ev=hdr_xprf&_sg=lGaI2daIBO6kPmtye069ckFfDExcPoNVKJHrqvQEPQmsmnHolvnRZzPQdcyxs1g7&gt;\*
|*Google Scholar
<https://scholar.google.it/citations?user=wGFhBrkAAAAJ&hl=it&gt;\*|\*LinkedIn
<https://www.linkedin.com/in/ludovico-frate-a387aa57?trk=hp-identity-name&gt;\*

----- Messaggio originale -----

Da: "Massimiliano Moraca" <info@massimilianomoraca.it>
A: gfoss@lists.gfoss.it
Inviato: Martedì, 17 marzo 2020 9:52:52
Oggetto: [Gfoss] Riproiezione di un raster

la dimensione di ogni

pixel è 10x10 metri, quindi la superficie totale di x è 10x10x20=2000mq

Il dato di partenza è in 4326 con dimensione del singolo pixel pari a
0.000112148462163201668 x
0.000112148462163201668

questi dati non concordano: il pixel quadrato in coordinate geografiche diventa un rettangolo in coordinate piane, quindi non può essere 10x10.
dipende dalla latitudine: grosso modo c'è di mezzo il coseno di fi, ovvero la dimensione in longitudine è data dalla dimensioni in latitudine per il coseno di fi. ciò è dovuto alla convergenza dei meridiani.
per piccole porzioni di raster il pixel può essere considerato costante da nord a sud. per raster grandi che si estendono molto in latitudine, no.
marcog

Ha usato nearest come me

-----
Consulente GIS, Formatore, Blogger e Ciclista Urbano
email: info@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/

Scusami se ti faccio qualche domanda in più, ma l'estensione dell'area è
importante? perché sia il 4326 che il 3857 introducono distorsioni
importanti e il calcolo dell'area è falsato

Il giorno mar 17 mar 2020 alle ore 10:45 Massimiliano Moraca <
info@massimilianomoraca.it> ha scritto:

Ha usato nearest come me

-----
Consulente GIS, Formatore, Blogger e Ciclista Urbano
email: info@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

--
*Dott. For. Ludovico Frate, Ph.D.*

*Via Kennedy 80, 86170 - Isernia - ITALIA.*
*Via Montalto 17, 86087 - Rionero Sannitico (IS) - ITALIA.*
Studio Tecnico Forestale e GIS *FORGIS* <http://www.forgis.it/&gt;
*Collaboratore presso Studio Associato Ecoview <http://www.ecoview.it/&gt;\*
*Collaboratore presso Unimol EnviXlab <http://envixlab.unimol.it/&gt;\*

*Docente GIS presso lezionigis.it <https://www.lezionigis.it>*
*Cel: ++39 3333767557*

*P.IVA 00960030948E-mail: *frateludovico@gmail.com*|*
ludovicofrate@hotmail.it
*Research Gate
<https://www.researchgate.net/profile/Ludovico_Frate?ev=hdr_xprf&_sg=lGaI2daIBO6kPmtye069ckFfDExcPoNVKJHrqvQEPQmsmnHolvnRZzPQdcyxs1g7&gt;\*
|*Google Scholar
<https://scholar.google.it/citations?user=wGFhBrkAAAAJ&hl=it&gt;\*|\*LinkedIn
<https://www.linkedin.com/in/ludovico-frate-a387aa57?trk=hp-identity-name&gt;\*

Ludovico l'area ha una estensione di 4-5kmq

Andrea il processo in se deve avvenire in automatico attraverso script in
Python, mi confronterò con lo sviluppatore per verificare se è possibile
inserire questi step nel codice. Grazie per l'indicazione

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*

Il giorno mar 17 mar 2020 alle ore 12:53 andrea pacifici <pacifici@gmail.com>
ha scritto:

Ciao Massimiliano,

immagino avrai avuto i tuoi motivi a fare tutto per via vettoriale, ma se
volessi fare tutta la procedura via raster potresti fare così:
1) riclassificare il raster (nei tre range X Y e Z del tuo esempio)
tramite r.reclass (o direttamente con il calcolatore raster di Qgis, se
preferisci)
2) usare r.report per avere per ogni classe numero di pixel, superficie in
mq o percentuale di copertura.
Sono due soli passaggi, semplici e veloci

Se ti serve aiuto scrivimi pure.
Andrea
____________________________
Dott. Geol. Andrea Pacifici, Ph.D.
Via Altogradi n° 1,
55100 Lucca (Lu)
Tel. 0583-082026
Cell. 328-0991808
web: www.geoitt.it
e-mail: pacifici@gmail.com

Il giorno mar 17 mar 2020 alle ore 09:52 Massimiliano Moraca <
info@massimilianomoraca.it> ha scritto:

Buongiorno a tutti, scrivo per esporvi alcuni dubbi che mi sono venuti
relativamente alla riproiezione di un raster. In ufficio, per alcuni
indici
di vegetazione, abbiamo la necessità di visualizzare in un diagramma a
barre
quanta superficie del raster in esame rientra in un certo range di valori.
Mi spiego meglio: posti tre range x, y e z, vogliamo sapere quanti pixel
rientrano in ognuno dei range e quale è la superficie totale di ognuno dei
range. Ad esempio: nel range x rientrano 20 pixel, la dimensione di ogni
pixel è 10x10 metri, quindi la superficie totale di x è 10x10x20=2000mq

Mettendo da parte i perchè, si è scelto di lavorare in questo modo:
1 - vettorializzazione del raster dell'indice di vegetazione
2 - calcolo della superficie di ogni poligono del vettore(ogni poligono
corrisponderà al singolo pixel del raster al punto 1)
3 - raggruppamento delle ricorrenze dei pixel secondo i range e sommatoria
delle aree

Il dato di partenza è in 4326 con dimensione del singolo pixel pari a
0.000112148462163201668 x 0.000112148462163201668

Uno sviluppatore si sta occupando di creare il flusso di lavoro in python,
io con QGIS ho fatto una verifica sui suoi risultati partendo da uno degli
indici calcolati.

Usando /Polygonize(raster to vector)/ ho ottenuto un vettore con una
colonna
DN che contiene il valore di indice per ogni poligono. Ho a questo punto
aggiunto una colonna che ho chiamato area_mq con cui tramite field
calculator ho calcolato la superficie di ogni poligono: *area( transform(
$geometry, 'EPSG:4326', 'EPSG:3857'))*. Il risultato è pari a circa 206 mq
per ogni pixel.

Lo sviluppatore usando rasterio ha riproiettato il raster in 3857 e si è
poi
calcolato l'estensione di ogni pixel che gli risulta pari a circa 175 mq
con
pixel di dimensioni 13.26663473960738138 x 13.26663473960738138 m.

Per capire il perchè di queste differenze ho esportato il mio raster in
3857(Export -> Save as..) trovandomi con pixel di dimensioni
12.48430981132078799 x 16.5115487603316744 e quindi la superficie di ogni
pixel è circa 206 mq. Mi trovo con il risultato che mi sono calcolato in
precedenza ma non con il risultato dello sviluppatore.

Secondo test: ho usato /Warp/ per riproiettare il raster e mi trovo con le
dimensioni in pixel dello sviluppatore.

Ora, posto che ho sempre riproiettato un raster nello stesso modo con cui
si
riproietta un vettore non avendo mai riscontrato problemi di
riposizionamento vorrei capire il perchè di quello che sembra essere un
mio
errore metodologico.

-----
Consulente GIS, Formatore, Blogger e Ciclista Urbano
email: info@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019