Le portail francophone de la géomatique

cquest · Wed 06 January 2021 23:08

Le format COG est un geotiff spécialement organisé pour pourvoir être utilisé à distance via le protocole HTTP, sans avoir à télécharger les fichiers en entiers.

https://www.cogeo.org/

Côté serveur, cela allège énormément comparé à un WMS quand même mille fois plus usine à gaz qu'un vulgaire apache ou nginx.

Côté client, j'ai fait un essai avec QGis et c'est rapide et fluide.

De nombreux institutionnels diffusent de l'imagerie sous cette forme, par exemple la NASA ou USGS.

Vous semblerait-il utile de repackager les orthos HR de la BD Ortho dans ce format et de les héberger sur opendatarchives (ou ailleurs) ?

Dernière modification par cquest (Wed 06 January 2021 23:08)

Benoît595 · Thu 07 January 2021 11:40

Bonjour,

Cela paraît effectivement une bonne idée, les flux WMS sont très bien mais montrent parfois leurs limites

Shot2 · Thu 07 January 2021 12:12

Sera-ce de l'archivage... avec pertes ?

Dernière modification par Shot2 (Thu 07 January 2021 12:12)

fbecir · Thu 07 January 2021 12:18

Benoît595 a écrit:

Bonjour,

Cela paraît effectivement une bonne idée, les flux WMS sont très bien mais montrent parfois leurs limites

