Encore une fois je suis plutôt de l'avis de Tony que de toi Marc sur ce point: si la référence et l'origine des noms de voie, et leur segmentation, vient de la commune, c'est le référenciel de la commune qui fournit les identifiants les plus précis et les plus stables. Tous les autres (Rivoli, etc.) sont dérivés et non stables (y compris les identifiants d'OSM).
En vertu de quoi l'identifiant utilisé par la source réelle a une utilité, il met tout le monde d'accord même si chacun à ses propres identifiants en plus (mais doit les corriger en permanence). Ton point de vue serait que ce seraient les identifiants d'OSM qui serviraient de référence, à charge pour la collectivité qui en est *réellement* à l'origine, de se mettre à jour (ce qu'elle ne fera pas car cela impactera aussi les autres acteurs, comme Rivoli qui n'utilisent pas non plus la base OSM comme référence en cas d'ambiguité ou de différences). Le référentiel reste donc celui décidé et utilisé par la collectivité (que celle-ci utilise son propre SIG, ou celui de sa communauté de communes sur lesquel elle a un accès direct et à tout moment le droit de faire les changements qu'elle souhaite, le SIG lui attribuant des identifiants uniques sur la base de la communauté de communes et que la commune utilise poru partager les coûts d'exploitation et maintenance, en lui transmettant les décisions du conseil municipal). Importer ces idenyifiants de référence dans OSM a cependant du sens seulement si ces identifiants sont accessibles au public (pas nécessairement par un site en ligne, ce peut être un fichier demandé à la collectivité, ou une demande faite à un de ses bureaux, car la collectivité n'a pas forcément mis en place un service web pour le faire en direct). Je préfère donc la limite posée sur le fat que les identifiants déposés dans OSM sont accessibles au public (mais pas nécessairement sur une base ouverte). C'est la bonne limite qui évite d'avoir à insérer dans OSM la numérotation interne nationale des franchises McDonald par exemple (la seule chose qui soit publique ce sont leurs numéros RCS voire les SIRET, mais même dans ce dernier cas je n'en suis pas sûr, l'accès public s'arrêtant au SIREN sans mentionner le détail de chaque établissement, et le SIREN ne correspondant pas non plus forcément au découpage géographique des points de vente s'il y en a plusieurs à proximité les uns des autres gérés légalement par la même entité, par exemple deux points de vente de la même franchise dans un même centre commercial, et avec pourtant pour le groupe l'envie de gérer en interne les résultats de chacun comme des établissements séparés) Autre exemple, les identifiants internes des sociétés telles que celles de transport ou de logistique qui exploitent le réseau public, ou qui gèrent leurs fichiers clients ou fournisseurs : ce sont des données privées, il ne faut pas que le client/fournisseur soit identifiable par le public comme étant en relation avec cette société du seul fait qu'il est référencé dans sa base privée (dans les fichiers clients ou fournisseurs il arrive qu'on y trouve des numéros de SIREN voire SIRET pour les organisations, pour les clients privés ils ont leurs noms et adresses et peuvent parfois inclure une vérification de leur identité avec un numéro de pièce d'identité ou de sécurité sociale, ces infos sont là encore confidentielles, et pour autant pas nécessairement très bien géolocalisés au delà des adresses de contact, de livraison ou de facturation elles aussi privées). Le 16 avril 2013 17:59, Marc SIBERT <[email protected]> a écrit : > Pas de problème, j'ai bien noté ce point de vue, mais je ne le partage > simplement pas, bien amicalement :-) > > Je comprends que les différentes administrations aient leurs UID locaux, > mais je considère, peut être à tord, que OSM *est le référentiel* et que > c'est à ce référentiel de produire un UID et qu'il est plus simple que les > différentes administrations l'utilisent (un champ à rajouter dans chaque > base utilisatrice et non un attribut de plus sur chaque élément d'OSM). Par > contre, je propose d'intégrer le Rivoli (j'ai du écrire TIVOLI plus haut, > c'est une typo et une déformation pro cf . IBM-TIVOLI) dans la base > Référentiel d'OSM (pas nécessairement dans OSM même). Avec cet identifiant > unique des voies et les numéros d'adresses, on peut produire des tronçons > entre les numéros et leur fournir des UID stables. > > Sincèrement, je ne vois pas les contributeurs maintenir les UID > propriétaires pendant leurs contributions : ils ne verront simplement pas > l'intérêt ; par contre, il "vous" (les différentes administrations) sera > relativement facile de les maintenir chez vous, sachant que vous en > connaissez la signification, quand ces ID ne sont pas obscurs, et que > "nous" (OSM + Nouveau Référentiel) vous fournissons les éléments *stables* > pour les associer. > > Par contre, j'ai basé mon analyse sur la présence du "Rivoli" (ou > équivalent) sur tous le filaire routier. Comme solution de secours, il > reste encore le nom des voies, mais là je ne compte pas trop sur > l'homogénéité... quoiqu'il est possible de normaliser dans le "Référentiel" > sans toucher à OSM. > > Je ne pense pas que le souplesse d'OSM soit faite pour répondre aux > besoins ponctuels de "consommateurs" du référentiels (même si c'est > techniquement facile). Dans ma définition des données référentielles, elles > sont, entre autre "Agnostiques des applications utilisatrices" ; ce ne > serait plus le cas ici. Pour moi un champ qui n'est utilisé que par une > seule application (la tienne) n'a pas sa place dans le "Référentiel". Mais > je propose un mécanisme pour assurer la stabilité et un UID de synthèse. > > Voilà mon point de vue. > > Cordialement, > > > > Le 16 avril 2013 17:16, Tony Emery <[email protected]> a écrit : > > Je m'excuse de revenir encore dessus mais certaines collectivités gèrent >> des >> référentiels adresses réalisés en interne et je les vois mal ne pas avoir >> créer d'identifiant interne pour leurs voies. >> >> L'avantage est que, les collectivités étant la source principale des >> données, on peut plus s'appuyer sur ce travail que sur la collecte des >> données via la DGFiP ou l'INSEE (j'ai déjà expliqué pourquoi, je reviens >> pas >> dessus). >> >> L'inconvénient est que, les collectivités étant indépendantes les unes des >> autres, ces référentiels se sont créés dans des systèmes différents, au >> contraire du Rivoli qui s'applique partout en France de la même manière. >> >> Pour info, j'ai fait un recoupement depuis ma base d'adresses. Sur 732 >> voies, je n'en ai que 686 qui ont un code Rivoli... >> >> Je pense que la souplesse d'OSM permettrait largement de gérer les >> identifiants internes des collectivités. >> >> >> >> -- >> View this message in context: >> http://gis.19327.n5.nabble.com/Liens-de-et-vers-OSM-tp5757047p5757364.html >> Sent from the France mailing list archive at Nabble.com. >> >> _______________________________________________ >> Talk-fr mailing list >> [email protected] >> http://lists.openstreetmap.org/listinfo/talk-fr >> > > > > -- > Marc Sibert > [email protected] > > _______________________________________________ > Talk-fr mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
