search

cnigfr / DDU-SG5-SYMBOLISATION

SG5-SYMBOLISATION
8 stars 6 forks source link

Catalogue de symboles - propositions sur l'attribut SYMBOLE #68

Closed mariondumont closed 2 years ago

mariondumont commented 2 years ago

Dans le cadre de l'expérimentation "Catalogue de symboles", voici les propositions GPU pour le nouvel attribut SYMBOLE :

GT-CNIG-DDU commented 2 years ago

1/ Je propose que le catalogue de symboles soit un registre en ligne. (forme, hébergement, etc. à définir)

2/ ok pour "valeur vide autorisée"

3/ "le code SYMBOLE doit exister dans le catalogue de symboles à la date du téléversement" => ne conviendrait-il pas plutôt de considérer qu'en l'absence du code et/ou du symbole dans le catalogue, alors le symbole par défaut s'applique ?

alhyss commented 2 years ago

Pour le point caractère, je serais également favorable à une solution très souple :

Pour le point contrainte de remplissage, j'hésite. D'un côté on peut se dire que si quelqu'un a fait l'effort de mettre une valeur dans ce champ optionnel, c'est qu'il souhaitait utiliser un symbole particulier. Qu'il soit informé du fait que son symbole n'est pas reconnu semble très utile. De l'autre, je me dis que des collectivités pourraient renseigner dans ce champ des références de symboles qui n'existent pas (ou pas encore) dans le catalogue mais seront reconnues dans leur propre système, et ça ne me semble pas une si mauvaise pratique dans le fond. Leur demander de créer un autre champ pour la même fonction paraît un peu absurde.

J'imagine par contre que, côté GPU, se retrouver avec des clés invalides dans ce champ serait tout sauf idéal... Comme pensez-vous gérer les valeurs vides sur les nouveaux PLU @mariondumont ? Est-ce que vous ajouteriez les codes des symboles par défaut au moment du téléversement, ou est-ce que l'absence de code serait gérée en aval, au moment de la récupération du code avant affichage du symbole correspondant ? Dans le premier cas, cela veut dire que le GPU s'autoriserait à modifier les données pour ce champ, et remplacer un code invalide par un code valide n'est pas pire que mettre un code là où il n'y en avait pas... Dans le second cas, devoir contrôler la validité du symbole à la volée pourrait dégrader un peu les performances ?

GT-CNIG-DDU commented 2 years ago

Au sujet du point "caractère", le standard PLU/CC n'admet que trois types d'attributs :

Je propose : 1/ que l'attribut SYMBOLE soit obligatoire à remplissage facultatif "Valeur vide autorisée" 2/ et qu'une valeur < vide> entraîne la symbolisation par défaut 3a/ et qu'une valeur <hors catalogue de symbole à la date du téléversement> entraîne la symbolisation par défaut 3b/ puis automatiquement la symbolisation requise dès que le catalogue de symbole aura été enrichi et/ou actualisé.

Je rejoins @alhyss sur le fait que dans le cas 3a/ l'autorité compétente soit informée de l'absence de correspondance dans le catalogue . Par contre les références internes à son propre système relèvent nécessairement d'un l'attribut optionnel : LIBATTRn : , LIBVALn : <le code du symbole dans le registre interne de l'agglo>

alhyss commented 2 years ago

@GT-CNIG-DDU Un attribut optionnel à remplissage facultatif aurait surtout eu l'intérêt de ne pas nécessiter de mise en compatibilité des PLU dans les versions antérieures du standard... Mais si ça ne fait que complexifier le standard, ce n'est pas forcément très bénéfique. Idem si les autres modifications du standard nécessitent de toute façon un travail significatif de mise en compatibilité - dans ce cas avoir un champ vide à ajouter dans quelques tables ne représenterait pas grand chose.

GT-CNIG-DDU commented 2 years ago

Nous sommes d'accords. Historiquement les évolutions du standard n'exigent pas de mise en compatibilité des PLU car le GPU admet différentes versions du standard. Concrètement, un PLU publié au standard v2017 restera définitivement publié dans le GPU sans devoir migrer au standard v2022.

alhyss commented 2 years ago

Par contre un PLU modifié est censé être re-publié dans la dernière version du standard, non ? C'est là que la mise en compatibilité peut être lourde, surtout si les vrais changements sont mineurs par comparaison.

GT-CNIG-DDU commented 2 years ago

C'est vivement conseillé en termes d'avantages métier (par exemple la codification v2014 est obsolète) mais ce n'est pas obligatoire. Comme tu l'indiques, en l'occurrence l'ajout d'un attribut obligatoire à remplissage facultatif n'est pas une opération coûteuse, elle est automatisable.

GT-CNIG-DDU commented 2 years ago

En vue d'intégrer l'attribut SYMBOLE dans le standard CNIG PLU/CC, je propose les spécifications suivantes : Qu'en pensez-vous ?

Intégration pour la classe ZONE_URBA :

ATTRIBUT Définition Occurrences Type Contraintes sur l'attribut
SYMBOLE Symbolisation alternative, le cas échéant. Elle fait référence au registre des symboles. ZONE_<typezone>_NNN cf. § Attribut SYMBOLE C20 Valeur vide autorisée

Intégration pour les classes PRESCRIPTION et INFORMATION :

ATTRIBUT Définition Occurrences Type Contraintes sur l'attribut
SYMBOLE Symbolisation alternative, le cas échéant. Elle fait référence au registre des symboles. PSC-<S/L/P>_<typepsc>-<stypepsc> cf. § Attribut SYMBOLE C20 Valeur vide autorisée
SYMBOLE Symbolisation alternative, le cas échéant. Elle fait référence au registre des symboles. INF-<S/L/P>_<typepsc>-<stypepsc> cf. § Attribut SYMBOLE C20 Valeur vide autorisée

§ Attribut SYMBOLE

_(Paragraphe intégré au §4.3 Règles d'organisation et de codification) :_ L'attribut SYMBOLE porte, le cas échéant, une valeur de symbolisation alternative à la symbolisation par défaut. Pour être applicable, cette symbolisation doit avoir été préalablement référencée dans le registre des symboles des documents d'urbanisme. Le format de la valeur à renseigner est fonction de la classe d'objet :

Le suffixe _NNN (ex : _004) correspond au numéro de symbole dans le registre pour la classe et type considérés.

La symbolisation par défaut s'applique :

La valeur conventionnelle 000 permet d'indiquer que l'objet ne doit pas être symbolisé. Quoique non symbolisé l'objet reste cependant "affiché" et interrogeable.

mariondumont commented 2 years ago

Sur le caractère : Il n'y a pas de différence pour nous entre attribut obligatoire/optionnel, nous ne basons nos exigences que sur le remplissage obligatoire/optionnel (ça n'a pas de sens pour nous d'exiger une colonne vide dans les données). Donc ok pour "valeur vide autorisée" car en effet cela ne nous semble pas pertinent d'exiger l'utilisation de SYMBOLE. Dans ce cas, on utilisera la valeur par défaut.

Sur les règles de remplissage : Pas d'accord pour dire que si valeur non connue > on utilise la valeur par défaut, car 1/on pense aussi que c'est dommage de laisser passer des mauvaises valeurs si coquilles 2/s'ils utilisent une valeur pas encore disponible en avance de phase, on ne pourra pas le prendre en compte, car comme le supposait @alhyss, côté GPU nous stockons cette information au moment de la validation (pour faire bref), donc nous ne pourrons pas revenir en arrière et réutiliser la valeur producteur si nous avons enregistré la valeur par défaut. On serait donc plutôt favorable à émettre une alerte bloquante en cas de valeur non connue. Cela veut dire qu'il faudra avoir un cycle "ajout dans le registre > implémentation dans le GPU" le plus court possible, on va travailler là-dessus :)

Sur l'ajout dans le standard : Ok modulo les modifications sur le sujet ci-dessus, et sur la taille max si on modifie les suffixes évidemment

Sur la mise en compatibilité : Oui c'est encouragé de monter de version pour bénéficier des nouveaux attributs etc, mais pas obligatoire car ça peut être bloquant pour la collectivité qui risquerait de ne pas mettre à jour ses données. Et le validateur qui se durcit progressivement pour améliorer la qualité des données, ça rend la montée de version complexe parfois... On pourrait éventuellement ajouter SYMBOLE sur les anciennes versions des standards également, pour permettre à des PLU 2013/2014 d'exploiter cette option également.... mais ne pas le faire est aussi une manière de les encourager à monter de version donc on préfèrerait ne pas le faire.

