[OSM-talk-fr] Coexistence du tag "ref:FR:commune" et "ref:FR:FANTOIR" [était "CR rencontre DMI de Grenoble"]

[Pieren]

Je prolonge la discussion sur la liste talk-fr parce qu'elle concerne
tout le monde et que le contenu d'OSM ne relève pas de l'association:

2015-02-26 21:31 GMT+01:00 DH <dhelfer at 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.
:
> Il ne faut pas se méprendre sur la chaine de valeur de l'information. Comme
> l'a justement rappelé Tony, la commune est TITULAIRE de la dénomination de
> la voirie. Le FANTOIR, certes national -merci Napoléon-, n'intervient qu'en
> 2ème rang avec toutes les erreurs de transcription de graphies,
> d'homophonies, etc.


2015-02-26 23:22 GMT+01:00 Guillaume Allegre <allegre.guillaume at free.fr>:
> MAIS je ne parlais pas de la donnée adresse et voirie (objet succinct du paragraphe
> suivant), mais des autres objets

C'est bien de le préciser ;-) Ca soulève du coup d'autres questions
(utilisation du même tag pour des objets totalement différents, quid
de la doc, etc) mais bon.
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 ? 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. 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. Dont acte. Un argument que je suis aussi prêt à défendre
à l'international car c'est une solution incontournable en France.
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.
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. Mais
on sait tous que les communes peuvent croiser leurs codes avec ceux du
cadastre mais que l'inverse n'est pas vrai et que c'est ingérable en
dehors de la sphère commune/interco. Il faut rester pragmatique et ne
laisser que le seul code fantoir, le seul qui soit ensuite
réutilisable pour croiser les fichiers de toutes les communes par tout
les consomateurs de données OSM.