Re: [QGIS-it-user] R: Digest di QGIS-it-user, Volume 101, Numero 15

[Totò Fiandaca via QGIS-it-user]

Grazie mille per la condivisione

saluti

Il giorno mar 30 apr 2024 alle ore 15:22 Francesco Fiermonte via
QGIS-it-user  ha scritto:

> Ciao,
>
> ho avuto una bella e piacevole chiaccherata con *Alessandro Furieri* (che
> legge in CCN e che ringrazio davvero moltissimo).
>
> Penso sia utile condividere con la lista un "estratto" dei punti che sono
> emersi da questo sostanzioso scambio di e-mail (grazie, Sandro, per rendere
> disponibile il Tuo pensiero).
>
> Per la leggibilità, il testo è stato "adattato", intervenendo anche sulla
> formattazione.
>
> --
>
> *WAL *= Write-Ahead Logging mentre *SHM *= Shared Memory
>
> e' tutta roba interna di *SQLite*. la spiegazione completa la puoi
> leggere qua:
>
> https://www.sqlite.org/wal.html
>
> ---
>
> * *GPKG-WAL*: Questo file contiene il LOG DI SCRITTURA ANTICIPATA
> (WAL) per la connessione corrente. In pratica, registra lo stato
> transazionale del database tra le operazioni di COMMIT o ROLLBACK. In altre
> parole, tiene traccia dei cambiamenti apportati al database durante una
> sessione di lavoro. *
>
> invece nel modo *classic *per gli stessi identici compiti viene creato un
> file con suffisso *-journal* che pero' ha una struttura del tutto
> differente e che lavora in tutt'altro modo.
>
> nota che in entrambi i casi questi logfiles devono stare nella solita
> cartella dove si trova il DB.
>
> andiamo un po' a vedere cosa succede in caso di disastro, p.es. dopo una
> caduta di tensione o un crash di sistema.
>
> quando prima o poi andrai ad aprire quel DB che e' rimasto azzoppato,
> SQLite si accorgera' dalla presenza del file di log che ci sono operazioni
> pendenti da sanare. comincia quindi a sbobinarsi a ritroso tutto il log, ed
> alla fine il tuo DB tornera' immacolato e pulito come se nulla fosse
> accaduto.
>
> ovviamente avrai perso tutte le operazioni che non erano ancora arrivate
> ad un COMMIT, ma almeno ritorni al punto da cui eri partito.
>
> ---
>
> * *GPKG-SHM*: Questo file gestisce l’accesso concorrente al database
> tramite un indice verso il file WAL. In sostanza, aiuta a garantire che più
> utenti possano accedere al database contemporaneamente senza causare
> conflitti. *
> corretto: una *shared memory* e' solo un blocco di memoria che puo'
> essere condiviso tra processi diversi, che cosi' possono scambiarsi
> direttamente le informazioni. insomma, visto che non e' possibile avere una
> vera architettura *client-server* si cerca di aggirare il problema
> facendo cooperare i vari processi passando per la *shared memory*.
>
> ---
>
> in pratica sono dei meccanismi abbastanza sofisticati che servono proprio
> per dare a SQLite un certo livello di multiutenza. che non sara' comunque
> mai perfetto visto che l'architettura generale non e' intesa per quello, ma
> sicuramente sono un bel passo avanti rispetto al vecchio modo tradizionale
> con cui lavora SQLite.
>
> personalmente li uso pochissimo, perche' ogni rosa ha le sue spine, che in
> questo caso significa che se puta caso qualcosa va storto fare ripartire
> SQLite senza perdere dati protrebbe anche essere una gran bella rogna.
>
> inoltre potrebbero nascere dei conflitti se piu' processi operano sul
> medesimo DB, alcuni in modo *WAL* ed altri in modo *classico*.
>
> se *QGIS* ha deciso di optare per il* WAL* mode dovrebbe significare che
> sono abbastanza sicuri di essere riusciti a mettere in piedi un ragionevole
> sistema di multiutenza.
>
> nota bene che comunque *SQLite* non ama affatto gli accessi remoti via
> rete, per cui in pratica tutti i processi concorrenti dovrebbero girare
> sempre sulla solita macchina dove e' installato di DB ... che ovviamente
> limita pesantemente la condivisione dei dati tra i vari processi.
>
> (...)
>
> quei files temporanei vengono creati autonomamente da *SQLite*, ed
> ovviamente devono stare nella stessa cartella dove si trova il DB quindi tu
> non vedrai mai nulla se lavori su di una macchina diversa da quella dove
> sta il DB, e' consequenziale.
>
> il vero problema sta tutto in questa idea di accedere ad un DB che e'
> fisicamente collocato in un altro PC tramite condivisione di rete.
>
> per quanto mi risulta i ragazzi di *SQLite *non si stancano mai di
> ripetere che e' una ricetta garantita ed assicurata per disastri che
> potrebbero anche arrivare alla "frittura" complete del DB e di tutti i dati
> che contiene.
>
> funziona e funziona bene, ma solo fin quando sia il DB che tutti i
> processi che accedono a quel DB stanno tutti su di un'unica macchina,
> altrimenti e' come giocare alla roulette russa, a volte va liscia ma a
> volte invece no :-P
>
> giusto per entrare un pelo nel tecnico; un buon sistema operativo e' in
> grado di assicurare un rigoroso sincronismo delle operazioni. se qualcosa
> dovesse andare male (crash, caduta 

Re: [Qgis-user] merging parts from various raster files

[Richard McDonnell via QGIS-User]

Hi Sibylle,
To extract the Bioregions, I suggest you utilise the option Selected features 
only which is a tick box below, where you select Mask layer. All you need to do 
is select, on the map canvas, the bioregion you want to extract.

QGIS is capable of loading Tiff's I use them exclusively in any Raster work I 
do. The virtual raster is just an 
easy way for you to merge/mosaic the raster's (10-12 Raster's) together into a 
single raster.
Kind Regards,

