Message posté par : Yves Jacolin ---------------------------------------- Bonjour François, Mes retours avec le peu d'expérience que j'ai eu à faire sur ce standard : 1. un modèle complexe pour un réseau complexe, certes, mais trop ambitieux par moment (intègre la fibre, la radio, etc.). Certains organismes n'ont besoin que d'une toute petite partie du modèle. Combien d'organismes ont besoin d'avoir un modèle aussi complexe (interrogation naïve) ? 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 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 4. le modèle tend à être tellement conceptuel qu'il se coupe de la réalité technique (je ne parle pas de la réalité du réseau fibre mais de l'implémentation qui s'ensuit). Bref, pour un format d'échange je trouve le modèle bien éclaté. Enfin, dans le document "PFTHD Recommandations GraceTHD v1.pdf", la justification de la v3 indique : "L’évolution de GraceTHD en version 3 doit permettre l’industrialisation des échanges de données entre les différents acteurs du PFTHD dans le cadre du déploiement et de l’exploitation de la boucle locale optique mutualisée." Pour un format d'échange, se donner cet objectif en version 3 est un objectif bien trop ambitieux :) Y. PS : la critique est facile, mais la tentative d'ouverture pour des retours est une bonne démarche. J'ai bien aimé trouver le mot open source, même si je ne comprends pas trop ce qu'il fait dans ce genre de document : "Cette étude a mené à la mise en place d’un projet open source participatif de création de modèle de données, porté et entièrement financé par l’Avicca." Page 12, document déjà cité. ---------------------------------------- Le message est situé https://georezo.net/forum/viewtopic.php?pid=333630#p333630 Pour y répondre : donnees(a)ml.georezo.net ou reply de votre messagerie Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement -- Association GeoRezo - le portail géomatique https://georezo.net

Message posté par : Bruno IRATCHET (bruno(a)georezo.net) ---------------------------------------- Bonjour, Espérons que le GT du CNIG lit votre échange: https://www.amenagement-numerique.gouv.fr/fr/actualite/nouvelles-recommanda… Bonne journée ---------------------------------------- Le message est situé https://georezo.net/forum/viewtopic.php?pid=333701#p333701 Pour y répondre : donnees(a)ml.georezo.net ou reply de votre messagerie Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement -- Association GeoRezo - le portail géomatique https://georezo.net

Message posté par : Fanfouer ---------------------------------------- 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:Tag:telecom%3Dexchange#Correspondanc… 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 ---------------------------------------- Le message est situé https://georezo.net/forum/viewtopic.php?pid=333700#p333700 Pour y répondre : donnees(a)ml.georezo.net ou reply de votre messagerie Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement -- Association GeoRezo - le portail géomatique https://georezo.net