Refactor projection

[nlenglet-ign]

Ajout des projections nécessaires à l'utilisation en production

Mise à jour des paramètres par défaut dans overviews comme demandé :

• taille tuile : 512x512 px au lieu de 256x256
• taille dalle : 8x8 tuiles au lieu de 16x16

Mise à jour swagger en correspondance

Mise à jour de la doc et des tests

[coveralls]

Pull Request Test Coverage Report for Build 5750605020

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 22 of 22 (100.0%) changed or added relevant lines in 2 files are covered.
• 25 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.4%) to 95.598%

---

Files with Coverage Reduction	New Missed Lines	%
middlewares/wmts.js	2	91.82%
gdal_processing.js	23	81.99%

Totals
Change from base Build 5398217406:	-0.4%
Covered Lines:	5914
Relevant Lines:	6141

---

💛 - Coveralls

[amrosu]

Il manque la mise mise à jour de l'aide pour create_cache, notamment la valeur par défaut pour le param "overviews" qui fait référence à LAMB93_5cm.json qui n'existe plus.
Il faut aussi aussi à jour la doc README

[amrosu]

Il faudrait s'assurer de la rétrocompatibilité LAMB93 <-> RGF93_LA93, notamment pour permettre de continuer à travailler sur des caches créés avant le changement et qui contiennent donc la "vielle" nomenclature LAMB93.

Dans la base de données, comme on enregistre le crs avec code EPSG, ça devrait être bon, pas d'impact suite au changement de nomenclature pour LA93

[nlenglet-ign]

Tests réalisées pour la rétrocompatibilité LAMB93 <-> RGF93_LA93 :

• itowns OK (vérifier avec plus de logs)
• export vue QGis OK (test saisie à faire)
• soucis côté doc API lors de requêtes WMTS de type GetTile / GetFeatureInfo

[amrosu]

Le problème ave GetTile/GetFeatureInfo dans la doc vient de TILEMATRIXSET qui est sur la forme d'une liste contenant les nouveaux identifiants de la pyramide (et donc pas compatible avec les vieux cache contenant les vieux identifiants). Pour corriger cela, je propose de passer à un champ libre - commit 4d92df7.
J'ai également corrigé une petite coquille dans l'exemple POST/ cache - commit 9c93ff4

[nlenglet-ign]

Les saisies sont OK sous QGis.
Le comportement attendu dans swagger est le bon également.

[amrosu]

J'ai remplacé les LAMB93->RGF93_LA93 restants dans la doc et les fichiers des tests regress, plus rebase de la branche

[amrosu]

Avec le changement de la taille de la tuile (512x512 px au lieu de 256x256 px), on retrouve le problème d'incohérence dans l'affichage des niveaux de zoom avec le client itowns décrit dans le ticket #358 :

[...]
Problème du client itowns : il semble y avoir un décalage entre le 'level' (et donc le 'levelCOG') demandé et celui affiché si la tuile est différente de 256. Le décalage est de 1 niveau (level) si taille tuile = 512 et de 2 niveaux si tuile=1024.

Actuellement, dans le client itowns, le niveau maximal d'affichage du graphe/contour et de saisie est lié à la taille de la dalle (ex: Dezoom 1/16 pour dalles de 16x16, 1/8 pour 8x8 et 1/4 pour 4x4). L'affichage actuel dans itowns du graphe/contour est 'décalé' pour des caches avec des tuiles différentes de 256x256, voir plus haut, avec des incohérences avec le message 'Graph not displayed', message qui n'est pas dépendant de 'level'.
[...]

Dans ce même ticket on avait conclu de ne pas corriger ce problème dans le client itowns, car :

Actuellement, dans client itowns, pas de correction sur 'level', ni d'évolution sur le niveau max d'affichage de graphe/contour et de saisie ne sont demandées par l'utilisateur principal (voir PR #351) :

[...] ces corrections liées à iTowns peuvent être mises en attente parce que:
* il n'est pas acté que l'on utilisera effectivement des caches avec des tuiles d'une autre dimension que 256
* on a décidé de ne plus faire d'évolutions lourdes sur la partie iTowns pour l'instant

[amrosu]

Et pour info, le repère géodésique pour Mayotte changera bientôt selon le service de géodésie de l'IGN : RGM23 remplacera RGM04. Pour le moment, RGM23 n'est pas officielle, donc pas de code EPSG, ni de définition d'emprise ... D'ici-là, on gardera RGM04 pour Mayotte

[gmaillet]

Validé, à merger