Richard




--
Richard McDonnell MSc GIS, FME Certified Professional
Flood Risk Management - Data Management

--
Oifig na nOibreacha Poiblí
Office of Public Works

Sráid Jonathan Swift, Baile Átha Troim, Co na Mí, C15 NX36
Jonathan Swift Street, Trim, Co Meath, C15 NX36
--
M +353 87 688 5964 T +353 46 942 2409
https://gov.ie/opw

--
To send me files larger than 30MB, please use the link below 
https://filetransfer.opw.ie/filedrop/richard.mcdonn...@opw.ie

Email Disclaimer: 
https://www.gov.ie/en/organisation-information/439daf-email-disclaimer/
From: QGIS-User  On Behalf Of Sibylle 
Stöckli via QGIS-User
Sent: 30 April 2024 14:10
To: 'Frank Broniewski' ; qgis-user@lists.osgeo.org; 
broniew...@a-a.lu
Subject: Re: [Qgis-user] merging parts from various raster files

Hello Frank and Richard
,
I have 10-12 raster files (figure 1, .tif files), they all look the same and 
cover the entire country with no definition of the biogeregions.
Second there is the shape file defining the biogeoregions (figure 2, different 
colors).

-  Probably I first need to extract the different biogeoregions out 
from each raster file or define the linkage between the raster files the the 
biogeoregions in the shape file. However, raster - crop raster based on layer 
mask extracts the entire mask (entire country) not the different biogeoregions.
-  Furter I may delete all the data in the raster files not needed: 
e.g. in raster 1  just data on biogeo 1, but not the other biogeoregions, in 
raster 2, data on biogeo 2, but not the other biogeregions. By doing so there 
will be no overlap, as each raster file consists only one biogregions.
-  I am not sure about the virtual raster, because it is not possible 
to import .tif files.
-  Then I may just use the "merge" function - merging each bioregions.

Background: postprocessing of a model output. It was not possible to run the 
model only for biogeoregion 1 (with input data from biogeoregion 1) , bioregion 
2 (with input data from bioregion 2) etc. It was necessary to model the entire 
country with input data from bioregion 1 etc.

Kind regards
Sibylle


Figure 1
[cid:image003.jpg@01DA9B0B.B9FA38E0]
Figure 2
[cid:image005.jpg@01DA9B0B.B9FA38E0]
From: Frank Broniewski mailto:broniew...@a-a.lu>>
Sent: Tuesday, April 30, 2024 1:48 PM
To: qgis-user@lists.osgeo.org; 
sibylle.stoec...@gmx.ch
Subject: AW: [Qgis-user] merging parts from various raster files

Hello Sybille,

I am not sure if I understand your problem correctly. I assume, you have a 
mosaic of raster files (that overlap) and you want to create a single raster 
file for statistical analysis. In my opinion, the easiest way to achieve that 
is to create a virtual raster (VRT) and either use that for stats or create a 
new raster file from the VRT. You can find the tool in the processing toolbox. 
With the tool you can even define the resolution, if mixed, and how the VRT 
should be resampled.

HTH
Frank

