Catalogue de symboles – nommage des symboles - Formalisme

[mariondumont]

Après un premier échange avec le SG5, voici le formalisme que nous vous proposons d'utiliser pour le nommage des symboles :

• un préfixe indiquant le nom de la couche, avec sa primitive géométrique (PCT/LIN/SURF) le cas échéant, séparés par un tiret
• une partie centrale décrivant de manière relativement explicite les « objets généraux » concernés par ce symbole, elle-même pouvant être composée de plusieurs parties séparées par un tiret
• un suffixe incrémental sur 3 chiffres permettant d’avoir plusieurs symboles différents pour un même « objet général », exemple pour les prescriptions XX-YY, en plus du symbole 001, on souhaite distinguer trois sous-catégories thématiques, basées sur d’autres attributs ou d’autres notions métier par exemple, on crée alors trois autre symboles avec les suffixes 002, 003 et 004
• ces trois parties étant séparées par un underscore Ce qui donnerait :

•   Pour les informations : INF-<P/L/S>_<typeinf>-<stypeinf>_NNN (exemple INF-S_17-00_001)
•   Pour les prescriptions : PSC-<P/L/S>_<typepsc>-<stypepsc>_NNN (exemple PSC-S_39-02_001)
•   Pour les zonages : ZONE_<typezone>_NNN (exemple ZONE_AUs_001)
•   Pour les secteurs : SECT_<typesect>_NNN (exemple SECT_01_001)
•   Pour les assiettes de SUP : ASS-<P/L/S>_<categorie>{-<typeass>}_NNN (exemple ASS-S_ACI-MH_001)

[GT-CNIG-DDU]

Marion, pourrais-tu plutôt faire 4 issues ?

[mariondumont]

Marion, pourrais-tu plutôt faire 4 issues ?

fait ! 3 nouvelles issues créées : #72 #73 #74

[GT-CNIG-DDU]

👍

[alhyss]

Nous avions parlé de nous laisser la liberté d'utiliser des suffixes porteurs de sens à la place de l'incrément lorsque c'est plus pertinent, voire peut-être même de préférer des suffixes porteurs de sens, qui aideront les personnes qui remplissent le champ SYMBOLE à confirmer visuellement que les codes associés à leurs objets sont les bons.

Pour ma part, j'aime bien cette idée. Il me semble que nous pouvons nous autoriser un peu de souplesse pour l'avenir, tant que les noms des symboles par défaut sont bien calés et que nous avons fixé la longueur maximum autorisée.

Ce serait d'autant plus cohérent si - et je crois que @mariondumont était de cet avis - nous fléchons l'usage des symboles sur des cas déterminés pour conserver une certaine homogénéité nationale, plutôt que de juste laisser les utilisateurs piocher le symbole qui leur chantent parmi ceux qui sont disponibles pour le sous-code.

Pour la règle générale, ça donnerait :

• informations : INF-<P/L/S>_<typeinf>-<stypeinf>_<suffixe>
• prescriptions : PSC-<P/L/S>_<typepsc>-<stypepsc>_<suffixe>
• zonages : ZONE_<typezone>_<suffixe>
• secteurs : SECT_<typesect>_<suffixe>
• assiettes de SUP : ASS-<P/L/S>_<categorie>{-<typeass>}_<suffixe>

<suffixe> est une chaîne de caractères, évidemment unique pour le sous-code considéré, et qui donne autant que possible une indication de l'usage préconisé pour le symbole. À défaut de pouvoir créer un suffixe porteur de sens, des incréments sur trois chiffres sont utilisés.

Pour les symboles par défaut, on pourrait se servir du suffixe DEF, par symétrie avec ce qui est proposé dans l'issue #73 . Par exemple dans le cas des prescriptions :

