Bug au niveau du nom de la table dans postgres

[IGNF-Xavier]

Qgis peut enregistrer les tables dans un geopackage avec espace et separateur double barre — .
La table est bien enregistré dans postgres.
Cf. entrepot/122b878c-aad8-4507-87b2-465e664467d3/donnees/355-test

Le workflow de génération d'un WFS indique une erreur sur ce nom et demande à corriger :

Le workflow de génération d'un TMS n'indique rien et lance la génération mais j'arrive sur un échec de ALAMO

Par contre, en modifiant le nom de la couche departement et en supprimant " — collectivite_territoriale", la génération du TMS fonctionne.

Le workflow de génération d'un WMS arrive sur une erreur 500.
Par contre, en modifiant le nom de la couche departement et en supprimant " — collectivite_territoriale", la génération du WMS fonctionne.

SUGGESTION :
Côté Front : Au moment du téléversement (donc avant d'effectuer la livraison), détecter le nom des tables et indiquer si le nom ne respecte pas une REGEX (qui doit être confirmée).

OU plutôt
Côté API Entrepôt : supprimer au moment de la livraison les caractères interdits ne permettant pas la génération des flux @Dolite

CONTOURNEMENT :
Indiquer en attendant dans la configuration en tant qu'astuce.

[slafayIGN]

Ce sont 2 traitement entrepôt qui sont en cause :

1. soit le traitement d'intégration des données en base qui devrait transformer departement — collectivite_territoriale en quelque-chose qui ne contient que des caractères autorisés. Mais ce qui est autorisé est toujours discutable car dans postgres tout peut être autorisé. Il n'y a pas vraiment de bug ici.
2. soit le traitement de génération de pyramide vecteur qui doit être modifié pour mettre systématiquement entre double quote les noms de tables car on ne sait pas ce qu'il peut y avoir comme caractères dans ces noms. (il me semble que ça se passe plutôt ici : https://github.com/rok4/core-perl/blob/develop/lib/ROK4/Core/Database.pm#L1041). Là ça ressemble à un vrai bug.

La modification 1., bien qu'elle ne soit pas une correction de bug, aurait l'avantage d'éviter en cascade :

• à l'utilisateur de devoir choisir un nom de table différent pour le service WFS (on pourrait quand-même adapter le front puisqu'on prérempli le champ pour l'utilisateur : on pourrait préremplir avec une valeur acceptable)
• aux traitements suivants de planter, il n'y a peut-être pas que la génération de pyramide qui pourrait être perturbée par des nommages exotiques.

Qu'est-ce que tu en penses @Dolite ? Les 2 modifications sont légitimes ou seulement l'une des 2 ?

En tout cas il me paraitrait douteux de faire des vérifications côté front puisque d'autres moyens d'alimentation sont possibles.