https://docs.qgis.org/3.34/en/docs/user_manual/processing_algs/gdal/rastermiscellaneous.html#build-virtual-raster

Von: QGIS-User 
mailto:qgis-user-boun...@lists.osgeo.org>> 
im Auftrag von Sibylle Stöckli via QGIS-User 
mailto:qgis-user@lists.osgeo.org>>
Gesendet: Dienstag, 30. April 2024 11:34
An: qgis-user@lists.osgeo.org 
mailto:qgis-user@lists.osgeo.org>>
Betreff: [Qgis-user] merging parts from various raster files

Dear community

I am working with QGIS 3.34 (Prizren) and would like to merge region 1 from
raster (.tif) file 1 and region 2 from raster file 2, and...
For sure I will need to use raster-miscellaneous-merge.

My question is related to the pre-processing of the input raster files.
- The 12 raster files all have the same coordinate system.
- The raster files are fully overlapping (the entire country).
- The region is not defined per se in the raster file, but in an additional
shape file (biogeo.shp).
- For sure I can carry out some zonal statistics using raster and shape
file, but to merge the regions I need all the pixels form a regions as input
file for the merging process. This process is more than just selecting
regions or cropping. Do you have any suggestions?

Kind regards
Sibylle

___
QGIS-User mailing list
QGIS-User@lists.osgeo.org
List info: 

[QGIS-it-user] R: Digest di QGIS-it-user, Volume 101, Numero 15

[Francesco Fiermonte via QGIS-it-user]

Ciao,

ho avuto una bella e piacevole chiaccherata con Alessandro Furieri (che legge 
in CCN e che ringrazio davvero moltissimo).

Penso sia utile condividere con la lista un "estratto" dei punti che sono 
emersi da questo sostanzioso scambio di e-mail (grazie, Sandro, per rendere 
disponibile il Tuo pensiero).

Per la leggibilità, il testo è stato "adattato", intervenendo anche sulla 
formattazione.

--

WAL = Write-Ahead Logging mentre SHM = Shared Memory

e' tutta roba interna di SQLite. la spiegazione completa la puoi leggere qua:

https://www.sqlite.org/wal.html

---

* GPKG-WAL: Questo file contiene il LOG DI SCRITTURA ANTICIPATA (WAL) per 
la connessione corrente. In pratica, registra lo stato transazionale del 
database tra le operazioni di COMMIT o ROLLBACK. In altre parole, tiene traccia 
dei cambiamenti apportati al database durante una sessione di lavoro. *
    
invece nel modo classic per gli stessi identici compiti viene creato un file 
con suffisso -journal che pero' ha una struttura del tutto differente e che 
lavora in tutt'altro modo.

nota che in entrambi i casi questi logfiles devono stare nella solita cartella 
dove si trova il DB.

andiamo un po' a vedere cosa succede in caso di disastro, p.es. dopo una caduta 
di tensione o un crash di sistema.

quando prima o poi andrai ad aprire quel DB che e' rimasto azzoppato, SQLite si 
accorgera' dalla presenza del file di log che ci sono operazioni pendenti da 
sanare. comincia quindi a sbobinarsi a ritroso tutto il log, ed alla fine il 
tuo DB tornera' immacolato e pulito come se nulla fosse accaduto.

ovviamente avrai perso tutte le operazioni che non erano ancora arrivate ad un 
COMMIT, ma almeno ritorni al punto da cui eri partito.

---

* GPKG-SHM: Questo file gestisce l’accesso concorrente al database tramite 
un indice verso il file WAL. In sostanza, aiuta a garantire che più utenti 
possano accedere al database contemporaneamente senza causare conflitti. *
    
corretto: una shared memory e' solo un blocco di memoria che puo' essere 
condiviso tra processi diversi, che cosi' possono scambiarsi direttamente le 
informazioni. insomma, visto che non e' possibile avere una vera architettura 
client-server si cerca di aggirare il problema facendo cooperare i vari 
processi passando per la shared memory.

---

in pratica sono dei meccanismi abbastanza sofisticati che servono proprio per 
dare a SQLite un certo livello di multiutenza. che non sara' comunque mai 
perfetto visto che l'architettura generale non e' intesa per quello, ma 
sicuramente sono un bel passo avanti rispetto al vecchio modo tradizionale con 
cui lavora SQLite.

personalmente li uso pochissimo, perche' ogni rosa ha le sue spine, che in 
questo caso significa che se puta caso qualcosa va storto fare ripartire SQLite 
senza perdere dati protrebbe anche essere una gran bella rogna.

