[OSM-talk-fr] Lot Talk-fr, Vol 94, Parution 99

Lun 19 Mai 21:28:47 UTC 2014

Je voudrais ajouter le cas des parcelles et des adresses avec 2 accès. Un sur une rue et l' autre de l' autre coté donnant sur une autre rue. L'adressage ne correspond pas a une logique définie mais parfois a des choix de propriétaires...

De nombreux cas prouvent que s'il semble avoir des règles permettant cette "systématisation" de nombreux cas particuliers existent.. D'ou l'idée d' une certification datée par exemple.

Envoyé à partir de mon Windows Phone
________________________________
De : talk-fr-request at openstreetmap.org<mailto:talk-fr-request at openstreetmap.org>
Envoyé : ‎19/‎05/‎2014 23:15
À : talk-fr at openstreetmap.org<mailto:talk-fr at openstreetmap.org>
Objet : Lot Talk-fr, Vol 94, Parution 99

Envoyez vos messages pour la liste Talk-fr à
        talk-fr at openstreetmap.org

Pour vous (dés)abonner par le web, consultez
        https://lists.openstreetmap.org/listinfo/talk-fr

ou, par email, envoyez un message avec 'help' dans le corps ou dans le
sujet à
        talk-fr-request at openstreetmap.org

Vous pouvez contacter l'administrateur de la liste à l'adresse
        talk-fr-owner at openstreetmap.org

Si vous répondez, n'oubliez pas de changer l'objet du message afin
qu'il soit plus spécifique que "Re: Contenu du digest de Talk-fr..."

Thèmes du jour :

   1. Re: Trouver les noeuds non rapportés à un bâtiment avec JOSM
      (Marc Sibert)
   2. Re: Lot Talk-fr, Vol 94, Parution 98 (dom bertho)

----------------------------------------------------------------------

Message: 1
Date: Mon, 19 May 2014 21:34:29 +0200
From: Marc Sibert <marc at sibert.fr>
To: Discussions sur OSM en français  <talk-fr at openstreetmap.org>
Subject: Re: [OSM-talk-fr] Trouver les noeuds non rapportés à un
        bâtiment avec JOSM
Message-ID: <537A5CC5.5030904 at sibert.fr>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

