Le portail francophone de la géomatique

Ma réponse pour le GT est disponible à cette adresse : https://common.infos-reseaux.com/files/ … thdv3.xlsx

Dommage qu'il n'y ait pas d'autres retours sur ce sujet.
La pratique de l'écriture d'un standard est assez chahutée ici.

Bonsoir et merci Yves de poursuivre la conversation

Voici quelques éléments de réponse en fonction de mon expérience (7 ans chez un telco national)
> 1. Combien d'organismes ont besoin d'avoir un modèle aussi complexe (interrogation naïve) ?
Selon moi cela ne dépend pas du besoin d'un seul organisme mais de tout l'éco-système. Même si tu ne travailles que sur une couche, l'ensemble de l'infrastructure doit être décrite de manière cohérente.
Combien d'organismes auraient besoin d'OpenStreetMap tout entier ? L'une de ses forces est pourtant de rendre l'ensemble de son contenu comparable via une modélisation unique.

> 2. Un modèle d'échange complexe à destination d'organisme privée type BTP qui soit ne comprennent pas les enjeux soit, plus souvent, n'ont pas les compétences pour fournir des données sous ce modèle
Vrai, et je reproche justement au modèle d'entretenir ce manque de compétences. Pourtant cela est tout de même plus nuancé que dans les 1ere version. Les choses s'améliorent de ce point de vue

> 3. Un modèle d'échange de données qui tend à vouloir devenir un modèle de stockage, et ce n'est pas la même chose
C'est un point très important et la v3 de Grace restaure l'ambition d'avoir un format d'échange solide. Les deux premières versions étaient vraiment des "SI clé en main" mélangeant encore plus stockage et échange, voué à l'échec car pas assez robuste pour ça.

> 4. le modèle tend à être tellement conceptuel qu'il se coupe de la réalité technique
+1 l'exemple d'implémentation SQL est à revoir, certaines briques conceptuelles aussi pour le coup puisque ni compatible avec le terrain, ni dans les règles de l'art d'une bonne gestion relationnelle.

> 5. Pour un format d'échange, se donner cet objectif en version 3 est un objectif bien trop ambitieux
Le déploiement de la fibre est en cours depuis 15 ans. Les choses vont au contraire trop lentement du point de vue des données. Qu'importe le numéro de version (prévoir des itérations plus courtes au besoin) mais un modèle comme Grace aurait du être industrialisé dès 2010. Pour les plus attentifs, vous remarquerez que les concepts réglementaires sur lequel le standard s'appuie datent de 2012, 2014, 2016... beaucoup de monde est en retard sur ce coup.

> 6. OpenSource
La documentation est sous licence ouverte (CNIG) et les exemples d'implémentation SQL sont également ouverts (il faut que je vérifie la licence). L'avicca a été attentive à cela dès le début, on peut les remercier.

A bientôt

Bonsoir et merci Yves pour la réponse
On est dans le fond du sujet, c'est appréciable de pouvoir en discuter.

Voici quelques réflexions supplémentaires:

J'ai volontairement parlé d'OSM, parce que dans le cadre d'un format d'échange, peu importe l'implémentation, la sémantique joue un rôle beaucoup plus important.
Que la base soit structurée ou en mode document, on doit retrouver les mêmes concepts. L'exemple choisi est en SQL, soit, on pourrait le traduire dans d'autres formats.
La correspondance entre certains objets de Grace V2 et OSM est déjà disponible, le même travail serait fait une fois la V3 finalisée
https://wiki.openstreetmap.org/wiki/FR: … e_GraceTHD

Au sujet des compétences, le modèle proposé tient compte de difficultés et de pratiques peu adaptées pour la production de données relatives au réseau (l'utilisation d'Autocad est mentionnée). La structure du modèle est adaptée, déformée presque, pour se soumettre à ces contraintes. De mon point de vue, le standard laisse du répit au lieu d'accélérer leur disparition.
Tant pis, on payera encore des petites mains pour passer du dwg au geopackage (la mer monte et les journées font 24h, j'ai vraiment pas que ça à faire pour ma part)
Une redondance est même introduite entre les cheminements et les tranchées, premier problème, et sa résorption n'est pas envisagée une fois les données de qualité disponibles, deuxième problème.

Je considérais bien l'implémentation en SQL comme un exemple.
Ce sera certainement l'implémentation la plus courante, si possible sous pgsql, autant partir sur quelque chose qui tire le meilleur parti des performances de ce moteur.
La question des énum n'est pas que le problème de l'exemple d'implémentation. Qu'est-ce qu'un standard sans liste de valeurs, même minimales ?
Le géo-standard ne donne aucune valeur, ni ne standardise la manière de les composer. Les tables l_*** ne sont formalisées que dans l'exemple.
C'est la garantie que tout le monde va faire sa soupe (les recommandations on ne les suit que lorsqu'elles sont dans notre propre intérêt, cet écosystème le démontre avec brio depuis des années).

Le point défendu dans les commentaires est de transformer en énum ce qui se rapporte aux normes. Il n'y a pas lieu de le compléter par autre chose qu'une unique valeur "hors norme".
Si il manque une valeur, c'est la norme qu'il faut faire évoluer, sinon on met des verrues partout et c'est la foire.
Plus de la moitié des concepts sont laissés à la discrétion de l'implémentation, ce n'est pas vraiment "à la marge", ce qui aurait pu se concevoir dans des proportions bien moindres.
Enfin, disposer de classes bien définies n'empêche pas de les étendre en cas de besoin sans mettre en péril le socle commun. Ce n'est pas ce que j'ai lu ici.

Exemple de foutoir possible : les types de chambres, une série de 3 caractères qui détermine les caractéristiques des locaux de tirage et d'accès aux câbles.
La liste n'est donnée que dans l'exemple SQL alors qu'ils sont tous normalisés par l'AFNOR. Deux implémentations vont pouvoir avoir deux listes différentes en apposant le même tampon "Grace THD v3" sur les documents. Ils ne pourront pas se parler. Est-ce ce genre de situations avec lesquelles on veut travailler ?


On est donc bien d'accord sur le retard pris par des outils aussi essentiels que celui-ci

Bonne soirée