inoltre potrebbero nascere dei conflitti se piu' processi operano sul medesimo 
DB, alcuni in modo WAL ed altri in modo classico.

se QGIS ha deciso di optare per il WAL mode dovrebbe significare che sono 
abbastanza sicuri di essere riusciti a mettere in piedi un ragionevole sistema 
di multiutenza.

nota bene che comunque SQLite non ama affatto gli accessi remoti via rete, per 
cui in pratica tutti i processi concorrenti dovrebbero girare sempre sulla 
solita macchina dove e' installato di DB ... che ovviamente limita pesantemente 
la condivisione dei dati tra i vari processi.

(...)

quei files temporanei vengono creati autonomamente da SQLite, ed ovviamente 
devono stare nella stessa cartella dove si trova il DB quindi tu non vedrai mai 
nulla se lavori su di una macchina diversa da quella dove sta il DB, e' 
consequenziale.

il vero problema sta tutto in questa idea di accedere ad un DB che e' 
fisicamente collocato in un altro PC tramite condivisione di rete.

per quanto mi risulta i ragazzi di SQLite non si stancano mai di ripetere che 
e' una ricetta garantita ed assicurata per disastri che potrebbero anche 
arrivare alla "frittura" complete del DB e di tutti i dati che contiene.

funziona e funziona bene, ma solo fin quando sia il DB che tutti i processi che 
accedono a quel DB stanno tutti su di un'unica macchina, altrimenti e' come 
giocare alla roulette russa, a volte va liscia ma a volte invece no :-P

giusto per entrare un pelo nel tecnico; un buon sistema operativo e' in grado 
di assicurare un rigoroso sincronismo delle operazioni. se qualcosa dovesse 
andare male (crash, caduta di corrente etc) avrai sempre un solido punto di 
ripristino da cui ripartire. magari scoprirai che avrai perso le ultimissime 
operazioni ancora non concluse, ma tutto il resto verra' correttamente 
ripristinato.

ma se nel mezzo ci infili una rete con tutti i suoi tempi di latenza non 

Re: [Qgis-user] merging parts from various raster files

[Frank Broniewski via QGIS-User]

Hello Sybille,

I am not sure if I understand your problem correctly. I assume, you have a 
mosaic of raster files (that overlap) and you want to create a single raster 
file for statistical analysis. In my opinion, the easiest way to achieve that 
is to create a virtual raster (VRT) and either use that for stats or create a 
new raster file from the VRT. You can find the tool in the processing toolbox. 
With the tool you can even define the resolution, if mixed, and how the VRT 
should be resampled.

HTH
Frank

https://docs.qgis.org/3.34/en/docs/user_manual/processing_algs/gdal/rastermiscellaneous.html#build-virtual-raster

Von: QGIS-User  im Auftrag von Sibylle 
St?ckli via QGIS-User 
Gesendet: Dienstag, 30. April 2024 11:34
An: qgis-user@lists.osgeo.org 
Betreff: [Qgis-user] merging parts from various raster files

Dear community

I am working with QGIS 3.34 (Prizren) and would like to merge region 1 from
raster (.tif) file 1 and region 2 from raster file 2, and...
For sure I will need to use raster-miscellaneous-merge.

My question is related to the pre-processing of the input raster files.
- The 12 raster files all have the same coordinate system.
- The raster files are fully overlapping (the entire country).
- The region is not defined per se in the raster file, but in an additional
shape file (biogeo.shp).
- For sure I can carry out some zonal statistics using raster and shape
file, but to merge the regions I need all the pixels form a regions as input
file for the merging process. This process is more than just selecting
regions or cropping. Do you have any suggestions?

Kind regards
Sibylle

___
QGIS-User mailing list
QGIS-User@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
___
QGIS-User mailing list
QGIS-User@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] merging parts from various raster files

[Sibylle Stöckli via QGIS-User]

Dear community

I am working with QGIS 3.34 (Prizren) and would like to merge region 1 from
raster (.tif) file 1 and region 2 from raster file 2, and...
For sure I will need to use raster-miscellaneous-merge.

My question is related to the pre-processing of the input raster files.
- The 12 raster files all have the same coordinate system.
- The raster files are fully overlapping (the entire country).
- The region is not defined per se in the raster file, but in an additional
shape file (biogeo.shp).
- For sure I can carry out some zonal statistics using raster and shape
file, but to merge the regions I need all the pixels form a regions as input
file for the merging process. This process is more than just selecting
regions or cropping. Do you have any suggestions?

Kind regards
Sibylle

___
QGIS-User mailing list
QGIS-User@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user