Le 19/05/2014 14:57, Marc SIBERT a écrit :
> Bon j'ai un petit schéma :
>
En fait il ne passe pas donc voici un lien :
http://eirl-marc.wp.sibert.fr/files/2014/05/Dessin2.png
>
> C'est bien clair : BANO synthétise et produit ; OSM est l'une des
> sources (la meilleure ?)
>
> A+
>
>
> Le 19 mai 2014 12:38, Vincent Pottier <vpottier at gmail.com
> <mailto:vpottier at gmail.com>> a écrit :
>
>
>     Le 19/05/2014 11:38, Pieren a écrit :
>
>         Je ne suis pas très à l'aise vis à vis de ce projet. D'un côté, je
>         comprend l'envie d'aller vite et d'offrir une base adresse
>         s'affranchissant des contraintes de l'import dans OSM. C'est
>         aussi à
>         cette tentation qu'à céder mapbox en créant le projet
>         "openaddresses"
>         ([1]), en voulant s'affranchir, lui, des problèmes de licences. Ca
>         nous fait donc déjà deux bases adresses "libres".
>         On voit bien où ça nous mène : un fork des données avec des
>         outils qui
>         seront obligés de jongler avec plusieurs bases (OSM pour la
>         navigation
>         et bano pour le géocodage, par exemple). C'est exactement
>         contre ça
>         qu'OSM a été créer : ne plus avoir à chercher à gauche et à droite
>         voir qui fait quoi, qui fait le mieux et comment et avec quelle
>         license pour travailler avec des données géographiques mais
>         avoir le
>         tout centralisé dans une seule base (et aussi pour les mises à
>         jour).
>
>         Donc "hourra pour bano" si ça sert à accélerer l'intégration des
>         adresses dans OSM. Mais "bof" si ça devient une solution
>         pérenne pour
>         compenser nos faiblesses comme dans la modélisation ou les
>         contraintes
>         de l'import (et qu'il vaudrait mieux surmonter).
>
>     OSM reste bien le réservoir de données autours duquel se développe
>     un écosystème.
>     Par nature, base de donnée ouverte, OSM a besoin de cet écosystème
>     pour la fourniture de données stabilisées.
>     OSM ne permet pas de connaître la qualité des données fournies :
>     précision, cohérence, libellés, exhaustive...
>     On le voit dans de nombreux exemples : trait de côte, limites des
>     collectivités territoriales...
>     Ce ne sont pas des données brutes OSM qui sont fournies, mais des
>     données au moins vérifiées dans leur intégrité, voire simplifiées.
>     Ce sont des interfaces de nature diverse qui fournissent ces
>     données avec un minimum d'information sur la qualité de celles-ci.
>
>     Il me semble, si j'ai tout compris, que BANO s'inscrit bien dans
>     la logique OSM en étant une double interface.
>     D'un côté l'aspect QA, permettant de compléter et corriger OSM (et
>     non d'importer dans OSM, ça a bien été répété)
>     De l'autre côté, proposer un jeu de données stabilisées, échappant
>     aux vicissitudes intrinsèques d'OSM : non permanence des ids,
>     risques d'introductions d'erreurs...
>     BANO permet que :
>     * à terme OSM soit bien le réservoir de données,
>     * à terme des jeux d'adresses cohérents soient fournis à qualité
>     standardisée (exhaustivité, précision, libellés, références...).
>
>     Comme il y a plusieurs fournisseurs de cartes Garmin à partir des
>     données OSM, comme il y a de nombreuses cartes en lignes, il y
>     aura probablement plusieurs fournisseurs de données stabilisées...
>     --
>     FrViPofm
>
>
>     _______________________________________________
>     Talk-fr mailing list
>     Talk-fr at openstreetmap.org <mailto:Talk-fr at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> --
> Marc Sibert
> marc at sibert.fr <mailto:marc at sibert.fr>

--
Marc Sibert
mailto:marc at sibert.fr

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140519/1068eea3/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 19 May 2014 23:17:36 +0200
From: dom bertho <new-dom at hotmail.fr>
To: "talk-fr at openstreetmap.org" <talk-fr at openstreetmap.org>
Subject: Re: [OSM-talk-fr] Lot Talk-fr, Vol 94, Parution 98
Message-ID: <DUB407-EAS2678BB9EEACCD413D9D37C28D320 at phx.gbl>
Content-Type: text/plain; charset="utf-8"

Je suis intrigué par cette discussion tournant autour de l'adressage. Le fichier fantoir n'a d'utilité que pour coder un numéro avec le code national du nom de la rue qui est unique.

La question est de savoir quelle précision on veut obtenir dans le positionnement d'un numéro d'adresse ?

C'est assez éloigné que de faire correspondre un numéro extrapolé par le cadastre par exemple.

Le positionnement  métrique est une alternative qui va engendrer beaucoup d' inexactitudes. comment générer les numéros bis, ter, voire les entrées bat A, B... Le positionnement de ce genre d' adresse est tout simplement impossible de cette façon.

Je travaille sur Paris, pour un prestataire de l'administration. J'ai travaillé pour un concepteur de logiciel de navigation. Il semble que de plus en plus les contributeurs orientent leur débat sur l' exploitation des données à des fins de navigation GPS. OSM ne défini pas ses critères dans cette optique, il s'agit plus d'une "globale" cartographie.

Il me semble que le positionnement des numéros est un point sensible qui admet une certification car les contributeurs sont les acteurs de la précision car ils font ce travail de terrain ESSESNTIEL.

Pour le reste, s'il s'agit d'exploiter l'adressage pour la navigation embarquée, il semble a la charge des concepteurs des logiciels de trouver les alternatives...

Envoyé à partir de mon Windows Phone
________________________________
De : talk-fr-request at openstreetmap.org<mailto:talk-fr-request at openstreetmap.org>
Envoyé : ?19/?05/?2014 21:11
À : talk-fr at openstreetmap.org<mailto:talk-fr at openstreetmap.org>
Objet : Lot Talk-fr, Vol 94, Parution 98

Envoyez vos messages pour la liste Talk-fr à
        talk-fr at openstreetmap.org

Pour vous (dés)abonner par le web, consultez
        https://lists.openstreetmap.org/listinfo/talk-fr

ou, par email, envoyez un message avec 'help' dans le corps ou dans le
sujet à
        talk-fr-request at openstreetmap.org

Vous pouvez contacter l'administrateur de la liste à l'adresse
        talk-fr-owner at openstreetmap.org

Si vous répondez, n'oubliez pas de changer l'objet du message afin
qu'il soit plus spécifique que "Re: Contenu du digest de Talk-fr..."

Thèmes du jour :

   1. Re: Projet BANO : bonne manière de taguer (Tyndare)
   2. Re: Projet BANO : bonne manière de taguer (Christian Quest)
   3. Re: Projet BANO : bonne manière de taguer (Jérôme Amagat)
   4. Re: Projet BANO : bonne manière de taguer (Tyndare)
   5. Format FANTOIR (was: Re: Correction de noms de voie pour
      jointure BANO) (Ralf Treinen)
   6. Re: Format FANTOIR (was: Re: Correction de noms de voie pour
      jointure BANO) (Christian Quest)

----------------------------------------------------------------------

Message: 1
Date: Mon, 19 May 2014 19:28:44 +0200
From: Tyndare <tyndare at wanadoo.fr>
To: Discussions sur OSM en français  <talk-fr at openstreetmap.org>
Subject: Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer
Message-ID:
        <CAMFe8j8tc9i=GnUa2YWdn0Q-a0QrzMatVvNR6m6Gc8rR2dDT2Q at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Pour les zones denses, je suis d'accord, mais pour les zones rurales
qui ont adopté la numérotation métrique, je pense que l'interpolation
permettrait d'approximer automatiquement les nouvelles adresses qui
seront ajoutées dans le futur sans avoir a attendre qu'un contributeur
éventuel repasse par là.

La modélisation par interpolation est je pense plus pérennes pour ce
problème là et peut être complémentaire avec la modélisation par point
adresses, le point adresses ayant la priorité si celui-ci existe.

Il n'est en tout cas très difficile d'interpoler automatiquement avec
les points adresses situés sur les maisons car j'ai vus de nombreux
cas où la maison (et sa parcelle) située à plus de 200m de la route,
avec des cas à 500m, ça me parait très compliqué d'interpoler quelque
chose de précis avec ça. La modélisation par interpolation calculerais
bien plus précisément le point d'accès sur la route principale.

Le cas typiques chez moi c'est d?interpoler entre le numéro 40 et le
numéro 920, pas entre 215 et 235, je parle de zones rurales...

Il suffit de faire l'expérience de la mise à jour du bâti cadastral
sur une commune où la dernière mise à jour date de 3-4 ans pour
s'apercevoir que le problème est réel et qu'il sera difficile de
maintenir les adresses à jour dans OSM avec la base de contributeurs
actuelle (on peut toujours extrapoler sur son augmentation ;-).

Je serais ok pour avoir un tag sur associatedStreet pour la
numérotation métrique (ou autre unité) mais est-ce une tendance
internationale cette manière de numéroter ? Est-ce que la modélisation
par interpolation ne correspond pas déjà à peu près ?

Le 19 mai 2014 18:46, Christian Quest <cquest at openstreetmap.fr> a écrit :
> L'interpolation peut toujours se faire, avec plus ou moins de précisions.
>
> Si il y a un 215 et un 235, le 225 sera quelque part entre les deux (dans ce
> cas on peut l'estimer au milieu).
> Si la route est sinueuse et qu'on a une relation associatedStreet, on peut
> projeter les 215 et 235 sur la voirie appartenant à la relation et trouver
> le 225 sur le milieu du tronçon.
>
> En gros, ça ne sert pas à grand chose de créer les interpolations... si on
> sait manipuler les données. Ca n'empêche pas de les saisir si ça nous fait
> plaisir, d'ailleurs avant que ma commune soit en cadastre vectoriel, j'avais
> fait une bonne partie avec des interpolations que j'ai ensuite reprises en
> ponctuel une fois le vectoriel disponible.
>
> Pour les voie numérotées en métrique, on pourrait avoir un tag qui le
> précise sur le associatedStreet (l'IGN a un truc de ce genre dans ses BD).
>
> Un truc qui par contre serait super cool pour le rendu carto, c'est de
> distinguer les adresses en coin de rue afin d'alléger le rendu aux zooms
> intermédiaires.
> J'ai un peu creusé la question, tenté des trucs à grand coups de postgis,
> mais c'est pas encore vraiment ça. Là ça serait tagguer pour un meilleur
> rendu (nouveau concept ©®?).
>
>
>
> Le 19 mai 2014 18:06, JB <jbosm at mailoo.org> a écrit :
>
>> Toute petite réponse d'un gars qui met pas vraiment les mains dans le
>> cambouis du clavier?
>> Si j'ai dans la base un numéro 215 et un numéro 235, j'arriverais surement
>> aussi bien à interpoler un numéro 225 que si j'ai juste des données
>> d'interpolation entre le numéro 205 et le 275, non ?
>> Bon, je m'interroge encore sur l'intérêt de mon message aussi?
>> JB
>>
>> Le 19/05/2014 17:46, Tyndare a écrit :
>>
>>> J'aurais voulu éviter d'embrouiller encore plus le débat, mais je ne
>>> suis pas d'accord pour écarter totalement l'interpolation comme mode
>>> de cartographie des adresses. C'est vrai que les données extraites du
>>> cadastre nous incitent pas à l'utiliser, mais ce mode pourrait avoir
>>> un grand avantage: il permettrait de modéliser une fois pour toute une
>>> bonne approximation de toutes les nouvelles adresses qui pourront être
>>> créées dans le futur dans une rue donnée, en particulier pour les rues
>>> ayant adopté la numérotation métrique (j'ai l'impression que c'est
>>> quasi systématique pour les nouvelles numérotations).
>>> Il y a de nombreuses communes en France avec une très faible densité
>>> de population, et dans certaines aucun contributeur local ne s'est
>>> manifesté au bout de 10 ans de projet. Dans son dernier post de blog
>>> Christian donne le chiffre de 200.000 nouvelles adresses chaque année
>>> en France [1], je ne vois pas pour l?instant comment OSM pourrait
>>> suivre ce rythme de manière à la fois réactive et homogène sur tout le
>>> territoire. Peut-être que BANO y arrivera en intégrant des données
>>> brutes issues de fournisseurs institutionnels ou autre, mais pour OSM
>>> comment on fait pour les zones sans contributeur local actif ?
>>>
>>> Comme on n'arrive pas à se mettre d'accord sur où positionner les
>>> point adresses, est-ce que l'on ne pourrait pas considérer
>>> l'interpolation comme une approximation durable et évolutive,
>>> potentiellement affinée par des points adresses additionnels ?
>>> Le seul truc qui m'embête c'est que j'ai l'impression d'après le Wiki
>>> [2] que l'utilisation de l'interpolation suppose que toutes les
>>> adresses interpolées aient une existence alors que cela ne serait pas
>>> du tout le cas avec une numérotation métrique.
>>>
>>> D'après vous, est-ce que la modélisation suivante serait correcte pour
>>> une numérotation métrique ?
>>>
>>> un way de chaque côté de la rue avec
>>>      addr:interpolation=odd/even
>>>      addr:inclusion=potential
>>> et pour ses nodes:
>>>      addr:housenumber=0/1 pour le premier, la longueur en mettre pour
>>> le dernier, et rien pour ceux des virages
>>>      addr:street=*
>>>
>>>
>>>
>>> [1] http://openstreetmap.fr/blogs/cquest/bano-banco
>>> [2] https://wiki.openstreetmap.org/wiki/Addresses#Using_interpolation
>>>
>>>
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

------------------------------

Message: 2
Date: Mon, 19 May 2014 19:51:05 +0200
From: Christian Quest <cquest at openstreetmap.fr>
To: Discussions sur OSM en français  <talk-fr at openstreetmap.org>
Subject: Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer
Message-ID:
        <CAAXY6DNcCb1L6mVcO-Ku=RyeMJB2zedEZKrMw-k252P8WM=CQw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Le 19 mai 2014 19:28, Tyndare <tyndare at wanadoo.fr> a écrit :

> Je serais ok pour avoir un tag sur associatedStreet pour la
> numérotation métrique (ou autre unité) mais est-ce une tendance
> internationale cette manière de numéroter ? Est-ce que la modélisation
> par interpolation ne correspond pas déjà à peu près ?
>

Il me semble tellement plus simple d'indiquer l'aspect métrique des
adresses liées à une voie par un simple tag supplémentaire que de tracer un
way assez arbitraire avec tout un paquet de tags associés pour obtenir à
peu de choses près le même résultat.

C'est pas forcément génial mon idée, juste un truc à creuser.

--
Christian Quest - OpenStreetMap France
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140519/266528c0/attachment-0001.html>

------------------------------

Message: 3
Date: Mon, 19 May 2014 19:58:32 +0200
From: Jérôme Amagat <jerome.amagat at gmail.com>
To: Discussions sur OSM en français  <talk-fr at openstreetmap.org>
Subject: Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer
Message-ID:
        <CAHUxktJ+URR-t5hWPdXQAL_CCExMrVuxZLUR-JfxoSiP2d53_w at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Je comprend pas trop le problème, pour moi l'interpolation est a la même
que ça soit métrique ou pas. Et d?après moi c'est l'utilisateur de osm ou
de bano qui devra interpoler grâce au numero existant. Le seul probleme
c'est pour un numero après le dernier existant dans le cas non metrique.

Le 19 mai 2014 19:51, Christian Quest <cquest at openstreetmap.fr> a écrit :

>
> Le 19 mai 2014 19:28, Tyndare <tyndare at wanadoo.fr> a écrit :
>
> Je serais ok pour avoir un tag sur associatedStreet pour la
>> numérotation métrique (ou autre unité) mais est-ce une tendance
>> internationale cette manière de numéroter ? Est-ce que la modélisation
>> par interpolation ne correspond pas déjà à peu près ?
>>
>
> Il me semble tellement plus simple d'indiquer l'aspect métrique des
> adresses liées à une voie par un simple tag supplémentaire que de tracer un
> way assez arbitraire avec tout un paquet de tags associés pour obtenir à
> peu de choses près le même résultat.
>
> C'est pas forcément génial mon idée, juste un truc à creuser.
>
> --
> Christian Quest - OpenStreetMap France
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140519/6a68b4d5/attachment-0001.html>

------------------------------

Message: 4
Date: Mon, 19 May 2014 20:38:52 +0200
From: Tyndare <tyndare at wanadoo.fr>
To: Discussions sur OSM en français  <talk-fr at openstreetmap.org>
Subject: Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer
Message-ID:
        <CAMFe8j_ULdE3GBCZNmvCwGj7Nat8h61hUQxp9EtNQwvjHdyLXw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Dans le modèle de données OSM rien n'indique que faire de
l'interpolation entre des valeurs addr:housenumber ait un sens si
elles ne sont pas dans un way addr:interpolation.
J?insistais sur le mode d'adressage «métrique» car c'est celui qui me
parait le plus compatible avec l'interpolation, les adresses
additionnelles ne seront normalement pas formées avec des suffixe tel
que bis,ter,... et on connait a peut près la valeur maximale.
Mon objectif serait de  pouvoir modéliser une fois pour toute
l?approximation de «toutes» les adresse d'une rue (actuelles et
futures).

Le 19 mai 2014 19:58, Jérôme Amagat <jerome.amagat at gmail.com> a écrit :
> Je comprend pas trop le problème, pour moi l'interpolation est a la même que
> ça soit métrique ou pas. Et d?après moi c'est l'utilisateur de osm ou de
> bano qui devra interpoler grâce au numero existant. Le seul probleme c'est
> pour un numero après le dernier existant dans le cas non metrique.
>

------------------------------

Message: 5
Date: Mon, 19 May 2014 21:01:31 +0200
From: Ralf Treinen <treinen at free.fr>
To: Discussions sur OSM en français  <talk-fr at openstreetmap.org>
Subject: [OSM-talk-fr] Format FANTOIR (was: Re: Correction de noms de
        voie pour jointure BANO)
Message-ID: <20140519190131.GA13121 at free.fr>
Content-Type: text/plain; charset=iso-8859-1

Hello,

On Mon, May 19, 2014 at 10:51:32AM +0200, Jean-Marc Liotier wrote:

> - Si le name est correct mais différent de la valeur donnée par le cadastre,
> alors je rajoute ref:FR:FANTOIR pour que le script BANO de Christian puisse
> quand même faire la jointure

j'ai un petit souci avec la description du format FANTOIR sur le wiki:
la page [1] dit que le format long FANTOIR est à 10 caractères. Or,
la description technique [2] (section 2.3 Enregistrement Voie) spécifie
11 caractères jusqu'à la clef Rivoli incluse. En fait, selon [2], il y a
un caractère "code direction" à la position 3 que la description [1]
ignore.

Donc, c'est bien les 11 permières caractères qu'on trouve sur une ligne
du fichier FANTOIT qu'il faut renseigner ?

-Ralf.

[1] http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
[2] http://www.collectivites-locales.gouv.fr/files/files/gestion_locale_dgfip/Descriptif_FANTOIR_2013.pdf

------------------------------

Message: 6
Date: Mon, 19 May 2014 21:10:31 +0200
From: Christian Quest <cquest at openstreetmap.fr>
To: Discussions sur OSM en français  <talk-fr at openstreetmap.org>
Subject: Re: [OSM-talk-fr] Format FANTOIR (was: Re: Correction de noms
        de voie pour jointure BANO)
Message-ID:
        <CAAXY6DNYa_D33FjXNCk8T3WBqYSCTWGiGATVpY6w0rxxuUshHA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Le code de direction de la DGFiP c'est pas inclu dans le ref:FR:FANTOIR

C'est donc bien une valeur à 10 caractères qui est utilisée et pas 11.

Le 19 mai 2014 21:01, Ralf Treinen <treinen at free.fr> a écrit :

> Hello,
>
> On Mon, May 19, 2014 at 10:51:32AM +0200, Jean-Marc Liotier wrote:
>
> > - Si le name est correct mais différent de la valeur donnée par le
> cadastre,
> > alors je rajoute ref:FR:FANTOIR pour que le script BANO de Christian
> puisse
> > quand même faire la jointure
>
> j'ai un petit souci avec la description du format FANTOIR sur le wiki:
> la page [1] dit que le format long FANTOIR est à 10 caractères. Or,
> la description technique [2] (section 2.3 Enregistrement Voie) spécifie
> 11 caractères jusqu'à la clef Rivoli incluse. En fait, selon [2], il y a
> un caractère "code direction" à la position 3 que la description [1]
> ignore.
>
> Donc, c'est bien les 11 permières caractères qu'on trouve sur une ligne
> du fichier FANTOIT qu'il faut renseigner ?
>
> -Ralf.
>
>
> [1] http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
> [2]
> http://www.collectivites-locales.gouv.fr/files/files/gestion_locale_dgfip/Descriptif_FANTOIR_2013.pdf
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

--
Christian Quest - OpenStreetMap France
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140519/e8375f84/attachment.html>

------------------------------

_______________________________________________
Talk-fr mailing list
Talk-fr at openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Fin de Lot Talk-fr, Vol 94, Parution 98
***************************************
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140519/9b27f7df/attachment.html>

------------------------------

_______________________________________________
Talk-fr mailing list
Talk-fr at openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Fin de Lot Talk-fr, Vol 94, Parution 99
***************************************
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140519/7c10b9ba/attachment.htm>