Primo riepilogo dei test eseguiti sul plugin

[DanieleSav]

test_plugin_chm_from_lidar.xlsx

In allegato, sotto forma tabellare, un primo riepilogo dei test eseguiti sulle singole campagne di volo. Il test ha avuto esito positivo solo per 5 campagne di volo, quindi sarà necessario un ulteriore sforzo congiunto per risolvere i numerosi problemi segnalati.

[rmarzocchi84]

https://github.com/gtergeomatica/chm_from_lidar/issues/7 inizierei da qui

[RobiFag]

@sergiozenforeste Per quanto riguarda la campagna 2015_Lidar_BL_VI\4_B_Datielaborati abbiamo corretto il problema del doppio "" nel nome del DSM (il problema era presente solo in alcune tile). Correggendo questo errore, ci siamo accorti che alcune tile hanno indicato nella colonna N_DSM il nome del file dtm e non quello del dsm. Potete verificare che effettivamente esista un file dsm per le tile con i seguenti valori in N_DTM e dirci cosa scrivere in N_DSM? D46201195_0101_DTM.asc D46231203_0101_DTM.asc D46281218_0101_DTM.asc D46371197_0101_DTM.asc D46411201_0101_DTM.asc D46411223_0101_DTM.asc D46491244_0101_DTM.asc D46561223_0101_DTM.asc D46591224_0101_DTM.asc D46561215_0101_DTM.asc D46341178_0101_DTM.asc

[RobiFag]

Abbiamo verificato quanto di nostra competenza nel file di riepilogo. Alleghiamo il file aggiornato con indicate le modifiche fatte, le cause di eventuali problematiche non dipendenti dal codice del plugin e eventuali richieste di verifica ulteriore dei dati. test_plugin_chm_from_lidar.xlsx

Sottomettiamo a breve una nuova versione, vi aggiorniamo appena verrà pubblicato dal team Qgis

[DanieleSav]

2015_lidar_bl_vi.zip

Allego la tabella di corrispondenza DTM --> DSM per la campagna 2015_Lidar_BL_VI

[rmarzocchi84]

Nel frattempo la versione del plugin sottomessa ieri è stata pubblicata. Probabilmente serve riavviare QGIS per trovarla fra i plugin aggiornabili

[DanieleSav]

Per quanto riguarda la campagna 2012_Lidar_Consbon_Veronese\LIDAR l'errore segnalato è duplice. La decompressione dei files compete al cartografico, ma ci sarebbe anche da integrare il percorso di rete, che risulta incompleto. A questo riguardo si può optare per il percorso che manda ai raster in gauss-boaga o a quelli in wgs84. I percorsi relativi sono i seguenti, ma sarà necessario verificare se verranno cambiati dopo la decompressione: \Lidar\2012_Lidar_Consbon_Veronese\LIDAR\DTM\ZIP\Maglia-0.50m\GAUSS-BOAGA \Lidar\2012_Lidar_Consbon_Veronese\LIDAR\DSM\ZIP\Maglia-0.50m\GAUSS-BOAGA \Lidar\2012_Lidar_Consbon_Veronese\LIDAR\DTM\ZIP\Maglia-0.50m\UTM-WGS84 \Lidar\2012_Lidar_Consbon_Veronese\LIDAR\DSM\ZIP\Maglia-0.50m\UTM-WGS84 Se si scelgono i primi, va corretta l'indicazione dell'epsg in tabella, mentre per i secondi dovrebbe essere corretto quello indicato. Secondo voi cosa conviene fare? Allego a titolo esemplificativo un asc del DTM e del DSM per ciascun sistema di riferimento 32_63605028_GAU.zip 32_63605028_GAU.zip 32_63605028_WGS.zip 32_63605028_WGS.zip

--

[RobiFag]

Corretti i nomi per la campagna 2015_Lidar_BL_VI

[RobiFag]

per quanto riguarda la campagna 2012_Lidar_Consbon_Veronese\LIDAR vi chiederei prima di tutto di rinominare la cartelle \Maglia-0.50m e \GAUSS-BOAGA o \UTM-WGS84 rimuovendo i caratteri come '.' e '-' Qgis infatti può dare qualche problema con i percorsi che includono caratteri particolari (es. spazi, trattini, asterischi, punti, ecc.). Per qunato riguarda il sistema di riferimento invece confermo che i file _GAU sono in 3003 mentre i file _WGS non sono in wgs84 come indicato in tabella (epsg 4326) ma in wgs84-utm32 (32632) quindi il codice in tabella andrebbe modificato in entramnbi i casi.

[rmarzocchi84]

Fatta la verifica su CRS. Sono effettivamente 3003 e 32632 però ci siamo accorti di una traslazione dovuta probabilmente all'utilizzo dei grigliati per ottenere i file GAU.

Metterei 32632 in tabella, ma per un'ultima verifica potete controllare se esistono file dei metadati?

Restiamo in attesa di conoscere il percorso ai file decompressi (senza "." e "-") per correggere i percorsi anche nel file.

[rmarzocchi84]

Fatta la verifica su CRS. Sono effettivamente 3003 e 32632 però ci siamo accorti di una traslazione dovuta probabilmente all'utilizzo dei grigliati per ottenere i file GAU.

Metterei 32632 in tabella, ma per un'ultima verifica potete controllare se esistono file dei metadati?

Restiamo in attesa di conoscere il percorso ai file decompressi (senza "." e "-") per correggere i percorsi anche nel file.

Se avete delle news in merito entro la mattinata inseriamo le modifiche nella nuova release, se no faremo prossima settimana