search

cnigfr / DDU-SG5-SYMBOLISATION

SG5-SYMBOLISATION
7 stars 6 forks source link

Catalogue de symboles – nommage des symboles - Gestion des données existantes #73

Closed mariondumont closed 2 years ago

mariondumont commented 2 years ago

Lors de l’initialisation du catalogue de symboles dans le GPU, l’ensemble des données existantes dans la base se verront attribuer un code symbole généré en fonction des règles de symbo actuelles (transparent pour l’utilisateur donc). Ce processus étant relativement impactant, il faut que ces nommages (ceux par défaut au moins) soient suffisamment stables pour que ces modifications soient pérennes. Pour traiter le cas des anciennes données du GPU, pour lesquelles les informations disponibles ne suffisent pas toujours pour déterminer à quel code symbole les rattacher (ex. typeinf/stypeinf pas dispos), des symboles par défaut seront également proposés pour chaque couche, exemple INF-S_DEF_001.

alhyss commented 2 years ago

Est-ce que l'incrément a une utilité dans ce cas ? À première vue ce symbole par défaut devrait être unique, sauf à ce que tu vois plusieurs cas d'impossibilité d'identification du code à distinguer @mariondumont ? Si ce n'est pas le cas, des noms de la forme INF-S_DEF ou INF-S_DEFAUT me plairaient davantage.

Une question sur le processus. Est-ce que le fonctionnement est celui-ci ?

  1. Code et d'un sous-code valides : attribution du symbole par défaut pour le code et sous-code.
  2. Code valide, sous-code invalide : attribution du symbole par défaut pour le code. Ce pourrait être celui du sous-code 00, sauf quand il n'y a pas de sous-code 00, auquel cas on basculerait peut-être dans le cas 3...
  3. Code invalide : attribution du symbole par défaut global pour la table et le type de géométrie évoqué dans cette issue.

Ou celui-là ?

  1. Code et d'un sous-code valides : attribution du symbole par défaut pour le code et sous-code.
  2. Code et/ou sous-code invalides : attribution du symbole par défaut global pour la table et le type de géométrie évoqué dans cette issue.
mariondumont commented 2 years ago

Avis IGN :

  1. si "code/sous-code" connu dans le registre, alors on utilise le symbole dédié
  2. sinon, si "code/n'importe quel ss-code" connu dans le registre, alors on utilise le symbole dédié au code
  3. sinon, si code inconnu dans le registre en gros, on utilise le symbole par défaut de la couche

A moins d'avoir des applications futures qui nécessitent une convention de nommage très régulière, je serais donc aussi plutôt d'avis d'utiliser <couche>-<P/L/S>_DEFAUT pour clarifier les choses.

alhyss commented 2 years ago

@mariondumont Tu as raison, un code ou code/sous-code inconnu du registre ou inconnu du standard ce n'est pas la même chose... Et il faudra bien nous assurer que nous ne nous trouverons jamais dans une situation où nous n'aurons pas (encore) dans le registre de symbole défini pour un code du standard reconnu par le GPU, puisque celui-ci irait alors remplir le champ SYMBOLE avec des <couche>-<P/L/S>_DEFAUT qu'il sera difficile de remplacer a posteriori (si j'ai bien compris ta réponse à l'issue #68)

Ça me fait penser au cas des codes obsolètes. Je ne les avais pas pris en compte lorsque j'ai réécrit les spécifications de symbolisation, mais il faudrait qu'ils apparaissent dans le registre, non ? Vous devez avoir des SLD pour eux côté GPU, j'imagine ?

mariondumont commented 2 years ago

Oui peut-être, sauf si aucun symbole n'était défini pour eux... Tu as la liste des SLD qu'on distingue en pj symbols.zip !

mariondumont commented 2 years ago

il faudra bien nous assurer que nous ne nous trouverons jamais dans une situation où nous n'aurons pas (encore) dans le registre de symbole défini pour un code du standard NON (?) reconnu par le GPU, puisque celui-ci irait alors remplir le champ SYMBOLE avec des -<P/L/S>_DEFAUT qu'il sera difficile de remplacer a posteriori

Si e registre est cohérent avec le standard mais que le GPU est en retard, tout le lot de données sera bloqué par le validateur et on en arriverait pas à l'étape de remplacement par DEFAUT a priori... donc pas pbq pour moi.

Il faudrait surtout que le registre reste cohérent avec le standard, et qu'on puisse avoir un buffer de symboles "en cours de validation" et un "validé mais en attente de publication du std" indépendants du registre publié.

alhyss commented 2 years ago

Il n'y avait vraiment pas de "non". Désolée si c'était obscur, je pensais au cas où le registre aurait du retard sur le standard et le GPU (que j'espère très improbable), et ça rejoint donc ton deuxième paragraphe. Oui, il faut que le registre reste cohérent avec le standard !

mariondumont commented 2 years ago

Ah oui aussi... oui dans ce cas ils seraient coincés avec du DEFAUT c'est sur.

alhyss commented 2 years ago

Le SG5 du 9 juin 2022 acte que le registre de symboles maintenu par le CNIG ne définira de symboles par défaut qu'au niveau des sous-codes, le GPU restant libre de prévoir des symboles par défaut valables pour un code ou une couche selon ses besoins internes. En effet, le standard n'autorisant pas à date l'usage de sous-codes ou codes autres que ceux qu'il prévoit, ni l'absence de valeur, il ne paraît pas opportun qu'il définisse les symboles à utiliser lorsque ces règles sont enfreintes.

Pour transposer la nouvelle gestion des symboles aux données existantes relevant de versions antérieures du standard, le GPU pourra utiliser le symbole par défaut du sous-code 00 - <PSC/INF>-<S/L/P>_<code>-00_001 - lorsque le sous-code de l'enregistrement est absent ou non reconnu (sous réserve que le sous-code 00 existe pour le code considéré).

Il n'est pas prévu pour l'heure de symboles <PSC/INF>-<S/L/P>_00-00_001 utilisables lorsque le code est absent ou non reconnu. Il reviendrait au GPU de gérer en interne de tels symboles.