Bonjour Corinne,
Merci pour le partage.
Pourquoi écrivez-vous “Il n’existe à ce jour aucune donnée numérique sur la voirie communale”, alors que la DGCL utilise le thème des transports (routes) de la BD TOPO pour calculer la DSR?
Amicalement
Bonjour Corinne,
Merci pour le partage.
Pourquoi écrivez-vous “Il n’existe à ce jour aucune donnée numérique sur la voirie communale”, alors que la DGCL utilise le thème des transports (routes) de la BD TOPO pour calculer la DSR?
Amicalement
Bonjour à toutes et à tous
Plutôt l’outil mes-adresses ?
L’éditeur des BAL vise à éditer des objets ponctuels et ne dispose pas de capacité d’édition de linéaires.
Les outils dont on parle en disposent tous.
Pourquoi cela serait plus économique et pérenne de faire ce développement ?
Salut François,
Je trouve que l’argument qui consiste à valoriser une interface connue des agents dans les collectivités est assez judicieux.
A+
bonjour,
la bd topo ne distingue la voirie communale (voies communales et chemins ruraux) de la voirie privée
voir page 3 du pdf IGN-visio_compressed dans le message précédent
bien cordialement
bonjour
la BAL sur mes adresses.data.gouv permet la saisie de linéaire.
Avoir l’information de la voirie communale sur cette base peut grandement aider pour numéroter correctement.
Avec de gros problèmes sur les résultats que j’ai pu constater moi même sur une zone rurale que je connais bien et une zone plus urbaine (Joigny).
Cela vient d’un manque de cohérence sur le renseignement de certains attributs et aussi d’une utilisation par la DGCL d’attributs non systématiquement renseignés.
Bonjour
Même si je l’ai découvert via cette conversation, je faisais davantage référence à l’édition complète d’un linéaire y compris l’association d’attributs sur les sommets du chemin (essentiel en gestion de voirie) et de gestion de la connectivité topologique de ces chemins.
Ici on est davantage proche de uMap que de l’édition qui serait nécessaire pour gérer la voirie et ses obstacles ou ses limites/tronçonnement.
Pourquoi pas mais dans le contexte actuel je trouve encore plus judicieux de mutualiser les développements et leur maintenance. Cela n’empêche pas que nous convergeons sur l’usage et ses potentielles passerelles avec d’autres sujets, mais le logiciel lui est non seulement à développer mais aussi à maintenir.
Rien n’empêche de préserver l’interface de mes-adresses en y intégrant iD. L’adaptation pour l’utilisateur est mineure et la résilience pour le projet bénéficie de la maintenance d’un éditeur de géométries open source qui dépasse largement le cas français.
On ne peut pas en vouloir à la DGCL de faire travailler l’IGN pour engager une réforme d’un mode de calcul qui s’appuie sur un référentiels géo national.
Mais personnellement, je regrette que la DGCL se cache derrière l’IGN pour accompagner cette réforme. Dans certaines collectivités (communes, interco, conseil départementaux), certains services de la voirie (ou services techniques) ne savent même pas qu’il y a eu une réforme. Certains diront qu’elle doit avoir peu d’impact sur les dodations…
La transformation d’un référentiel géo millésimé, spécialité de l’IGN, en un référentiel métier, utilisé par des agents au quotidien, n’est pas une paille! Il a fallu 20 ans pour organiser la production des BALs et qu’existe la BAN.
bonjour
je confirme que dans mon département de l’Isère, bon nombre de communes n’ont pas connaissance de la réforme de 2025 et celles qui le savent ne la comprennent pas vraiment. D’autant que la légende de macarte.ign.fr “voirie communale” prend aussi en compte les voies privées.
bonjour,
rajouter la longueur de la voie dans la donnée exportée doit être possible vu que la création d’un numéro sur la voie indique le métré depuis le départ.
Avoir la donnée voirie communale sur la BAL permet aussi de numéroter correctement.
Cet argument peut convaincre les communes d’ y indiquer le linéaire de leur voirie.
Bonjour Bruno
Plutôt 10 : début des discussions en 2014
Il n’était pas question de la longueur de la voie, mais de pouvoir qualifier les sommets de sa géométrie et d’y associer des objets surfaciques.
Par exemple ajouter un accessoire comme les passages protégés sur le linéaire :
La référence fonctionnelle, ça doit plutôt être ça : SIREO
Heureusement, ce dont nous parlons est bien plus simple d’utilisation pour produire une connaissance au moins aussi fine sinon plus dans les cas les plus aboutis.
bonjour,
la réflexion porte sur le statut des voies : “faciliter la conservation des chemins ruraux et le recensement des voies communales” .
Les accessoires de voirie et les équipements liés à cette voirie sont sur un autre niveau d’identification.
Si l’idée est d’avoir une cartographie du statut des voies, il faut un site simple.
Cela n’empêche pas de prévoir le coup et de ne pas mettre de cloisons là où elles ne sont pas nécessaires.
On peut commencer par le statut des voies sans ajouter rien d’autre et puis poursuivre avec plus de détails lorsque ce sera possible / nécessaire.
Mais si on se dit qu’on a besoin d’un éditeur d’habillage aujourd’hui, pour redévelopper un éditeur topologique dans quelques années, je ne suis pas d’accord.
Ce choix a été fait pour la BDTopo il y a ~20 ans et on se demande encore aujourd’hui comment la rendre routable sans que les leçons n’aient été tirées aujourd’hui.
L’éditeur graphique est indirectement en cause, c’est la modélisation non topologique en couches indépendantes qui est plus en question et ce choix est aussi lié à l’usage métier initial c’est à dire produire des cartes (papier).
C’est un cas typique où l’usage métier pose problème sur l’usage en tant que référentiel et que promouvoir des données métier en statut de référentiel ne répond que partiellement aux besoins plus divers que le métier d’origine.
Si je prends le pendant “cadastre”, c’est propre sur la topologie car nécessaire au métier, mais pas sur le géoréférencement, non prioritaire pour le métier, mais qui le devient quand tu veux exploiter des données qui elles sont bien géoréférencées comme les détections sur ortho (oui, les piscines).