Le portail francophone de la géomatique

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

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

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

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.

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).

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...)

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)

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 !

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)

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é