• symbole par défaut pour un code/sous-code : PSC-<P/L/S>_<typepsc>-<stypepsc>_DEF
• symbole par défaut pour un code (pas de sous-code valide, s'il y a lieu) : PSC-<P/L/S>_<typepsc>_DEF
• symbole par défaut pour le type de géométrie (pas de code valide) : PSC-<P/L/S>_DEF

Je me demande d'ailleurs comment gérer le cas des sous-codes qui n'ont pas aujourd'hui de symbole spécifique. Est-ce que nous leur créons tout de même un symbole par défaut de sous-code PSC-<P/L/S>_<typepsc>-<stypepsc>_DEF en dupliquant le symbole commun, ou affectons-nous à tous les objets concernés le symbole par défaut du code (hypothétiquement PSC-<P/L/S>_<typepsc>_DEF) ? D'un côté la duplication va nous ennuyer un peu si nous avons besoin de modifier le symbole - il va falloir répliquer le changement à plusieurs endroits dans le catalogue -, de l'autre elle pourrait faciliter grandement les choses côté GPU si un symbole est un jour défini pour le sous-code en question. Si les valeurs vides du champ SYMBOLE sont remplacées en dur dans la base par les codes des symboles par défaut (est-ce le cas ?), alors il serait nécessaire de faire de la reprise de l'existant pour aller remplacer PSC-<P/L/S>_<typepsc>_DEF par le nouveau PSC-<P/L/S>_<typepsc>-<stypepsc>_DEF pour tous les objets du sous-code considéré...

[GT-CNIG-DDU]

L'idée est tentante, mais mieux vaut rester sur l'incrément pour faire simple et uniforme. Le champ "Intitulé de légende" que nous avons prévu dans le catalogue remplit justement le rôle d'indiquer l'usage du symbole.

Sur la deuxième question, je privilégierais l'équivalence entre le registre des codes-sous-code et le catalogue des symboles en créant un symbole par défaut pour chaque sous-code : PSC-<P/L/S>_<typepsc>-<stypepsc>_001, ce qui a le mérite d'être à la fois simple à créer et à maintenir.

[alhyss]

Ah, je consteste le fait qu'un incrément soit univoque. Ce n'est pas tant qu'il y ait ambiguïté sur l'interprétation, ce n'est carrément pas interprétable du tout. Un suffixe textuel ne remplacera évidemment pas la définition donnée par le catalogue, mais il donne au moins une indication.

Et je ne suis pas sûre non plus que ce soit particulièrement simple. Avoir besoin de se référer au catalogue pour savoir de quel symbole on parle est une source de complexité notable à mon sens, tant pour ceux qui gèrent les symboles (nous) que pour ceux qui les utilisent. Les seuls avantages que je vois aux incréments sont qu'il n'y a pas besoin de réfléchir aux noms et qu'il est plus facile de contrôler la validité formelle des valeurs renseignées dans le champ SYMBOLE. Mais pour nous le critère de validité sera l'existence dans le catalogue et pas le respect d'une expression régulière de toute façon...

[mariondumont]

Avis IGN :

• sur le fond, on est plutôt d'accord avec @alhyss de dire que des suffixes textuels seraient plus équivoques pour les utilisateurs
• sur la forme, on tient beaucoup à l'homogénéité de l'ensemble, et à la simplicité d'utilisation et de mise à jour de l'outil, sous-entendu ne pas avoir à mettre à jour les données du GPU. Pour le dire plus clairement, pour l'instant la position du projet GPU c'est : on se permet d'initialiser les valeurs de SYMBOLE dans la base de données car cet attribut n'existe pas encore, mais dès que l'évolution sera déployée, nous ne toucherons plus à cette donnée et il faudra que le producteur republie son document pour mettre à jour les valeurs SYMBOLE.
• donc en conclusion, si vous pensez que l'on peut construire un registre avec des suffixes textuels homogènes (ex. 6 caractères en majuscules pour tous les suffixes), on est pas contre passer à du texte; et dans ce cas on pourra repasser sur du DEFAUT pour les symboles de base, sinon on resterait sur du 001 (ou 000 éventuellement si ça vous semble + clair)

Je me demande d'ailleurs comment gérer le cas des sous-codes qui n'ont pas aujourd'hui de symbole spécifique.

Pour l'instant, la convention de nommage n'a pas été tout à fait respectée en fait, et les symboles concernés ne contiennent pas le sous-code (ex. PSC-S_15_001 pour les autres sous-codes que 50 et 51). L'option de ne pas dupliquer les symboles pour les sous-codes qui n'existent pas encore nous semble favorable. En revanche, à la réflexion, il faudrait certainement mettre qqch comme PSC-S_15_OTH_001 pour signaler qu'il s'applique à "tous les autres" que ceux spécifiquement définis... Qu'en pensez-vous ?

[GT-CNIG-DDU]

Je viens d'éditer mon commentaire ci dessus pour le rendre cohérent avec le #68 (rédigé postérieurement) : avant : "... en créant un symbole par défaut pour chaque sous-code : PSC-<P/L/S>_<typepsc>-<stypepsc>_000, ce qui..." maintenant : "... en créant un symbole par défaut pour chaque sous-code : PSC-<P/L/S>_<typepsc>-<stypepsc>_001, ce qui..."

[GT-CNIG-DDU]

Marion je reviens sur : "L'option de ne pas dupliquer les symboles pour les sous-codes qui n'existent pas encore nous semble favorable." Peux-tu justifier ce choix, car je ne vois pas trop où est le problème en fait... De mon point de vue, disposer d'un catalogue version initiale en relation bijective avec les listes PrescriptionUrbaType et InformationUrbaType est le procédé vraiment le plus simple et performant car il permet :

• de disposer immédiatement de l'ensemble des symboles avec possibilité de les implémenter (pour un sous-code par exemple) aussitôt le symbole validé par le CNIG SG5.
• de respecter la convention de nommage dès le départ ;-)
• de s'éviter des procédés de type PSC-S_15_OTH_001 qui sont temporaires et pas très lisibles pour les utilisateurs, et le seront encore moins à l'apparition des PSC-S_15_01_001, PSC-S_15_02_001, etc.

