refactor(API): replace jimp by gdal

[gmaillet]

version à tester. J'ai l'impression que Jimp limite les performances lorsque l'on monte charge, mais il faudrait faire plus de tests pour vérifier.

[ftoromanoff]

Les tests entrent dans une boucle infinie...

[ftoromanoff]

J'ai remarqué aussi de mon coté que c'était les lignes 97 -> 105 du fichier gdal_processing qui prenaient du temps. b.forEach((band) => { if (band in blocks) return; const selectedBand = band === 3 ? dsIr.bands.get(1) : ds.bands.get(band + 1); const B = z === 0 ? selectedBand : selectedBand.overviews.get(z - 1); blocks[band] = B.pixels.readBlock(x, y); });

[ftoromanoff]

après quelques essais en local pour une requête get/ wmts (getTile) la requête prend ~145ms pour ~215 avant.

[coveralls]

Pull Request Test Coverage Report for Build 3195514192

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 44 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-0.1%) to 94.952%

---

Files with Coverage Reduction	New Missed Lines	%
middlewares/patch.js	11	94.58%
middlewares/wmts.js	14	92.5%
gdal_processing.js	19	91.24%
<!--	Total:	44		-->

Totals
Change from base Build 3082883775:	-0.1%
Covered Lines:	5975
Relevant Lines:	6266

---

💛 - Coveralls

[gmaillet]

Voilà, une version corrigée des problèmes détectés par l'intégration continue. Je n'ai pas l'impression que le bilan soit réellement positif sur les performances mais ça reste à vérifier et on peut garder cette PR sous le coude au cas où. Par contre, en travaillant sur cette PR, je me suis rendu compte qu'il y a probablement une faille dans le système actuel: on a une gestion de cache pour éviter d'ouvrir trop souvent les images, mais cette gestion ne fonctionne bien que si on travaille avec une seule instance. Lorsqu'on utilise PM2, je pense qu'on pourrait avoir une image qui reste ouverte dans le cache alors qu'elle a été modifiée par une autre instance de l'API. Dans ce cas, je pense qu'on pourrait avoir une erreur de rafraichissement dans iTowns (personnellement je ne pense pas l'avoir déjà observé).

[amrosu]

Le client itowns ne fonctionne pas avec cette branche - lors de 'npm run build', on a ces erreurs :

ERROR in ./node_modules/shpjs/lib/binaryajax-browser.js 4:15-39
Module not found: Error: Can't resolve 'buffer' in 'packo/itowns/node_modules/shpjs/lib'
...

ERROR in ./node_modules/shpjs/lib/binaryajax-fetch.js 4:15-39
Module not found: Error: Can't resolve 'buffer' in 'packo/itowns/node_modules/shpjs/lib'
...

ERROR in ./node_modules/shpjs/lib/index.js 12:15-39
Module not found: Error: Can't resolve 'buffer' in 'packo/itowns/node_modules/shpjs/lib'
...

ERROR in ./node_modules/string_decoder/node_modules/safe-buffer/index.js 2:13-30
Module not found: Error: Can't resolve 'buffer' in 'packo/itowns/node_modules/string_decoder/node_modules/safe-buffer'
...

webpack 5.51.0 compiled with 4 errors in 16148 ms

Il semble y avoir des conflits avec la version du paquet webpack, car pour chaque erreur, j'ai quelque chose qui ressemble à ça :

BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.

[amrosu]

Pour corriger ces erreurs et faire remarcher le client itowns, il faut ajouter le paquet buffer dans la partie itowns. Je viens de pousser la branche without_jimp_ro ('ro' = 'rebased on origin') qui contient cette correction en plus du rebase de la branche gmaillet:without_jimp avec le dernier origin/master à jour + suppression des commits pas nécessaires ou devenus obsolètes

[amrosu]

Géré dans PR #370