#1 Thu 23 September 2021 12:08
- jydee
- Participant occasionnel
- Date d'inscription: 2 Nov 2010
- Messages: 41
charger du COG dans Qgis
Bonjour à tous,
Je ne parviens pas à charger du COG dans Qgis.
Exemple de fichier au format COG qui devrait fonctionner :
http://files.opendatarchives.fr/profess … _IGN69.tif
ou un pris au hasard ici :
http://files.opendatarchives.fr/profess … _20210118/
Mais rien n'y fait, Qgis affiche un message d'erreur!
Qui est parvenu à charger du COG dans Qgis et comment avez vous fait?
J'ai réalisé une dalle au format cog, cad avec gdal_translate -of COG, ici :
https://drive.google.com/drive/folders/ … sp=sharing
Qui peut me la déposer sur un serveur sachant qu'elle est valide (testée ici http://cog-validate.radiant.earth/html/validate ) afin que je test dans Qgis.
Aussi, quand on a plusieurs dalles, le .vrt est-il indispensable?
Merci de votre aide
Jean-Yves
Dernière modification par jydee (Thu 23 September 2021 12:10)
Hors ligne
#2 Thu 23 September 2021 12:27
- cquest
- Participant assidu
- Date d'inscription: 6 Jan 2013
- Messages: 864
Re: charger du COG dans Qgis
Je viens d'essayer avec QGis, ça s'affiche sans problème pour moi.
Quel est le message d'erreur ?
Christian Quest - https://amicale.net/@cquest sur Mastodon (terminé twitter/X)
Membre fondateur et porte parole d'OpenStreetMap France
A l'origine de opendatArchives, OpenEventDatabase
Hors ligne
#3 Thu 23 September 2021 12:41
- jydee
- Participant occasionnel
- Date d'inscription: 2 Nov 2010
- Messages: 41
Re: charger du COG dans Qgis
Je viens d'essayer avec QGis, ça s'affiche sans problème pour moi.
Quel est le message d'erreur ?
bonjour,
j'ai fais une capture vidéo, j'ai Qgis 3.4.4
https://drive.google.com/file/d/1QC8vR2 … sp=sharing
Le message d'erreur est le suivant :
2021-09-23T12:41:43 CRITICAL Couche non valide : GDAL provider Cannot open GDAL dataset /vsicurl/http://files.opendatarchives.fr/professionnels.ign.fr/rgealti/repack/RGEALTI_MNT_1M_TIF_LAMB93_IGN69_D089_20210118/
RGEALTI_FXX_080_674_MNT_LAMB93_IGN69.tif:
`/vsicurl/http://files.opendatarchives.fr/professionnels.ign.fr/rgealti/repack/RGEALTI_
MNT_1M_TIF_LAMB93_IGN69_D089_20210118/RGEALTI_FXX_080_674_MNT_LAMB93_IGN69.tif'
does not exist in the file system, and is not recognized as a supported dataset name.
Raster layer Le fournisseur de données n'est pas valide
(prestataire : gdal, URI : /vsicurl/http://files.opendatarchives.fr/professionnels.ign.fr/rgealti/repack/
RGEALTI_MNT_1M_TIF_LAMB93_IGN69_D089_20210118/RGEALTI_FXX_080_674_MNT_LAMB93_IGN69.tif
Dernière modification par jydee (Thu 23 September 2021 12:49)
Hors ligne
#4 Thu 23 September 2021 12:50
- cquest
- Participant assidu
- Date d'inscription: 6 Jan 2013
- Messages: 864
Re: charger du COG dans Qgis
Le VRT n'est par contre pas la bonne approche, le COG justement permet d'avoir un gros et unique TIFF qui sera requêté selon les besoins.
J'ai vraiment fait ça très vite pour tester.
Christian Quest - https://amicale.net/@cquest sur Mastodon (terminé twitter/X)
Membre fondateur et porte parole d'OpenStreetMap France
A l'origine de opendatArchives, OpenEventDatabase
Hors ligne
#5 Thu 23 September 2021 13:17
- jydee
- Participant occasionnel
- Date d'inscription: 2 Nov 2010
- Messages: 41
Re: charger du COG dans Qgis
Le VRT n'est par contre pas la bonne approche, le COG justement permet d'avoir un gros et unique TIFF qui sera requêté selon les besoins.
J'ai vraiment fait ça très vite pour tester.
D'accord, je prends note que le .vrt n'est pas la bonne approche.
Mais quelle version de Qgis utiliser pour que cela fonctionne?
Merci
Hors ligne
#6 Thu 23 September 2021 14:54
- SANTANNA
- Moderateur
- Lieu: Angers
- Date d'inscription: 18 Jan 2008
- Messages: 3881
Re: charger du COG dans Qgis
Bonjour,
Mais quelle version de Qgis utiliser pour que cela fonctionne?
Essayez avec une plus récente. 3.4 a au moins deux ans d'âge et QGIS bouge vite. Je viens d'essayer votre premier lien et certains des liens dans le dossier, sans souci dans une 3.16.
Hors ligne
#7 Thu 23 September 2021 16:26
- jydee
- Participant occasionnel
- Date d'inscription: 2 Nov 2010
- Messages: 41
Re: charger du COG dans Qgis
Merci, en fait il s'agit de mon réseau qui doit bloquer la donnée
Hors ligne
#8 Fri 24 September 2021 10:17
- JRM
- Participant assidu
- Lieu: Arras
- Date d'inscription: 15 Apr 2009
- Messages: 521
Re: charger du COG dans Qgis
Le truc avec ces formats requérables en http c'est de ne pas se situer derrière un proxy monté par votre DSI où les certificats SSL valides d'origines sont remplacés par des certificats auto-signés reconnus à juste titre comme invalides par toutes les applications correctes.
Dernière modification par JRM (Fri 24 September 2021 10:17)
Hors ligne
#9 Mon 27 September 2021 10:55
- jydee
- Participant occasionnel
- Date d'inscription: 2 Nov 2010
- Messages: 41
Re: charger du COG dans Qgis
..
Dernière modification par jydee (Mon 27 September 2021 12:47)
Hors ligne
#10 Mon 27 September 2021 16:28
- cquest
- Participant assidu
- Date d'inscription: 6 Jan 2013
- Messages: 864
Re: charger du COG dans Qgis
J'ai commencé à repackager le RGEALTI 1M en COG départementaux + un VRT national, en commençant par l'île-de-France (la suite va arriver).
https://data.cquest.org/ign/rgealti/rep … 69_FXX.vrt
C'est bien rapide
Moins compact que le .7z d'origine (x2 à x2.5) mais directement utilisable en "flux" tout en étant téléchargeable. QGis peut même appliquer des traitements à la volée (l'ombrage fonctionne très bien).
Par contre, les fichiers "COG" publiés par l'IGN pour l'Ortho du 74 n'apportent absolument rien:
- ils sont remis en .7z, ce qui les rend non requêtables
- chaque petite dalle est bien en COG, mais trop petite pour que ce soit utile
J'ai donc repackagé ça pour test ici: https://data.cquest.org/ign/orthohr/repack/test.tiff
Le principe d'un seul fichier par département fonctionne très bien et le volume final est similaire aux .7z (+3% seulement)
L'autre avantage c'est qu'en téléchargeant le fichier, il est directement utilisable, pas besoin de l'horrible décompression 7z
Christian Quest - https://amicale.net/@cquest sur Mastodon (terminé twitter/X)
Membre fondateur et porte parole d'OpenStreetMap France
A l'origine de opendatArchives, OpenEventDatabase
Hors ligne
#12 Mon 27 September 2021 21:24
- Shot2
- Participant actif
- Date d'inscription: 22 Jan 2020
- Messages: 114
Re: charger du COG dans Qgis
Penser à activer la compression delta (-co PREDICTOR=2) pour gagner facilement encore 5-20% de volume. Et éventuellement encore quelques Mo en réduisant la taille de bloc (256 mieux que 512).
Dernière modification par Shot2 (Mon 27 September 2021 21:32)
Hors ligne
#13 Fri 01 October 2021 09:00
- jydee
- Participant occasionnel
- Date d'inscription: 2 Nov 2010
- Messages: 41
Re: charger du COG dans Qgis
Le VRT n'est par contre pas la bonne approche, le COG justement permet d'avoir un gros et unique TIFF qui sera requêté selon les besoins.
J'ai vraiment fait ça très vite pour tester.
Pourquoi vous n'avez pas également retenu la solution du .vrt avec un .ovr?
J'ai réalisé l'ovr pour le département 74 au format cog :
https://drive.google.com/drive/folders/ … sp=sharing
et la donnée se charge en moins d'une seconde..
Hors ligne
#14 Fri 01 October 2021 09:15
- cquest
- Participant assidu
- Date d'inscription: 6 Jan 2013
- Messages: 864
Re: charger du COG dans Qgis
Sauf erreur, le VRT et surtout les .ovr associés sont spécifiques à GDAL, là où le format COG n'est pas spécifique à GDAL et utilisable par des logiciels n'utilisant pas GDAL.
Je ne suis pas au fait de l'avancement des standards OGC, mais je parie que le COG sera standardisé vu que ce n'est qu'une façon ordonnée de ranger les données dans un géotiff déjà standardisé.
Christian Quest - https://amicale.net/@cquest sur Mastodon (terminé twitter/X)
Membre fondateur et porte parole d'OpenStreetMap France
A l'origine de opendatArchives, OpenEventDatabase
Hors ligne
#15 Fri 01 October 2021 09:46
- jydee
- Participant occasionnel
- Date d'inscription: 2 Nov 2010
- Messages: 41
Re: charger du COG dans Qgis
Sauf erreur, le VRT et surtout les .ovr associés sont spécifiques à GDAL, là où le format COG n'est pas spécifique à GDAL et utilisable par des logiciels n'utilisant pas GDAL.
Je ne suis pas au fait de l'avancement des standards OGC, mais je parie que le COG sera standardisé vu que ce n'est qu'une façon ordonnée de ranger les données dans un géotiff déjà standardisé.
merci pour votre réponse et bonne journée
Hors ligne
#16 Tue 05 October 2021 10:10
- jydee
- Participant occasionnel
- Date d'inscription: 2 Nov 2010
- Messages: 41
Re: charger du COG dans Qgis
bonjour,
Je test la réalisation de COG départementaux à partir de la BDO HR (jp2) du département 74 et c'est très long.
Je n'ai pas fais 10% en 24h (voir PJ).
Voici les commande que j'utilise :
pushd "C:\Program Files\QGIS 3.4\"
@call OsGeo4W.bat gdalbuildvrt -addalpha -allow_projection_difference -a_srs EPSG:2154 "%~dp0\mosaique.vrt" "%~dp0\*.jp2"
@call Osgeo4w.bat @call "C:\Program Files\QGIS 3.16\OsGeo4W.bat" gdal_translate -co BIGTIFF=YES -of COG -co predictor=2 --config GDAL_CACHEMAX 50000 -co NUM_THREADS=4 -co COMPRESS=JPEG -a_srs EPSG:2154 "%~dp0\mosaique.vrt" "%~dp0\mosaique_cog.tif"
Pourtant j'ai une station de travail assez puissante : 64 Go de ram et processeur Intel(R) Xeon(R) E-2144G CPU @ 3.60GHz 3.60 GHz
@cquest : Pouvez vous me dire le temps de traitement de votre côté et si vous remarquez une erreur dans ma méthode
Merci
Hors ligne
#17 Tue 05 October 2021 13:05
- cquest
- Participant assidu
- Date d'inscription: 6 Jan 2013
- Messages: 864
Re: charger du COG dans Qgis
La décompression JEG2000 est très lente si l'on n'a pas un GDAL qui utilise une librairie dédiée (comme celle d'hexagon qui gère ECW/JPEG2000).
Il y a de très fortes chance que ce soit la cause principale de la lenteur du traitement.
Un détail (sans lien), il me semble que PREDICTOR=2 n'a pas d'effet avec COMPRESS=JPEG
Dernière modification par cquest (Tue 05 October 2021 14:17)
Christian Quest - https://amicale.net/@cquest sur Mastodon (terminé twitter/X)
Membre fondateur et porte parole d'OpenStreetMap France
A l'origine de opendatArchives, OpenEventDatabase
Hors ligne
#18 Tue 05 October 2021 15:24
- fbecir
- Participant assidu
- Lieu: Saint-Mandé
- Date d'inscription: 16 Sep 2008
- Messages: 512
Re: charger du COG dans Qgis
Bonjour
Les questions de transparence avec le TIFF sont toujours épineuses. Il y a deux manières de faire :
1. Créer un masque de transparence sous la forme d'une image avec le tag PhotometricInterpretation (262) = 4 (Transparency Mask). Cette image est sous la forme d'une image 1 bit. Donc le fichier TIFF doit contenir l'image RGB + l'image Masque. Problème avec le COG : on utilise déjà le fait qu'une image TIFF peut contenir plusieurs images pour stocker la pyramide d'images sous-échantillonnées. Donc là, je ne sais pas comment faire (c'est d'ailleurs le problème inhérent à la spécification du TIFF quand on a plusieurs IFD dans une image : il n'y a aucune indication sur le lien "logique" qui existe entre ces IFD). Je n'ai pas l'impression que le COG ait prévu ce cas.
2. Utiliser le tag ExtraSamples (338). Ce tag est apparu avec la version 6 des spécifications du TIFF. Il permet de rajouter pour chaque pixel de l'image une valeur de canal alpha. Par contre, je ne sais pas si ce qu'il se passe quand on veut compresser en JPEG car l'algorithme prend seulement du RGB en entrée (et pas du RGBA). Par contre en LZW ou Deflate, cela ne pose pas de soucis.
Cordialement
Hors ligne
#19 Tue 05 October 2021 16:04
- cquest
- Participant assidu
- Date d'inscription: 6 Jan 2013
- Messages: 864
Re: charger du COG dans Qgis
En fait, les fichiers COG que j'ai généré en JPEG ont bien un masque, j'ai juste eu un problème lorsque j'ai testé avec QGIS qui m'a affiché n'importe quoi, mais en revérifiant ça semble bon.
Exemple: https://data.cquest.org/ign/orthohr/rep … -01-01.tif
Un -addalpha dans gdalbuildvrt fait que le "gdal_translate -of COG -co COMPRESS=JPEG" génère bien un TIFF JEPG+masque
Le script de conversion que j'utilise est ici: https://data.cquest.org/ign/orthohr/rep … tif2cog.sh
Pour les ressources nécessaires, c'est quand même violent.
Le gdal_translate en est à 72Go de RAM sur un petit département (93) et il n'est qu'à 60% de progression...
Ceci confirme que ça vaut le coup qu'une conversion soit faite et que le résultat directement exploitable soit partagé.
Christian Quest - https://amicale.net/@cquest sur Mastodon (terminé twitter/X)
Membre fondateur et porte parole d'OpenStreetMap France
A l'origine de opendatArchives, OpenEventDatabase
Hors ligne
#20 Tue 05 October 2021 17:24
- fbecir
- Participant assidu
- Lieu: Saint-Mandé
- Date d'inscription: 16 Sep 2008
- Messages: 512
Re: charger du COG dans Qgis
Christian, en regardant la structure de ton fichier, voilà ce que je constate :
1. C'est la technique du masque de transparence qui est utilisé. Donc on peut compresser en JPEG sans problème
2. Le premier IFD (c'est-à-dire la première image contenue dans le TIFF) contient l'image pleine résolution (125000 x 75000 pixels) en YCbCr (ce qui est normal car il y a une compression JPEG)
3. Le deuxième IFD contient une image (125000 x 75000 pixels) qui est le masque de transparence de la première image
4. Le troisième IFD contient une image (62500 x 37500 pixels) en YCbCr, donc la résolution / 2 de la première image
5. Le quatrième IFD contient une image (31250 x 18750 pixels) en YCbCr, donc la résolution / 4 de la première image
6. et ainsi de suite
7. et puis on ensuite tous les masques de transparence des résolutions sous-échantillonnées
Donc je suis un peu surpris par cet ordre dans le COG, ce qui pourrait expliquer les problèmes dans QGIS. On pourrait s'attendre à avoir sous toutes les images YCbCr puis tous les masques, ou alors avoir à chaque fois l'image YCbCr suivi de son masque.
A vérifier dans les spécifications du COG.
Mais cela illustre bien le problème du COG : comment savoir que l'IFD N est le masque de transparence de l'IFD P ou que l'IFD K est l'image sous-échantillonnée de l'IFD L ... Rien ne l'indique formellement donc cela laisse cours à l'interprétation, ce qui n'est jamais bon ...
(à l'origine le TIFF prévoyait le stockage de plusieurs images dans un même fichier pour permettre par exemple de stocker des fax sur plusieurs pages, donc juste une relation d'ordre entre les pages)
Hors ligne
#21 Tue 05 October 2021 18:54
- Shot2
- Participant actif
- Date d'inscription: 22 Jan 2020
- Messages: 114
Re: charger du COG dans Qgis
Pour les ressources nécessaires, c'est quand même violent.
Le gdal_translate en est à 72Go de RAM sur un petit département (93) et il n'est qu'à 60% de progression...
Vieille version de GDAL+OpenJP2 ? auquel cas ça sera volontiers poussif. Mieux vaut alors passer par un autre workflow :
décompression jp2 -> tif (avec plein de gigaoctets de tifs à la clé) puis création vrt puis conversion vrt en COG.
Testé sur mon vieux laptop de 2014, convertir l'OrthoHR du 93 a pris 45mn chrono (et pas plus de 16Go de RAM).
Comment ? opj_decompress (OpenJPEG 2.4, 8 threads : 15mn pour les 20 dalles) -> gdalbuildvrt (-addalpha) -> gdal_translate (GDAL 3.2, COG, JPEG, all_cpus : 30 mn). Inconvénient : il faut un peu de place sur son SSD pour les .tif intermédiaires (~2 Go par .tif)
Code:
$time sh -c 'for i in *.jp2; do ~/.local/bin/opj_decompress -threads ALL_CPUS -i "$i" -o "$(basename "$i" .jp2).tif"; done' [INFO] Start to read j2k main header (572). ... [INFO] Generated Outfile 93-2018-0670-6875-LA93-0M20-E080.tif decode time: 36186 ms real 14m28.935s ... $ gdalbuildvrt -vrtnodata "255 255 255" -hidenodata -addalpha truc.vrt *.tif 0...10...20...30...40...50...60...70...80...90...100 - done. $ time GDAL_NUM_THREADS=ALL_CPUS GDAL_CACHEMAX=8192 GDAL_DISABLE_READDIR_ON_OPEN=YES GDAL_FORCE_CACHING=YES gdal_translate -of COG -co NUM_THREADS=ALL _CPUS -co BIGTIFF=YES -co COMPRESS=JPEG truc.vrt blah.gtiff Input file size is 150000, 125000 0...10...20...30...40...50...60...70...80...90...100 - done. real 28m26.232s
edit: et ô joie (ou magie noire ?) ça préserve bel et bien la transparence/masque à tous les niveaux aucun souci d'affichage sous p.ex. GlobalMapper.
Dernière modification par Shot2 (Tue 05 October 2021 19:32)
Hors ligne
#22 Mon 11 October 2021 11:36
- jydee
- Participant occasionnel
- Date d'inscription: 2 Nov 2010
- Messages: 41
Re: charger du COG dans Qgis
La décompression JEG2000 est très lente si l'on n'a pas un GDAL qui utilise une librairie dédiée (comme celle d'hexagon qui gère ECW/JPEG2000).
Il y a de très fortes chance que ce soit la cause principale de la lenteur du traitement.
Un détail (sans lien), il me semble que PREDICTOR=2 n'a pas d'effet avec COMPRESS=JPEG
Merci pour votre réponse
Hors ligne