[Donnees] [Appel à commentaires] GT Grace THD

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