[mariondumont]

Je plussoyais le commentaire sur le fait que si un symbole partagé devait être mis à jour, cela serait plus couteux s'il était répété plusieurs fois dans le registre. Et il y a aussi le fait que d'un point de vue implémentation, on est plus proche de cette situation actuellement que de la cible 1 symbole/sous-code (de notre côté en tout cas), puisque l'on a construit le catalogue à partir des SLD existants. En prenant un peu de recul, je me dis aussi que l'on risque de continuer à s'appuyer côté GPU sur cette symbolisation pour dériver la légende, et qu'il n'est pas pertinent de faire une légende exhaustive si les symboles ne sont pas différenciés par sous-code...

Mais je suis bien d'accord avec toi sur tous les avantages de passer directement à un catalogue "exhaustif" avec des symboles répétés... A voir si on a de quoi le remplir initialement ou si ça doit être notre cible idéale à terme plutôt !

[alhyss]

donc en conclusion, si vous pensez que l'on peut construire un registre avec des suffixes textuels homogènes (ex. 6 caractères en majuscules pour tous les suffixes), on est pas contre passer à du texte; et dans ce cas on pourra repasser sur du DEFAUT pour les symboles de base, sinon on resterait sur du 001 (ou 000 éventuellement si ça vous semble + clair)

Par curiosité @mariondumont, qu'est-ce qui rend utile de figer la longueur du suffixe ? J'imaginais qu'avoir une longueur max pourrait suffire.

Pour l'éventuel symbole qui s'appliquerait à tous les sous-codes qui n'ont pas de symbole spécifique, je voterais pour PSC-<P/L/S>_<typepsc>_DEF ou PSC-<P/L/S>_<typepsc>_DEFAUT (même suffixe que pour le cas #73). Je ne vois pas l'intérêt d'un incrément s'il n'y en a qu'un. Sauf à ce qu'on imagine proposer plusieurs symboles... Mais ce serait assez bizarre : on aurait alors dans le registre une catégorisation concurrente de celles des sous-codes...

Ça rejoint ce que tu dis, @mariondumont :

En prenant un peu de recul, je me dis aussi que l'on risque de continuer à s'appuyer côté GPU sur cette symbolisation pour dériver la légende, et qu'il n'est pas pertinent de faire une légende exhaustive si les symboles ne sont pas différenciés par sous-code...

Sinon, je pense qu'il vaudrait mieux AUT que OTH, comme les identifiants du standard sont tous en français.

[mariondumont]

Par curiosité @mariondumont, qu'est-ce qui rend utile de figer la longueur du suffixe ? J'imaginais qu'avoir une longueur max pourrait suffire.

J'ai pas d'argument là, juste une maniaquerie surement :') Oui seule la longueur max compte je pense aussi.

Sinon, je pense qu'il vaudrait mieux AUT que OTH, comme les identifiants du standard sont tous en français.

Tu as raison oui, mais ça me semble un tout petit peu moins équivoque. Il y aura ptet qqch de plus clair pour dire "tous les autres codes" en français ? :/

[alhyss]

Bien d'accord que l'anglais est plus pratique pour ce genre de chose... Éventuellement DIV, qui a l'avantage d'être un classique même si ce n'est pas exactement la même notion ? Pas d'idée pour ma part hormis ma préférence plus générale pour l'approche DEF/DEFAUT, comme vous l'aurez compris...

[alhyss]

Le SG5 du 9 juin 2022 valide les règles de nommages décrites dans l'issue #68. Il est également acté que le CNIG ne définira pas de règle concernant le nommage de symboles par défaut applicables à un code ou une couche (seulement au niveau du sous-code, avec le suffixe 001), dans la mesure où leur usage est spécifique au GPU (cf. issue #73).