GT-CNIG-DDU commented 2 years ago

Sur les règles de remplissage : Je suis d'accord sur le principe que le validateur devrait émettre une alerte bloquante en cas de valeur non répertoriée. Mais justement, connaissant vos difficultés (ou impossibilités) à raccourcir le cycle "ajout dans le registre > implémentation dans le validateur GPU", la solution souple que je proposais me paraissait plus sûre, en tout cas beaucoup moins contraignante pour le GPU. Maintenant, me plaçant du point de vue l'autorité compétente, je suis d'accord pour estimer qu'elle doit plutôt être avertie par un blocage du validateur, plutôt que par "c'est quoi ce GPU qui ne me symbolise pas mes données (mal codées) comme je le souhaitais". Principe à moduler éventuellement (collectivement) en fonction de savoir si c'est le symbole NNN, le <type>, ou le <stype> qui n'est pas répertorié. Dans le premier cas (symbole NNN) la symbolisation par défaut peut s'appliquer sans dommage (oui, non ??) dans les deuxième et troisième cas, c'est carton rouge du validateur car le contenu de la valeur de SYMBOLE serait incohérent avec le TYPE et STYPE de l'objet.

mariondumont commented 2 years ago

Je me dis que si la faisabilité d'un nouveau symbole est testée de notre côté pour le valider, on a déjà le code SLD sous la main et il ne reste donc plus grand chose à faire pour le prendre en compte sur le GPU. L'idée est qu'on puisse automatiser la quasi-totalité de la chaine de mise à jour de la symbolisation dans le GPU (on a quasiment toutes les briques) et augmenter la fréquence de mise à jour des symboles si possible (au sens livraison de l'évolution).

Nous ne sommes pas obligés de trancher là-dessus immédiatement (comme ce n'est pas exprimé de manière équivoque dans le standard a priori). Laissons nous le temps de mettre en place le catalogue initial et le circuit de demande pour décider, non ?

alhyss commented 2 years ago

@GT-CNIG-DDU Pour dire qu'il ne faut pas représenter l'objet, n'avions-nous pas parlé d'utiliser la valeur INVISIBLE ? Je trouve le principe des indices 000 contre-intuitif : c'est un seul pseudo-symbole qu'on appelle par plus d'une centaine de noms différents. On va littéralement remplir le registre de non-symboles. Ça complique aussi largement la vie des utilisateurs : plus de chances de se tromper en écrivant les noms vu qu'ils sont beaucoup plus compliqués, plus difficile de faire un filtre sur les symboles invisibles pour vérifier que ce sont bien les bons...

mariondumont commented 2 years ago

Oups, j'avais raté cette phrase => d'accord avec @alhyss Il y a une issue dédiée à ce sujet d'ailleurs #72

GT-CNIG-DDU commented 2 years ago

@alhyss il s'agit d'une valeur conventionnelle, il n'est évidemment pas question de remplir le registre de non-symboles !

alhyss commented 2 years ago

@GT-CNIG-DDU Si la règle est que les valeurs du champ SYMBOLE doivent être des codes de symboles référencés dans le registre, alors tous ces codes 000 ne devraient-ils pas être référencés également ? Ça vaut aussi pour INVISIBLE, mais au moins il est tout seul.

Même si on ne les référençait pas mon principal problème est qu'on complique les choses sans y gagner quoi que ce soit. Mais je passe peut-être à côté de quelque chose.

alhyss commented 2 years ago

Après délibération et, en ce qui concerne la formalisation de l'absence de représentation, vote[^1], le SG5 du 9 juin 2022 valide la proposition de @GT-CNIG-DDU.

[^1]: 3 voix pour l'usage de codes <couche>-<S/L/P>_<typepsc>-<stypepsc>_000, 3 voix pour l'usage d'un code unique INVISIBLE, 1 abstention. Le pilote du GT DDU tranche pour la première option au motif de la cohérence interne des standards.