Résultats de la recherche

Rechercher dans les contenus ayant un titre ou un résumé disponibles dans les langues sélectionnées

Résultats de la recherche

  1. Message de forum Quelques actualités (en vrac et sans attendre le prochain point du 25 juin)

    les langues régionales (enfin) disponibles à l'échelle départementale c'est ici. L'initialisation des identifiants à démarré ( communication plus globale sur le sujet vers mi-juin) avec Adresses avec Ban ID : 1 923 589 ; Communes utilisant les Ban ID : 1 422 Et pour le déploiement des BAL 20367 communes ce matin (on approche des 60%) C'est confirmé : les principaux acteurs du GPS (Google Maps, Waze, Apple Maps, Here et TomTom) utilisent la BAN avec une fréqence à minima mensuelle. Mais tous ne sont pas au mêmes niveau d'exploitation (certains ont encore des trous dans la raquette)
  2. Idée principe de stabilité de l'identifiant

    Bonjour, En préparation de l'atelier sur l'identifiant de ce lundi 18/12 après-midi, je vous soumets l'énoncé d'un principe qui va servir de point de départ lors de notre atelier. Donc si vous avez une autre formulation, n'hésitez pas à la partager : Principe de stabilité de l’identifiant : "Si le lieu/endroit à adresser n’a pas été modifié, l’identifiant ne change pas, il reste stable." Dont un corolaire est que "sans changement du lieu/endroit à adresser, les modifications d’une composante de son adresse n'entraînent pas de changement d’identifiant ladite adresse. " En lien avec ce principe, voici quelques règles/exigences issues du document "Cadre Commun d'Architecture des Référentiel de données v1.0_0" règle RF4 page 28 * : "Règle SF4 : Séparer les données d’identités (ou d’identification métier), des identifiants des données de référence... identifiant ... aisément partageable, non ambigus, non signifiant ..., non modifiables, non-réaffectable, non supprimable et persistant. La notion d’identifiant, donnée permettant d’identifier avec certitude un objet métier (une personne par exemple, ou une entreprise), doit très clairement être dissociée des données d’identités de l’objet métier.... La mise en place d’identifiant, ou de clé, permettant de retrouver avec certitude un objet métier, doit répondre à des exigences précises : cet identifiant doit être facilement partageable (dans un format interopérable) ; il doit être non ambigu ; il doit être non signifiant, c’est-à-dire ne contenant pas de données métiers ou techniques susceptible d’évoluer dans le temps, ne contenant pas de données à caractères personnels ou confidentielles ; il doit être non modifiable : une fois défini et attribué, il ne doit plus changer ; il ne doit pas être réaffecté à un autre objet métier, même si le précédent objet n’a plus lieu d’être (quelle qu’en soit la raison) ; Il ne doit pas être supprimable, même si l’objet n’a plus lieux d’être. (ex. L’identifiant d’une entreprise qui fait faillite, ne doit pas être supprimé, il est conservé jusqu’à la date légale de conservation, et même probablement au-delà dans cet exemple). Il doit être persistant : c’est-à-dire qu’il doit être réellement stocké, conservé et archivé dans le temps." * Pour ceux qui le souhaitent, j'ai mis ce document dans la rubrique documents / 1.1 - Chantier Identifiant unique / autres ressources (merci Loic de m'avoir réorienté vers ce -vieux- document que je ne connaissais pas:)).
  3. Idée Donner des identifiants uniques aux positions

    Le travail en cours porte sur un identifiant unique des adresses BAN. C'est un bon premier pas mais je pense qu'il est nécessaire d'aller plus loin : donner des IDS aussi sur les différentes positions. Le manque d’ID sur les différentes positions pose problème : il n’y a aucune unicité sur le type de position (il peut y avoir plusieurs entrées) donc aucun moyen de différencier 2 positions de manière sûre d’autres outils liés à la BAN (par exemple BAN PLUS mais cela pourrait être des outils tierces), utilisent ces différentes positions et n’ont aucun moyen d’identifier une position. Pour ne citer que mon problème actuel : 2 formats sont mis à disposition sur la BAN : BAL et CSV (je laisse le format addok de côté). Quand on regarde le fichier BAL, nous n’avons pas de moyen simple de remonter au point unique remonté dans le fichier CSV. Ces éléments qui peuvent sembler mineur sont assez importants pour faciliter l’intégration de la BAN dans les outils tierces.
  4. Message de forum Prochaine réunion de travail stratégie de déploiement des identifiants uniques.

    Bonjour, la prochaine réunion de travail sur l'identifiant unique aura lieu le vendredi 22 septembre de 14 à 16h. Le sujet est la stratégie de propagation/initialisation des identifiants. Pour rappel des décisions ont été prises sur : le format de cet identifiant : uuid v4. les objets concernés : adresses, voies / lieux dits et communes. Le cycle de vie des adresses et voies : pour permettre l’historisation des adresses et des voies pour les utilisateurs. Un CR décrit les cas courants envisagés sur OSMOSE OSMOSE - Documents (numerique.gouv.fr) CR atelier identifiant unique 23 juin. Une documentation en Draft est également disponible sur Github DRAFT # Intégration des données de fichiers BAL au sein de la BAN · BaseAdresseNationale/ban-plateforme Wiki (github.com). Les outils sont en charges de la production des id BAN voies / lieux dits et adresses (SIG, mes adresses), plus largement le producteur les fourni. Pour préciser un peu l'ordre du jour, l'idée de cette réunion est de réunir des producteurs, des utilisateurs et les développeurs BAN autour de ces identifiants afin de mieux comprendre les problématiques de chacun. Il y a plusieurs stratégies possibles : - le producteur (les outils) fournit les identifiants sur les BAL - le producteur (les outils) fournit les identifiants sur les adresses certifiées uniquement. Cette stratégie pose des problèmes côté développement BAN. - Le producteur à un délai pour fournir ses identifiants, au delà la BAN met les identifiants, et les données ne sont plus mises à jour. - autres stratégies? Le déploiement se fera au fur et à mesure des possibilités développées dans les outils. Nous prévoyons une brève présentation de ce qui a été réalisé pendant cet été en première partie. N'hésitez pas à vous faire représenter en cas d'indisponibilité. Le lien de webinaire : https://webinaire.numerique.gouv.fr//meeting/signin/16152/creator/3581/hash/cfb8fe3545f6d0a68a9bd28a44d2a8fae8bdb8a1 Mélanie Mortier
  5. Message de forum Minimum Viable Product Cible V0

    Bonjour, Voici notre cible pour une V0 de l'identifiant unique. On récupère une BAL format 1.3 AITF avec des identifiants au format (à priori uuid v4) dans la colonne uid_adresse avec les spéc [BanID] Spécification temporaire du champ UID de la BAL 1.3 · [BanID] Spécification du champ UID de la BAL 1.3 · Issue #184 · BaseAdresseNationale/ban-plateforme (github.com) Une brique technique ID-Fix va lire la BAL pour déterminer quelles sont les créations / modifications / suppressions et les envoyer à l'API BAN Intégration dans la BAN avec préservation des ID uniques stables. Exports avec les identifiants de voies, d'adresses et de communes dans la colonne uid_adresse pour le format BAL. Nous allons prévoir un atelier pour le périmètre des adresses concernées prochainement avec 3 scénarios (adresses certifiées uniquement, adresses des BAL, toutes les adresses y compris assemblage). Nous discuterons des avantages et des inconvénients de chaque scénarios. Mélanie
  6. Message de forum Forme de l’identifiant unique BAN UUID V4 vs Nano ID

    L’identifiant va concerner plusieurs types d’objets : L’adresse La voie et/ou lieu-dit Il est envisagé d’utiliser le champ uid_adresse du format BAL AITF_SIG_Topo_Format_Base_Adresse_Locale_v1.3.pdf (aitf-sig-topo.github.io) en y concaténant un id d’adresse de voie et ou lieu-dit. Nous avons suivi les échanges concernant le choix de la forme de l’identifiant de BAT ID : Format de l'identifiant bâtiment · Issue #24 · fab-geocommuns/BatID (github.com) L’équipe BAN propose les UUID V4 pour plusieurs raisons : un identifiant non signifiant donc ne comporter aucune indication géographique ou producteur. une génération décentralisée possible. Nous proposons aussi de fournir des uuid V4 via une API à la demande si l’utilisateur en a besoin. L’algorithme de génération des UUID V4 est répandu et disponible dans de nombreuses technos. Il est non sensible à la casse. Compatible avec les URI INSPIRE. Limite les règles à diffuser aux producteurs qui livreront les identifiants, on veut des uuidV4, pas de paramétrage/règle supplémentaire à donner contrairement à NanoID. Ces identifiants sont des éléments techniques à destination des programmes et n’ont pas vocation à être interprétés par des personnes.. Nous attendons vos remarques à cette proposition. Nous nous fixons une limite de temps pour recueillir vos remarques que nous discuterons sur le forum, jusqu’au 16 juin. L’équipe adresse.
  7. Question de FAQ collaborative idvoie

    Bonjour, Je fais suite à l'échange de ce jour sur l'id. Nous restons interrogatifs sur la partie idvoie après avoir compris ce jour, que cet id n'est pas un id du nom de voie (qui est donc différent lorsqu'on débatise et nomme différemment une voie : cf fonctionnement du FANTOIR) mais bien un idvoie correspondant à un lieu qui n'est pas matérialisé géographiquement (car on ne s'appuie pas sur un référentiel de filaire et c'est une sage décision de ne pas l'avoir imposé pour les communes). Ce concept est très différent de ceux mis en oeuvre historiquement dans la plupart des SIG des collectivités qui s'adossent à un triptique de classes : pt adresse <> filaire des troncons de voie <> base des noms de voie. Sur le besoin premier de "tracer" l'ensemble des mouvements d'une adresse, nous estimons que l'id adresse devrait se suffire à lui même en cas de changement de "nom de voie". Si le 2 rue de la baleine, devient le 2 rue du cachalot, l'id adresse est commun mais l'id nom de voie peut être différent . Ce mouvement peut donc informatiquement être relevé et visible par les réutilisateur car l'id adresse est stable. A titre d'exemple, si la ligne de conduite est de ne pas "supprimer" et "recréer" un nouveau libellé de voie, comment gèrer le cas d'une voie dont le nom est en partie (seulement) conservée, et que l'autre partie prend un nom nouveau ? 2 (id:1) 4 (id:2) 2 (id:1) 2 (id:2) ________x____________________x________ >> ________x___________|_________x________ rue de la baleine (id:a) r. de la baleine (id:a) | rue du cachalot (id:a) Selon votre approche, ceci peut fonctionner car le concept abstrait de voie se maintient, id adresse (id:1, id:2) et id voie (id:a) ne changent donc pas (d'ailleurs pourquoi même gérer un idvoie dans ce cas ?). En revanche, selon l'implémentation courante des bases voies adresses dans les SI de collectivités, nous ne voyons pas comment maintenir cet id voie abstrait sans en passer à des changements importants ou à des ajustement manuels qui ne peuvent être admis. Pour nous, r. de la baleine resterait à (id:a) mais la r. du cachalot prendrait un (id:b). En effet, notre modélisation empecherait de simplement modifier (id:a) de la r. de la baleine en r. du cachalot pour le cas exposé. En conclusion, je pense que l'attente sur l'id voie et le concept sous jacent (initialement assimilé à l'id du nom de la voie pour nous) ne fera pas sens commun et mérite d'étre réviser. C'est un avis qu'il faut évidemment confronter auprès d'autres collectivités porteuses de SI adresse en propre. En tous les cas, il nous semble absolument nécessaire d'étayer à l'appui de cas pratiques, le cycle de vie adresse pour mettre à l'épreuve ces concepts tout en s'assurant également, de leur faisabilité de mise en oeuvre par les collectivités productrices. Par ailleurs, au titre de la constitution d'un GT voie au CNIG, faut il même implémenter un fonctionnement particulier et précurseur sur l'adresse sur la question des voies (qui se résume pour l'adresse uniquement à sa dénomination) ? Cordialement Florent VANHOUTTE Resp. SIG Agglo Compiègne
  8. Question de FAQ collaborative Mise à jour des adresses utilisées par des réutilisateurs

    Question redirigée depuis le slack adresse.data.gouv.fr Bonjour ! Nous avons une question qui nous turlupine depuis quelques temps maintenant concernant les mises à jour d'adresse dans les bases de données des réutilisateurs. Je contextualise : lorsqu'un organisme qui utilise de la donnée adresse en interne doit mettre à jour cette donnée suite à la certification d'une BAL par une commune, comment peut-elle être sûre que sa donnée (ancienne version d'une adresse) correspond à telle ou telle adresse (nouvelle version certifiée) ? Et lorsque la même commune mettra une nouvelle fois à jour cette donnée, comment la structure réutilisatrice saura qu'elle a été mise à jour et donc qu'elle-même devra effectuer une mise à jour ? L'exemple concret est un service de facturation d'ordures d'une collectivité. Le producteur de déchets M. Machin a une adresse de facturation 1 rue Tartanpion dans la commune X. Commune X qui décide de mettre à jour la donnée adresse et modifie celle-ci en 10 rue du Poirier. Comment le service de facturation peut effectuer cette mise à jour et donc savoir que M. Tartanpion habite au 10 rue du Poirier ? Sachant que dans ce cas précis, le service de facturation ne peut en aucun cas aller vérifier la donnée mise à jour sur une quelconque carte... On a le sentiment grandissant qu'il manque un fichier de suivi des adresses, type git... Grand merci d'avance !!
  9. Idée Gestion des identifiants BAN : quel périmètre / stratégie d'initialisation ?

    Lors des Geodatadays et de la dernière réunion AdresseLab, l'équipe BAN a évoqué un principe d'initialisation des identifiants sur laquelle il me semble important qu'on rediscute collectivement. Et je vais essayer d'expliciter ici quelques préoccupations déjà partagées lors de ces échanges. L'alimentation de la BAN est actuellement selon deux modes : par la publication des communes (avec fichier BAL = mode cible) par l'agrégation des données captées/disponibles par processus historique. L'intérêt de la BAN - et son succès notoire mesuré par exemple par l'usage de l'API- provient bien de cette vision globale France ENTIERE. Même si tous les utilisateurs de la BAN ne vont pas l'utiliser directement, il y a consensus je pense sur la préoccupation majeure d'une gestion d'identifiants BAN. Cette gestion est attendue avant tout pour permettre aux utilisateurs "administrateurs" d'identifier les créations/suppression d'objets ainsi que pour permettre répercuter efficacement les modifications d'adresses dans leurs bases de données. Ces utilisateurs "administrateurs" souhaitent la mise en place d'identifiants pour gérer toutes les évolutions survenues sur la BAN. Et la BAN évolue actuellement beaucoup : 1) lorsqu'une commune s'approprie son plan d'adressage 2) lorsqu'une commune fiabilise en qualité son adressage BAL 3) lorsqu'une commune gère ses mises à jour d'adresse "au flux" (évolution du territoire) Pour que les identifiants permette à des "administrateurs" de gérer efficacement l'articulation de leurs données à la BAN. Gérer les identifiants / évolutions de type 1) de manière "similaire" aux 3) est important car : Cela permet d'envisager des traitement uniformes France entière Cela permet d'analyser plus efficacement cette étape clé du territoire et facilitent l'accostage à la BAN pour tous les "administrateurs" qui ont des historiques de données. Selon les modalités retenues par la commune (partir d'un fichier BAL extrait de la BAN produite en mode historique), les changements d'adresses peuvent être déterminés précisément (même sur un % de communes , cela serait précieux !). Les évènement de type 2) sont concernés probablement au même titre - mais on manque de recul et d'analyse pour bien en parler… Cela milite donc pour une mise en œuvre le plus vite possible : cible d'un MVP travaillé ensemble pour fin 2023 ? Et l'hypothèse proposée de ne mettre en place les identifiants BAN que pour ces communes publiées en BAL (voir uniquement certifié) va donc à l'encontre des attentes que je viens d'évoquer. Qu'en pensez-vous ? (@utilisateur de ce forum - en particulier les utilisateurs "administrateurs" de données associées à des adresses. Ex : INSEE, DGFIP, gestionnaires de réseaux, gestionnaire de bases navigables, collectivités,…)