En toute rigueur, il faut plutôt comparer avec du WMTS.
En effet, en WMS le serveur fait l'extraction et la mise en résolution de l'image demandée par l'utilisateur, ce qui prend du temps pour le serveur (mais qui facilite la vie côté client : le client récupère directement l'image qu'il veut avec l'emprise et la résolution qui lui conviennent).
En WMTS, on a une pyramide d'images avec des résolutions données et c'est à l'utilisateur d'aller prendre les images qui lui faut et ensuite de les assembler et de les mettre en résolution.
En COG, c'est la même chose qu'en WMTS, on accède à une des résolutions définies dans le COG et on doit ensuite récupérer les tiles qui nous intéressent (et ensuite les assembler et les mettre à l'échelle).

La différence entre COG et WMTS est que pour le WMTS on a un fichier image par tile (donc une entête de fichier, dont la taille dépend du format choisi, en général JPG ou PNG). Donc, pour chaque tile, il faut analyser l'entête.
Dans le cas du COG, il y a un seul fichier image, donc une seule analyse d'entête, et ensuite on accède aux pixels directement. On doit donc gagner un petit peu en nombre d'octets qui transitent et en temps d'analyse de l'entête.
Il serait intéressant de mesurer l'écart entre les deux technologies.

Cordialement

fbecir · Thu 07 January 2021 12:23

Shot2 a écrit:

Sera-ce de l'archivage... avec pertes ?

Le COG, c'est du TIF. Donc on peut avoir de la compression sans perte (type LZW) ou avec pertes (type JPG).

Shot2 · Thu 07 January 2021 12:27

fbecir a écrit:

Shot2 a écrit:
Sera-ce de l'archivage... avec pertes ?

Le COG, c'est du TIF. Donc on peut avoir de la compression sans perte (type LZW) ou avec pertes (type JPG).

Je sais bien ! (c'est même du GeoTIFF... )
D'où ma question à l'initiateur du fil : sera-ce de l'archivage avec pertes ?

Dernière modification par Shot2 (Thu 07 January 2021 12:28)

fbecir · Thu 07 January 2021 13:10

Shot2 a écrit:

Je sais bien ! (c'est même du GeoTIFF... )
D'où ma question à l'initiateur du fil : sera-ce de l'archivage avec pertes ?

Désolé, je n'avais pas saisi le sens de la question.
Connaissant Christian, je doute qu'il s'amuse à introduire des pertes là où il n'y en avait pas.

cquest · Thu 07 January 2021 14:15

Les orthohr sont déjà avec perte (faible) sauf pour de rares départements (Alsace).

Des pertes, il y en aura sûrement un petit peu avec les retraitements même si je tente de les minimiser, mais si ça permet une utilisation plus facile en échange d'une petite perte ça peut rester intéressant pour pas mal de monde.

Aujourd'hui, les ortho HR sont hébergées par OSM France sur wms.openstreetmap.fr en WMS et TMS, avec un retraitement des JPEG2000 car c'est un format bien adapté à l'archivage mais pas trop pour fournir des pixels en live rapidement. Donc je remet tout en geopackage webp pour donner ça à manger à mapserver et tilecache.

En COG, des dalles plus grandes seraient intéressantes, et il doit être possible de les assembler pour GDal via un .vrt
J'ai testé un vrt accessible à distance en http et ça fonctionne

Shot2 · Thu 07 January 2021 14:49

cquest a écrit:

Les orthohr sont déjà avec perte (faible) sauf pour de rares départements (Alsace).

Oui D'où ma question sur une éventuelle étape de traitement avec pertes (JPEG-in-GeoTIFF...) si le but est de l'archivage (et non du service de données).

cquest a écrit:

Des pertes, il y en aura sûrement un petit peu avec les retraitements même si je tente de les minimiser, mais si ça permet une utilisation plus facile en échange d'une petite perte ça peut rester intéressant pour pas mal de monde.

Est-ce que ce sera vraiment plus "facile" que servir aux clients des tuiles WMTS, façon Geoportail ? ce qui contrairement au COG est déjà largement géré en dehors de QGIS, et imposerait de toute façon aussi une recompression (sauf à faire du LZW/Deflate-in-TIFF, mais bonjour le volume pour de l'orthophoto...)

cquest a écrit:

Aujourd'hui, les ortho HR sont hébergées par OSM France sur wms.openstreetmap.fr en WMS et TMS, avec un retraitement des JPEG2000 car c'est un format bien adapté à l'archivage mais pas trop pour fournir des pixels en live rapidement. Donc je remet tout en geopackage webp pour donner ça à manger à mapserver et tilecache.

Dommage que Mapserver ne soit pas (encore) capable d'utiliser le JP2 d'origine pour en "fournir [les] pixels en live rapidement", car c'est l'un des points forts de JPEG2000. Le meilleur des deux mondes quand on a des données-source déjà en JP2, évitant des manipulations et recompressions.

Peut-être regarder du côté de JPIP ? une implémentation libre existe, et GDAL (donc peut-être aussi QGIS ?) tout comme divers SIG savent l'utiliser.

Dernière modification par Shot2 (Fri 08 January 2021 00:49)

sc · Thu 07 January 2021 17:33

Bonjour,

Pour information, le serveur mixte WMS/WMTS ROK4 conforme INSPIRE, utilisé par le Géoportail, est basé sur l'utilisation de fichiers TIFF tuilés (avec des tuiles pouvant être compressées). Il a été spécialement conçu pour optimiser les accès aux fichiers, notamment en mode WMTS. Par exemple, il n'est pas nécessaire d'ouvrir systématiquement un fichier à chaque requête d'une tuile.

Le code est en open source :
https://github.com/rok4/rok4

cquest · Thu 07 January 2021 18:29

mapserver sait lire tout ce que GDAL sait lire, donc du JPEG2000.
Le problème ce sont les implémentations libre du JPEG2000 qui ne sont pas performantes du tout.
Le plus efficace reste la lib propriétaire ECW d'Erdas qui gère aussi le JPEG2000, mais l'utilisation sur un serveur nécessite une licence... et une recompilation de GDAL.

En fait, ce que j'imaginais avec le format COG n'est pas forcément de remplacer un WMS/WMTS, mais de permettre d'avoir des fichiers hybrides, qui peuvent être utilisés dans leur globalité ou juste pour une petite zone (et donc remplacer WMS/WMTS).

En stockage, je viens de vérifier sur mon test avec l'Yonne de 2018...
- 34.4Go de fichiers 7z/JPEG2000 "E080"
- 37.6Go en COG JPEG réglages par défaut
- 19Go en WEBP !

Les pertes ne sont vraiment pas visibles à l'oeil nu en JPEG ou WEBP.

Pour juste 10% de plus (en JPEG) c'est un bon compromis pour permettre:
- de ne télécharger que les dalles dont on a besoin (et pas un département entier en 7z qui prend un temps fou à décompresser)
- d'utiliser en mode COG ces mêmes dalles
- de ne nécessiter côté serveur aucun logiciel autre qu'un bête serveur HTTP

En WEBP, on gagne sur tous les tableaux... à part peut être la compatibilité avec des outils propriétaires ?

Un mapserver pourrait taper directement dedans pour fournir un accès plus classique.

Un stockage unique pour 3 services différents, c'est assez optimal.

Ce qui est sûr, c'est que ça va faire une belle moulinette pour tout retraiter, mais c'est l'hiver, ça me chauffera mon bureau !

Shot2 · Fri 08 January 2021 01:02

WebP (que ce soit dans du TIFF, GPKG...) n'est pas encore très bien géré partout malheureusement. Et en effet la gestion du JPEG2000 par GDAL/Mapserver reste sub-optimale peu importe le driver employé. (à ce sujet : peut-être essayer le décodage de JP2 hors de GDAL, si on est pressé)

Donc oui, du JPEG-in-TIFF semble un compromis correct à l'heure actuelle - peut-être en poussant un peu la qualité ? Au cas où ces COG devraient subir un nouveau cycle de compression JPEG pour être servis optionnellement par WMS...

Dernière modification par Shot2 (Fri 08 January 2021 01:11)

Le Masson · Fri 21 May 2021 08:06

Bonjour,
je remonte le sujet, parce qu'on (IGN) propose une mise à disposition "test" en COG.
Les données sont par là:ftp://ORTHO_HR_NL_ext:puiweep2Boh3ohsh@texte-a-enlever.ftp3.ign.fr/, en COG90 et en COG75. Ortho (HR, forcément) sur le département 74.
Je prépare un questionnaire en parallèle pour recueillir les avis. Si vous avez un avis sur les questions à poser, je suis preneur!
Matthieu (IGN)

Hydrolithe · Fri 21 May 2021 09:02

Bonjour,

Je m'écarte un peu du sujet mais j'avais lu un benchmark des formats raster (dont COG) réalisé par OpenGIS l'an dernier, qui permet d'avoir un vue assez détaillée :

https://www.opengis.ch/fr/2020/06/09/of … or-qfield/

Pierre

JRM · Fri 21 May 2021 09:54

Le Masson > super ! Par contre, est-ce qu'un accès http(s) ne serait pas à privilégier plutôt qu'une diffusion ftp ? Ce protocole disparaît des navigateurs et ne permettrait pas un appel direct depuis une application client js, iem pour le fait de l’appeler depuis QGIS ou gdal pour récupérer une zone d'intérêt plutôt que la totalité de la donnée.

Je ne reviens pas sur les échanges précédents mais le COG a vite trouvé sa place chez nous en remplacement des tif+ovr, les deux principaux blocages étant le support des logiciels proprio pour les appels http et les difficultés liés au proxy d'entreprise ayant la mauvaise habitude d'imposer leur certificat ssl autosigné

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Sites amis	Agenda Biblio Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Le portail francophone de la géomatique

#1 Wed 06 January 2021 23:08

Ortho photos en COG ? (Cloud Optimized Geotiff)

#2 Thu 07 January 2021 11:40

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

#3 Thu 07 January 2021 12:12

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

#4 Thu 07 January 2021 12:18

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

#5 Thu 07 January 2021 12:23

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

#6 Thu 07 January 2021 12:27

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

#7 Thu 07 January 2021 13:10

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

#8 Thu 07 January 2021 14:15

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

#9 Thu 07 January 2021 14:49

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

#10 Thu 07 January 2021 17:33

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

#11 Thu 07 January 2021 18:29

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

#12 Fri 08 January 2021 01:02

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

#13 Fri 21 May 2021 08:06

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

#14 Fri 21 May 2021 09:02

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

#15 Fri 21 May 2021 09:54

Re: Ortho photos en COG ? (Cloud Optimized Geotiff)

Pied de page des forums