Le portail francophone de la géomatique

Autre problème constaté : pour la toponymie, il n'y a pas de différenciation entre communes et lieux-dits... Par conséquent, il est impossible de donner une police différente pour ces 2 classes. A moins que ?

A ma connaissance, les noms de communes ne sont pas répertoriés dans cette couche.
Pour afficher les noms de communes, vous pouvez vous baser sur la couche "Commune" tout simplement qui contient le champ "Nom_officiel".

Sur la couche toponymie_Lieux_nommés, les 2 champs "classe de l'objet" et "nature de l'objet" devraient vous suffire pour appliquer un style spécifique à chaque type de toponymes.
N'hésitez pas à lire la documentation "descriptif de contenu" fournie par l'IGN avec la BD TOPO.

Bonnes recherches

Bonjour M. Boulerie,

Je lis avec beaucoup d'attention vos réponses sur ce forum qui sont souvent pertinentes et pointues notamment dans la connaissance des données cadastrales.

Je suis d'accord avec vous, enfin... avec la citation de François Bouillé mais elle n'a rien à voir avec le sujet de base ! Ou alors, je n'ai pas compris votre point de vue puisqu'il se limite à citer ce professeur.
Je suis le 1er à défendre l'idée que si les applications (et les ordinateurs) ne simplifient pas la vie des gens, il vaut mieux le faire à l'ancienne.

En l'occurrence, en bases de données, sous prétexte que l'un aimerait avoir des majuscules et l'autre des minuscules ou toutes autres mises en formes possibles, je maintiens mes propos : il serait absurde de stocker plusieurs fois un même champ pour de multiples raisons et principalement pour la maintenance et pour limiter l'espace de stockage... Pensons un minimum à la planète.

L'homme peut aussi être intelligent et tout simplement retravailler et manipuler la donnée pour atteindre son objectif surtout que pour le coup, je donne la solution à benjamin_68.
Alors, même si nous sommes à l'ère de l'Intelligence Artificielle, nous ne sommes pas exempts de réfléchir... Et espérons que l'homme contrôlera toujours les ordinateurs, et non l'inverse...

et dans l'autre discussion :

Bonjour à toutes et tous,

Je confirme ce constat et m'en étonne depuis près de 20 ans.

Suggestion : L'IGN pourrait/devrait faire évoluer le format de la BD TOPO, et ajouter un champ "Libellé affichable conforme aux normes d'orthographe et d'orthotypographie de la langue française de France" (pour faire court).

Ainsi, le travail de "bidouille" serait réalisé une fois et une seule à la source, de manière professionnelle et conforme aux normes en vigueur par des professionnels et experts de l'IGN, et ce libellé d'affichage "correct et conforme" serait partagé par la Terre entière, sans que plus personne n'ait à brûler du jus de cervelle ni consommer de l'électricité d'origine fossile ou nucléaire pour mal faire ses propres conversions.

On peut recycler un vieil acronyme pour désigner le concept : WORM - Write once read many

Une façon parmi d'autres de mettre en actes la sobriété énergétique et contribuer au GreenIT... et faire jouer pleinement à l'IGN son rôle de référence absolue.

Je suis très intéressé par la suite du débat...

Bon mois d'août,
David

PS :

Il s'agit là malheureusement d'une norme d'orthotypographie états-unienne, qui pollue les logiciels (et les têtes) francophones depuis des années.
Je me suis longtemps battu contre "Google Contacts" qui nous l'impose à chaque saisie d'adresse géographique, mais j'ai fini par renoncer. J'ai autre chose à faire de mon temps que de me battre contre des IA stupides...
Mais si Thierry Breton ou la Commission européenne voulait s'emparer du sujet, ça me ferait plaisir ;-)

Bonjour,

Une première remarque, parler de base de données en lieu et place de formats d'échanges me chagrine toujours un peu.
Certes c'est un jeu de données mais pour moi j'associe à base de données un système de gestion. Je sais c'est discutable.
La BD-Topo est pour moi un (des) jeux de données dans un format d'échange X.

Et c'est au moment de l'intégration dans un SGB que le contenu des fichiers de données est formaté selon les choix du gestionnaire du système.

Ensuite en tant que développeur et codeur depuis de nombreuses années, je trouve souvent le point de vue "géomatique" très centré sur les besoins,
envies de l'utilisateur métier et éloigné, souvent par ignorance, des notions et contraintes "informatiques" partagées mondialement par les développeurs.

Je suis en accord avec AI3+ sur les points évoqués en matière de redondance et de coût.

Le contenu d'une données est conditionné par son codage, qui lui même dépend de deux choses :
L'encodage (UTF8 et consorts)
Le séparateur décimal et le système de date heure.

Ces deux points sont des casse tête récurrents pour les codeurs du monde entier.

Donc le

c'est du WIN1252 pour les uns ou de l'ISO 8859 pour certains autres et j'arrête là la liste des encoding utilisables.

Demander des modifications à l'IGN pour pouvoir afficher telle ou telle donnée en fonction de ses envies est inopportun, pourquoi vous ne demandez pas à Microsoft et Excel de générer des fichiers conformes à vos attentes ? Qui n'a pas perdu du temps pour retravailler les csv en Open Data ???
Chaque producteur de données y va de la sienne ... et qui séparateur "," pour les nombres réels, qui win1252 et qui LATIN1 pour les champs texte ...

Commençons par éviter les majuscules dans les noms de champs, les ' et autres " dans les contenus des champs ce serait déjà un réel progrès.

Donc parler d'universalité (et de WORM) c'est souvent une vision très française hexagonale.

La phase d'intégration de données issues de fichiers d'échange dans un Système de Base de Données sera toujours présente et c'est le lieu du formatage, du contrôle et pour les systèmes relationnels de celui de l'intégrité. Ce, pour se conformer au MCD choisi par le concepteur de la BD en accord avec ses utilisateurs.

Dernière modification par ChristopheV (Thu 29 August 2024 10:37)