> De: "Pieren" <pier...@gmail.com> > > 2015-02-26 21:31 GMT+01:00 DH <dhel...@free.fr>: > > N'est-ce pas là le fond du problème ? Faire un référentiel > > géographique mutualisé multi-domaines (on balaie large de l'occupation du > > sol, > > aux services publics en passant par l'adresse sans oublier les PEI et > > les limites en tous genres) sans tenir compte des nécessaires > > connexions avec les réutilisateurs/producteurs. Ces primary key sont > > nécessaires > > tant qu'une solution plus durable (uuid géographisée déjà évoquée sur cette > > liste) n'émerge et fasse consensus. > > Pour revenir au code ref:FR:commune sur les voies, limité à Orange et > son interco pour l'instant, personne ne répond à une de mes questions > : si on laisse se propager plusieurs codes uniques pour chaque voie, > qui pourra dire stop à la prolifération de ces refs externes ?
Et pourquoi vouloir dire stop ? Je te trouve bien pessimiste. Si ces refs sont le témoignage d'un besoin, et d'une réutilisation d'OSM dans un système géré au jour le jour, ça préfigure plutôt d'une maintenance qui, indirectement, a toutes les chances de profiter au contenu OSM en retour. Une voie accidentellement supprimée dans OSM, c'est une alerte potentiel dans le SIG du consommateur, et en retour une correction apportée dans OSM pour remette d'aplomb le référentiel. > Ceux qui sont abonnés à la liste "import" savent à quel point le principe > même de "ref" externe pour le croisement de données est mal accepté, > voir refusé au moment des imports. Même le code fantoir doit encore > justifier de sa légitimité à l'extérieur de la France. À l'inverse, envisager que le contenu OSM est autonome et peut se passer de clés et autres mécanismes pour interagir avec un contenu externe, c'est largement prétentieux en l'état de la base (je ne dis pas ça pour toi mais ceux qui tiennent ce discours). Et c'est oublier que l'intérêt premier d'OSM est d'être utilisé... > Au moment de sa création, on nous a expliqué en long et en large que le > cadastre > n'étant pas suffisament fiable avec les dénominations, le code FANTOIR > servirait à croiser les données OSM avec le cadastre avec succès dans > tous les cas. Pour moi le code FANTOIR, et la problématique des "rapprochements" qui suscite beaucoup de questions et de contributions, est avant tout un outil pour mesurer l'avancement de notre couverture en voies nommées _dans OSM_, au niveau France. C'était ma première motivation pour faire http://cadastre.openstreetmap.fr/fantoir/ : permettre d'y voir clair surle reste à faire, par commune. > Mais si maintenant, chacun vient avec son propre code interne, c'est > plus difficile à admettre, surtout lorsqu'on sait que l'utilisateur a > aussi le code fantoir en local, donc que le croisement automatique > reste possible moyennant un petit effort au départ dans la mise en > place des outils. Tony a expliqué le souci il me semble : le FANTOIR est long à émerger, localement, et le besoin d'un ID unique pour chaque voie arrive bien avant la publication d'un code FANTOIR. Donc non, l'utilisateur n'a pas _immédiatement_ le code fantoir en local. Ça simplifierait voire annulerait cette discussion, sinon. > Denis, tu dis que le fantoir ne vient qu'en deuxième rang. Mais du > point de vue d'OSM, il n'y a pas de rang ni de priorité dans les > consommateurs de nos données. Il peut y avoir "des producteurs" de > code ref mais nous n'avons pas à connaitre leur hiérarchie, ni leur > priorité. A la limite, moi, je n'ai rien contre la généralisation des > codes "ref:FR:commune" mais alors on supprime les codes FANTOIR. Ça rejoint le point ci-dessus sur le nombre de ref distinctes. Je préfère poser la question autrement : si des consommateurs de données veulent s'appuyer sur FANTOIR, et que d'autres préfèrent un ref:FR:commune, pourquoi trancher ? Ce cumul de 2 ref, peut-être demain de 5 ou 10, serait plutôt pour moi un excellent signe : celui que des acteurs qui n'ont rien à voir entre eux, ont tous besoin de consommer nos données, et vont donc avoir un intérêt (une motivation) pour surveiller et maintenir ces données. vincent _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
