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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:
> 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 <[hidden email]>:
> 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.

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Coexistence du tag "ref:FR:commune" et "ref:FR:FANTOIR" [était "CR rencontre DMI de Grenoble"]

Vincent de Château-Thierry-2

> De: "Pieren" <[hidden email]>
>
> 2015-02-26 21:31 GMT+01:00 DH <[hidden email]>:
> > 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Coexistence du tag "ref:FR:commune" et "ref:FR:FANTOIR" [était "CR rencontre DMI de Grenoble"]

verdy_p
In reply to this post by Pieren


Le 27 février 2015 13:33, Pieren <[hidden email]> a écrit :
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 <[hidden email]>:
> 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.
 
Et encore une fois on oublie de dire que la commune n'est TITULAIRE de la dénomination QUE pour la partie de la voirie située sur son territoire.

Ce qui exclut les côtés des voiries situées sur une commune limitrophe (les deux communes peuvent se mettre d'accord pour utiliser le même nom, mais elles n'ont aucune obligation de le faire, même si elles sont dans la même intercommunalité, et notamment quand le segment de voirie partagé se prolonge à une extrémité ou l'autre (voire les deux) par un segment dont les deux côtés sont entièrement sur son territoire.

Orange et sa CCPRO n'ont peut-être pas ce cas de doubles noms, mais Tony a voulu généraliser un peut vite à toutes les communes de France. Du coup on peut malgré tout se retrouver avec DEUX "ref:FR:commune=*" selon sa proposition de tag ! Toute la discussion à ce sujet est partie sur ce simple constat. J'ai encore une fois l'impression que personne ne veut le comprendre.

Ça remet en cause le tag "ref:FR:commune=*" sur le segment de voie partagée (objet de type "way" dans OSM) sur ces cas là (et aussi le code FANTOIR propre à chaque commune).

C'est là dessus qu'on a admis qu'il faudrait deux relations "type=associatedStreet", avec pour chacune ses propres références en tags : "ref:FR:commune=*", "ref:FR:FANTOIR=*", "addr:city=*"... ainsi que "addr:postcode=*" (qui cependant a de grande chances d'être le même entre les deux relations, la Poste ne séparant que rarement ses tournées selon le côté de la rue, même si les deux cotés ne sont pas sur les mêmes communes, comme elle le fait en zone frontalière des communes rurales quand le chemin d'accès le plus pratique vers une ferme isolée vient de la commune voisine, la zone de distribution postale ne suivant pas toujours exactement les limites administratives).

Et dans ce cas le "name=*" qu'on indique sur le chemin devrait inclure les deux noms avec un séparateur adéquat (le point-virgule collé n'est pas pratique, il est plus courant de mettre un nom unique avec un "/" encadré d'espaces), ou un seul nom si c'est le seul affiché sur place (parce qu'il n'y a encore aucune adresse sur le côté de l'autre commune et que celle-ci n'a pas jugé utile d'y poser un panneau indicateur); la relation "type=associatedStreet" devrait aussi avoir un tag "name=*" par défaut non ambigu (suffixé par le nom de la commune), et le nom isole de la voirie pour la commune concernée sera dans le tag "addr:street=*" de la relation.

En résumé pour trouver le nom de voie effectif et sa référence FANTOIR (ou communale) pour les adresses postales, il faudrait :

- regarder d'abord s'il existe une ou deux relations "type=associatedStreet" reprenant le segment de voie.
- puis distinguer la commune pour savoir quelle relation "type=associatedStreet" utiliser quand il y en a deux (avec un problème : addr:city est le nom **postal** et pas toujours le nom de la commune elle-même, ce peut être une le nom d'une section de commune, la commune réelle étant omise des adresses postales, cas fréquent en cas de communes rurales fusionnées comportant plusieurs villages, qui d'ailleurs peuvent avoir conservé des codes postaux distincts): en cas d'ambiguïté on pourrait utiliser la codification proposée par Tony qui inclue dans ref:FR:commune les 5 chiffres du code INSEE (ce peut être un code INSEE d'une ancienne commune avant sa fusion ou celui d'une commune associée ou déléguée, ce code figure d'ailleurs encore dans le cadastre des communes fusionnée pour distinguer les numéros de sections cadastrales : il est marqué en préfixe avant le code Lettre+Chiffres de cette section pour les sections venant d'une commune associée ou déléguée)
- puis regarder dans le relation "addr:street=*" (s'il y est il est prioritaire sur le "name=*" de la relation qui peut avoir des suffixes informatifs de désambiguïsation),
- sinon le "name=*" de la relation,
- sinon en dernier lieu le "name=*" du segment de voie (objet de type "way").


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Coexistence du tag "ref:FR:commune" et "ref:FR:FANTOIR" [était "CR rencontre DMI de Grenoble"]

Pieren
In reply to this post by Vincent de Château-Thierry-2
2015-02-27 14:40 GMT+01:00 Vincent de Château-Thierry <[hidden email]>:

> 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.

La discussion ne concerne que les voies qui ont déjà un code FANTOIR.
Pour une commune, j'imagine que c'est l'immense majorité des cas. Pour
les voies nouvelles qui n'ont pas encore de ref FANTOIR, j'ai déjà
répondu par ailleurs que le tag "ref:FR:commune" était compréhensible,
faute de mieux.

> 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.

Ben non, c'est là où on ne va pas être d'accord (tant pis, c'est pas
mortel) et où tu va avoir beaucoup de mal à convaincre le reste des
contributeurs. Multiplier les tags "ref" montre certes une belle
dynamique de réutilisation mais elle rend surtout l'interprétation des
données plus difficile par les humains...  et inutile. Ce sont d'abord
les humains qui maintiennent et maintiendront la voirie OSM dans le
futur, pas des programmes de synchronisation avec des référentiels
externes que personne n'a encore vu à l'oeuvre après 10 ans. Nous
avons tout à gagner à utiliser un uuid (identifiant unique). Comme
cela n'existe pas par défaut dans OSM, on peut parfaitement adopter le
code FANTOIR et s'en contenter (et le "ref:FR:commune" là où il n'y en
a pas). Sans vouloir être jacobin, il a l'avantage d'être déjà public,
présent et cohérent sur l'ensemble du territoire, our toutes les
communes, ce qui n'est pas le cas d'un "ref:FR:commune". Concernant la
prolifération de tags abscons, lorsqu'il y a des discussions sur les
listes de diffusion internationales et qu'il faut choisir entre le
confort des contributeur et celui des "consommateurs" (souvent pour
éviter de faire un petit effort de programmation d'ailleurs), c'est
toujours celui des contributeurs qui est au final privilégié car c'est
le contributeur lambda, celui qui est près du terrain, qui fait la
force du projet. La liste "imports" est remplie d'exemples de refs
externes remis en question ou même finalement rejetés pour un import
de nouveaux objets dans OSM. Alors en mettre 5 ou 10...

Pieren

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Coexistence du tag "ref:FR:commune" et "ref:FR:FANTOIR" [était "CR rencontre DMI de Grenoble"]

jbosm

Bon, comme Pieren a l'air de batailler seul contre le vent, je pollue un peu la discussion juste pour dire qu'il n'est pas seul, et que j'ai aussi du mal avec ces ajouts de ref à outrance.

On n'a pas écrit un jour que si une machine peut faire le travail, c'est à elle de le faire ? C'est sur, c'est plus facile pour tout le monde d'ajouter son identifiant unique dans la base, sans limite, puisqu'on peut en ajouter autant qu'on veut à chaque élément. Alors que chacun pourrait juste partir du ref naturel, ici probablement le Fantoir (puisque je vois mal quelqu'un aller croiser les ref de voirie avec les fichiers de chaque commune).

À quand un ref:google/viamichelin/mappy dans OSM ? D'après certains, ce serait la preuve d'une belle réutilisation des données ?

JB.

 

 

Le 27.02.2015 15:27, Pieren a écrit :

2015-02-27 14:40 GMT+01:00 Vincent de Château-Thierry <[hidden email]>:

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.

La discussion ne concerne que les voies qui ont déjà un code FANTOIR.
Pour une commune, j'imagine que c'est l'immense majorité des cas. Pour
les voies nouvelles qui n'ont pas encore de ref FANTOIR, j'ai déjà
répondu par ailleurs que le tag "ref:FR:commune" était compréhensible,
faute de mieux.

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.

Ben non, c'est là où on ne va pas être d'accord (tant pis, c'est pas
mortel) et où tu va avoir beaucoup de mal à convaincre le reste des
contributeurs. Multiplier les tags "ref" montre certes une belle
dynamique de réutilisation mais elle rend surtout l'interprétation des
données plus difficile par les humains...  et inutile. Ce sont d'abord
les humains qui maintiennent et maintiendront la voirie OSM dans le
futur, pas des programmes de synchronisation avec des référentiels
externes que personne n'a encore vu à l'oeuvre après 10 ans. Nous
avons tout à gagner à utiliser un uuid (identifiant unique). Comme
cela n'existe pas par défaut dans OSM, on peut parfaitement adopter le
code FANTOIR et s'en contenter (et le "ref:FR:commune" là où il n'y en
a pas). Sans vouloir être jacobin, il a l'avantage d'être déjà public,
présent et cohérent sur l'ensemble du territoire, our toutes les
communes, ce qui n'est pas le cas d'un "ref:FR:commune". Concernant la
prolifération de tags abscons, lorsqu'il y a des discussions sur les
listes de diffusion internationales et qu'il faut choisir entre le
confort des contributeur et celui des "consommateurs" (souvent pour
éviter de faire un petit effort de programmation d'ailleurs), c'est
toujours celui des contributeurs qui est au final privilégié car c'est
le contributeur lambda, celui qui est près du terrain, qui fait la
force du projet. La liste "imports" est remplie d'exemples de refs
externes remis en question ou même finalement rejetés pour un import
de nouveaux objets dans OSM. Alors en mettre 5 ou 10...

Pieren

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Coexistence du tag "ref:FR:commune" et "ref:FR:FANTOIR" [était "CR rencontre DMI de Grenoble"]

verdy_p
Je n'emploierais pas les termes de "refs à outrance" quand il s'agirait ici d'une source communale, malgré tout officielle, pour peu qu'elle soit publique et libre, ce qui n'est pas le cas des ref Google, Michelin Mappy...) on voit bien qu'on a un problème avec une source nationale (mais qui a du fiat de son extension nationale du mal à tout coordonner et rester à jour, et les besoins locaux plus immédiats des communes dans ce qui est de leur compétence).

Bref je ne m'oppose pas aux "ref:FR:commune" (en tant que complément utile des codes FANTOIR), à condition de les placer au bon endroit et que la source soit publiquement vérifiable et réutilisable librement, et qu'elle apporte une différence mesurable avec une valeur ajoutée.

Les SIG communaux sont en chantier permanent, le FANTOIR aussi pour répondre aux besoinx plus globaux y compris dans les communes non dotées de leur propre SIG (ou qui n'en a pas confié la gestion à une intercommunalité ou une autre collectivité ou un prestataire de service externe); il va bien arriver un moment où ces deux vont arriver à se synchroniser au point que l'un ou l'autre disparaîtra (ne sera plus maintenu), mais pour l'instant ce n'est pas le cas.

Le 27 février 2015 15:40, JB <[hidden email]> a écrit :

Bon, comme Pieren a l'air de batailler seul contre le vent, je pollue un peu la discussion juste pour dire qu'il n'est pas seul, et que j'ai aussi du mal avec ces ajouts de ref à outrance.

On n'a pas écrit un jour que si une machine peut faire le travail, c'est à elle de le faire ? C'est sur, c'est plus facile pour tout le monde d'ajouter son identifiant unique dans la base, sans limite, puisqu'on peut en ajouter autant qu'on veut à chaque élément. Alors que chacun pourrait juste partir du ref naturel, ici probablement le Fantoir (puisque je vois mal quelqu'un aller croiser les ref de voirie avec les fichiers de chaque commune).

À quand un ref:google/viamichelin/mappy dans OSM ? D'après certains, ce serait la preuve d'une belle réutilisation des données ?

JB.

 

 

Le 27.02.2015 15:27, Pieren a écrit :

2015-02-27 14:40 GMT+01:00 Vincent de Château-Thierry <[hidden email]>:

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.

La discussion ne concerne que les voies qui ont déjà un code FANTOIR.
Pour une commune, j'imagine que c'est l'immense majorité des cas. Pour
les voies nouvelles qui n'ont pas encore de ref FANTOIR, j'ai déjà
répondu par ailleurs que le tag "ref:FR:commune" était compréhensible,
faute de mieux.

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.

Ben non, c'est là où on ne va pas être d'accord (tant pis, c'est pas
mortel) et où tu va avoir beaucoup de mal à convaincre le reste des
contributeurs. Multiplier les tags "ref" montre certes une belle
dynamique de réutilisation mais elle rend surtout l'interprétation des
données plus difficile par les humains...  et inutile. Ce sont d'abord
les humains qui maintiennent et maintiendront la voirie OSM dans le
futur, pas des programmes de synchronisation avec des référentiels
externes que personne n'a encore vu à l'oeuvre après 10 ans. Nous
avons tout à gagner à utiliser un uuid (identifiant unique). Comme
cela n'existe pas par défaut dans OSM, on peut parfaitement adopter le
code FANTOIR et s'en contenter (et le "ref:FR:commune" là où il n'y en
a pas). Sans vouloir être jacobin, il a l'avantage d'être déjà public,
présent et cohérent sur l'ensemble du territoire, our toutes les
communes, ce qui n'est pas le cas d'un "ref:FR:commune". Concernant la
prolifération de tags abscons, lorsqu'il y a des discussions sur les
listes de diffusion internationales et qu'il faut choisir entre le
confort des contributeur et celui des "consommateurs" (souvent pour
éviter de faire un petit effort de programmation d'ailleurs), c'est
toujours celui des contributeurs qui est au final privilégié car c'est
le contributeur lambda, celui qui est près du terrain, qui fait la
force du projet. La liste "imports" est remplie d'exemples de refs
externes remis en question ou même finalement rejetés pour un import
de nouveaux objets dans OSM. Alors en mettre 5 ou 10...

Pieren

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
DH
Reply | Threaded
Open this post in threaded view
|

Re: Coexistence du tag "ref:FR:commune" et "ref:FR:FANTOIR" [était "CR rencontre DMI de Grenoble"]

DH
In reply to this post by Pieren
Le 27/02/2015 13:33, Pieren a écrit :

> 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.

Presque d'accord avec toi. Quand je parle de second rang à propos du
FANTOIR, je parle d'un point de vue légal. FANTOIR est pratique,
national, toussa.... comme l'IGN (troll detected ;-). Ce que je voulais
souligner c'est l'importance de sourcer l'information au niveau objet
(et non pas simplement au niveau changeset). OSM, d'un point de vue
qualité de la donnée, DOIT (must) se soucier non seulement des limites
de la source mais également des différents niveaux imbriqués, chacun
dans leur mission stricte. OK, c'est lourd de demander cela à des gens
qui prennent sur leur temps libre pour contribuer (aka je ne suis pas un
contributeur lamda).

Ok pour un système de subsidiarité des références sur la voirie ;
l'important est de coller à la référence la plus solide légalement, de
traquer les distorsions. Les progrès de la politique opendata des
collectivités locales laissent encore beaucoup de marge par rapport à la
DGFiP. Gageons que les initiatives des premières ne trouveront pas chez
OSM une porte close hermétiquement, pour des raisons en partie dogmatiques.
Je ne crois pas qu'OSM puisse aujourd'hui méconnaître l'écosystème de la
production d'information publique. Il y a, visiblement, des efforts de
communication à faire de part et d'autre.

Nous (communauté OSM) ne pouvons pas co-construire la description du
territoire uniquement sur la base de données libérées et d'efforts
individuels (ou collectifs en réponse à des urgences décrétées ou
imposées). C'est nécessaire mais pas suffisant (trop couteux par unité
de compte).
D'un autre côté, les producteurs de données publiques ne peuvent pas
espérer qu'en simplement publiant leur production sous licence opendata,
la base de données géolocalisées qu'est OSM non seulement sera réactive
mais en plus fournira une donnée facilement réutilisable pour leur
gestion. Toutefois, je crois qu'il y a un compromis durable possible.

Denis

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr