Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Romain MEHUT]

Le 18 mai 2014 17:33, Jean-Marc Liotier  a écrit :


> Seuls les noeuds flottants, indépendant de toute feature semblent faire
> l'unanimité à leur encontre.
>

Il n'y a absolument pas unanimité.

Romain
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Romain MEHUT]

Le 18 mai 2014 19:05, Yannick VOYEAUD  a écrit :


> Il n'y a qu'un seul et unique immeuble et pourtant 10 adresses
> différentes (1 à 10).
>

A l'inverse, il existe des cas où plusieurs bâtiments ont la même adresse.


> Pour le faire correctement on doit donc bien tagguer chaque entrée
> (adresse) à son emplacement physique.
>
> Je viens d'en faire la description sommaire. Toutefois les Rennais, sur
> place, voudront bien rectifier l'emplacement exact des entrées, et donc
> des numéros, ainsi que le positionnement de l'escalier proche du 9 car
> Bing n'est pas sympa sur ce coup car c'est dans l'ombre (qui a osé dire
> qu'il pleuvait toujours en Bretagne ;-) ).
>

Tu as regardé avec l'orthophotographie de GéoBretagne
http://wiki.openstreetmap.org/wiki/Service_WMS_ouvert_GeoBretagne ?

Romain
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] alt_name et associatedStreet

[Nicolas Dumoulin]

Bonjour,

Où vaut-il mieux mettre le alt_name d'une voie :
Sur les chemins (way), sur la relation associatedStreet, ou sur les deux ?

L'idéal de mon point de vue serait sur la relation pour éviter la duplication 
de valeurs (maintenance plus facile et moins de risque d'incohérence), mais 
bon pour l'instant, je mets sur les deux car je ne suis pas sûr que les outils 
comme nominatim aille chercher l'info dans la relation.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Pieren]

2014-05-19 9:12 GMT+02:00 Romain MEHUT :
> Le 18 mai 2014 17:33, Jean-Marc Liotier  a écrit :

> Il n'y a absolument pas unanimité.

On pourrait essayer de trouver un compromis. Apparement, les noeuds
flottants sont préférés dans certains cas (reste à définir lesquels).
Par contre, je crois qu'on est assez hunanimes à ne pas vouloir des
noeuds flottants systématiquement.

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Pieren]

2014-05-19 0:09 GMT+02:00 Christian Quest :

> Comment faire la différence dans les data OSM entre les adresse positionnées
> ainsi arbitrairement et celle qui au moins ont la cohérence d'être en limite
> entre l'espace public et privé telle que le fait (en général, pas toujours)
> le cadastre ?

Il faut surtout éviter ce piège d'avoir une vision trop "cadastrale"
de l'adresse. Même si c'est notre source principale ici, rappelons que
le cadastre ne gère pas les adresses, qu'il n'en est ni l'auteur ni le
gestionnaire et qu'il n'y a pas de lien direct entre adresse et
parcelle (il y a des parcelles sans adresses et des parcelles avec
plusieurs adresses) bien qu'elle en soit un attribut.
Le but des adresses est de localiser des gens ou des activités. Je
vois donc d'avantage de liens entre bâti et adresses qu'entre
parcelles et adresses. Ensuite, lorsqu'on descend au niveau de savoir
s'il faut le mettre sur la plaque ou sur la boite aux letttres ou sur
l'entrée, chaucun y cherchera son intérêt : le facteur ne
s'intéressera qu'à la boîte aux lettres, le visiteur cherchera d'abord
l'entrée principale...

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Pieren]

2014-05-18 16:55 GMT+02:00 Arnaud Vandecasteele :

> Avant de commencer à ajouter massivement des adresses,

Il faut faire très attention avant de se lancer dans un import à
partir de cette base BANO en odbl. La discussion sur la liste en
anglais a soulevé un problème sur la licence non négligeable (même si
ça reste très théorique) : en cas de changement éventuel de licence
dans le futur, il se pourrait que nous soyons obligés de supprimer les
adresses venant de BANO. Alors qu'on pourrait conserver celles venant
directement du cadastre.
Il serait donc plus prudent pour l'instant d'utiliser cet outil pour
identifier les manquements mais de prendre ensuite les données
directement depuis le cadastre.

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] alt_name et associatedStreet

[Christian Quest]

J'espère que Nominatim prend en compte associatedStreet, car le
rapprochement purement géométrique est quand même aléatoire pour associer
un addr:housenumber à un addr:street.

De toute façon, le plus simple c'est de tester !


Le 19 mai 2014 09:48, Nicolas Dumoulin <
nicolas_openstreetmap@dumoulin63.net> a écrit :

> Bonjour,
>
> Où vaut-il mieux mettre le alt_name d'une voie :
> Sur les chemins (way), sur la relation associatedStreet, ou sur les deux ?
>
> L'idéal de mon point de vue serait sur la relation pour éviter la
> duplication
> de valeurs (maintenance plus facile et moins de risque d'incohérence), mais
> bon pour l'instant, je mets sur les deux car je ne suis pas sûr que les
> outils
> comme nominatim aille chercher l'info dans la relation.
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Frédéric Rodrigo]

Le 19/05/2014 10:14, Pieren a écrit :

2014-05-18 16:55 GMT+02:00 Arnaud Vandecasteele :


Avant de commencer à ajouter massivement des adresses,


Il faut faire très attention avant de se lancer dans un import à
partir de cette base BANO en odbl. La discussion sur la liste en
anglais a soulevé un problème sur la licence non négligeable (même si
ça reste très théorique) : en cas de changement éventuel de licence
dans le futur, il se pourrait que nous soyons obligés de supprimer les
adresses venant de BANO. Alors qu'on pourrait conserver celles venant
directement du cadastre.
Il serait donc plus prudent pour l'instant d'utiliser cet outil pour
identifier les manquements mais de prendre ensuite les données
directement depuis le cadastre.


Je pense que chaque élément de la BANO doit être sourcé avec sa ou ses 
sources d'origine.

Importer la BANO... c'est pas trop dans ce but là qu'elle est faite.

Pour ce qui est de l'import de sources ODbL (donc avec Share-Alike) qui 
peut être gênant si du monde voulait retirer le SA : moi je dit 
justement, importons des données en SA ;) !


Mes 2 cents,
Frédéric.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[V de Chateau-Thierry]

> De : "Pieren"
>
> Il faut faire très attention avant de se lancer dans un import à
> partir de cette base BANO en odbl. La discussion sur la liste en
> anglais a soulevé un problème sur la licence non négligeable (même si
> ça reste très théorique) : en cas de changement éventuel de licence
> dans le futur, il se pourrait que nous soyons obligés de supprimer les
> adresses venant de BANO. Alors qu'on pourrait conserver celles venant
> directement du cadastre.
> Il serait donc plus prudent pour l'instant d'utiliser cet outil pour
> identifier les manquements mais de prendre ensuite les données
> directement depuis le cadastre.

J'ai suivi cette discussion sur talk@ et sa tournure m'a franchement étonné. Il 
ne me
serait jamais venu à l'idée d'utiliser BANO comme source d'import vers OSM, 
pour moi
le lien est fondamentalement dans l'autre sens : OSM alimente BANO. Le cercle 
vertueux
est ensuite : BANO est utilisée, des problèmes ou lacunes dans son contenu sont 
détectés,
ils sont corrigés dans OSM, et le prochain rafraîchissement de BANO profite de 
ces
corrections.

Et ainsi de suite.

Il y a des bénéfices connexes, comme la représentation carto des adresses 
initiée par
Christian, et qui contribue, via JOSM, à cibler les zones à qualifier (aka le 
dégommage
des points rouges). Mais pour ce qui est d'importer des adresses, je renvois aux
fichiers disponibles à : http://cadastre.openstreetmap.fr/?type=adresses qui ne 
sont
d'ailleurs pas à importer mais à intégrer :)

vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Christian Quest]

Le 19 mai 2014 00:37, Jean-Marc Liotier  a écrit :

> On 05/19/2014 12:09 AM, Christian Quest wrote:
> > Pour moi oui, surtout sans être allé sur le terrain, le point mis sur
> > le bâtiment est dans ce cas arbitraire.
> > Comment faire la différence dans les data OSM entre les adresse
> > positionnées ainsi arbitrairement et celle qui au moins ont la
> > cohérence d'être en limite entre l'espace public et privé telle que le
> > fait (en général, pas toujours) le cadastre ?
> >
> > Même en étant allé sur le terrain, je préfererai surtout ajouter un
> > entrance=yes/main
>
> Cette entrée doit-elle être liée à une adresse ?


Non pas forcément. C'est bien ça qui le semble important, on décrit les
choses une à une, la position de la "plaque" (linterface public/privé), le
bâtiment proche, l'entrée du bâtiment, etc...


> Est-ce que ça ne va pas
> finir en relation délicate à saisir, englobant entrée, adresse,
> bâtiment, boîte aux lettres etc. ?


Il faudra peut être passer par une modélisation utilisant une relation pour
rentrer dans tout ces détails et ne pas laisser d'ambiguité. Le problème ce
sont les ambiguïtés. On peut déduire un certain nombre de choses de façon
algorithmique, mais pas tout et c'est là qu'il faut ajouter des
informations pour lever les ambiguïtés.


> A mon avis, il faudrait que nous nous replongions dans les 2 rapports
> > de référence sur l'adresse: celui du CNIG et celui de l'Afigéo. Il y a
> > quand même du monde qui a réfléchit à ces problèmes, et à moins que ça
> > soit trop alambiqué (je ne crois pas), plus nous collerons à ce
> > modèle, plus OSM apparaitra comme crédible.
> > On passera ainsi directement de la BAN (qui n'existe toujours pas) à
> > la BANO...
>
> Tu as les URL sous la main ?
>

Oui:

http://openstreetmap.fr/blogs/cquest/BAN-a-cote-de-la-plaque

2ème et 3ème liens du billet de blog, c'est à dire:

http://cl.ly/3G1s0N0G2v2G (rapport CNIG que j'ai repartagé vu qu'il est
quasi introuvable)
et
http://www.afigeo.asso.fr/les-grands-dossiers/61-ladresse.html



> > Je me répète: Il est bien plus important et utile de s'occuper des
> > noms de voirie manquants.
> > il n'y a aucune urgence actuellement à ajouter/modéliser des adresses,
> > ça viendra et sera beaucoup plus facile une fois la première étape
> > faite et la réflexion/le consensus trouvé pour une modélisation
> > cohérente et homogène des adresses.
>
> Tu ferais bien de coller ça en bonne place partout où le projet BANO est
> exposé aux contributeurs... Il arrive pile dans le contexte mûr pour son
> explosion et il provoque une certaine excitation autour des adresses
> Openstreetmap... Il va falloir rappeler souvent qu'il s'agit avant tout
> d'une base de données tierce - certes liée à Openstreetmap et qui lui
> bénéficiera finalement, mais que le rapprochement de la voirie est un
> préalable qui a déja de quoi occuper du monde le temps que la
> problématique de modélisation se décante.
>

Oui, il faut qu'on soit plus explicite sur les différentes étapes
permettant un maximum d'efficacité. Bien sûr rien n'est obligatoire et OSM
est un projet ouvert ou chacun est libre d'avancer à sa manière, mais si on
se coordonne on sera globalement bien plus efficace.

Si on s'y prend bien, BANO a un potentiel énorme pour une adoption encore
plus massive d'OSM par les collectivités, les services de l'État, les
entreprises vu que le cycle de mise à jour et de montée en qualité de BANO
se base sur OSM.

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Christian Quest]

Le 19 mai 2014 08:15, Marc SIBERT  a écrit :

> tms[19]:http://{switch:a,b,c}.
> layers.openstreetmap.fr/bano/{zoom}/{x}/{y}.png
>

Tu peux aller jusqu'à 20:

tms[20]:http://{switch:a,b,c}.
layers.openstreetmap.fr/bano/{zoom}/{x}/{y}.png


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trouver les noeuds non rapportés à un bâtiment avec JOSM

[Pieren]

2014-05-17 9:46 GMT+02:00 Christian Quest :
> osmose, rajouter éventuellement un official_name pour le nom du cadastre.

grrr. quand je pense que le tag "official_name" a été créé à l'origine
pour des noms de pays...
Petit rappel, le cadastre (dgfip) n'est pas non plus l'organisme qui
définit le nom officiel des rues (pas plus que les numéros
d'adresses). Il n'y a qu'un seul name "official", c'est celui définit
par la mairie et pour celui-là, on utilise simplement le tag "name".
Utilisez plutôt "alt_name" est cas de divergence entre les deux et ne
laissez pas croire que le cadastre est plus "officiel" que la mairie.

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trouver les noeuds non rapportés à un bâtiment avec JOSM

[Jean-Marc Liotier]

On 19/05/2014 10:33, Pieren wrote:

2014-05-17 9:46 GMT+02:00 Christian Quest :

osmose, rajouter éventuellement un official_name pour le nom du cadastre.

Petit rappel, le cadastre (dgfip) n'est pas non plus l'organisme qui
définit le nom officiel des rues (pas plus que les numéros
d'adresses). Il n'y a qu'un seul name "official", c'est celui définit
par la mairie et pour celui-là, on utilise simplement le tag "name".
Utilisez plutôt "alt_name" est cas de divergence entre les deux et ne
laissez pas croire que le cadastre est plus "officiel" que la mairie.


Ayant bleui quelques points rouges de la BANO dans mon quartier hier 
soir, je confirme qu'il est loin d'être rare que le nom originaire du 
cadastre soit erroné... Le terrain d'abord !



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Christian Quest]

Le 19 mai 2014 10:14, Pieren  a écrit :

> 2014-05-18 16:55 GMT+02:00 Arnaud Vandecasteele :
>
> > Avant de commencer à ajouter massivement des adresses,
>
> Il faut faire très attention avant de se lancer dans un import à
> partir de cette base BANO en odbl. La discussion sur la liste en
> anglais a soulevé un problème sur la licence non négligeable (même si
> ça reste très théorique) : en cas de changement éventuel de licence
> dans le futur, il se pourrait que nous soyons obligés de supprimer les
> adresses venant de BANO. Alors qu'on pourrait conserver celles venant
> directement du cadastre.
> Il serait donc plus prudent pour l'instant d'utiliser cet outil pour
> identifier les manquements mais de prendre ensuite les données
> directement depuis le cadastre.
>


Ca délire pas mal sur talk@ à ce sujet oui, c'est peut être pas la peine
d'étendre la contagion ici.

Pourquoi BANO est en OdbL ?

- parce qu'il y a des données issues d'OSM dedans... une bien mauvaise
raison pour ne pas les importer dans OSM
- parce que certaines données en opendata sont en odbl: et alors ? on
arrête d'importer des données ODbL dans OSM ?

Pour les données du cadastre, on a un outil d'extraction, qui est utilisé
par BANO.
C'est ça qui est utilisé pour ajouter des adresses pas BANO qui est une
base composite OSM/opendata/cadastre/autre.

Le rendu BANO n'est pas destiné à ajouter des adresses, c'est totalement
contre productif, sauf si on veut perdre son temps. Il est par contre très
utile pour compléter les noms de rue manquants et ça c'est très productif.


Pour le délire anti-ODbL de talk@ c'est la nouvelle mode après les grandes
manoeuvres de Mapbox pour supprimer le share-alike (voire passer en domaine
publique, ce qui impliquerai aussi de virer l'attribution). D'après
certains, il ne faudrait plus importer de données avec une source
"share-alike" au cas où on changerai de licence pour OSM.

Pour moi qui considère le share-alike comme indispensable à la survie
d'OSM, c'est au contraire une bonne raison pour en ajouter encore plus ;)

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Comment tagguer une ressourcerie ?

[Francescu GAROBY]

Bonjour,
Comme l'indique le titre de ce mail, je cherche à tagguer des ressourceries.
"Kézako une ressourcerie ?" Pour faire court, c'est un lieu d'échange
d'objets recyclés, réutilisés, ... Mais c'est aussi de la sensibilisation
et du conseil aux particuliers, entreprises et collectivités sur le
recyclage et la diminution des déchets, etc. Le tout s'inscrivant dans un
esprit ESS (entreprise sociale et solidaire).
Plus d'infos ici :
http://www.ressourcerie.fr/Vos-Ressourceries/Le-concept/Le-concept-explique

Du coup, comment classer ça ? shop=second_hand me parait bien réducteur...

Francescu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Correction de noms de voie pour jointure BANO [was: Trouver les noeuds non rapportés à un bâtiment avec JOSM]

[Jean-Marc Liotier]

On 19/05/2014 10:39, Jean-Marc Liotier wrote:
Ayant bleui quelques points rouges de la BANO dans mon quartier hier 
soir, je confirme qu'il est loin d'être rare que le nom originaire du 
cadastre soit erroné... Le terrain d'abord !


La procédure que j'ai adoptée est:
- Si le name est incorrect et que sa correction correspond à la valeur 
donnée par le cadastre, alors je corrige le name
- 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


Ca vous paraît correct ?

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[THEVENON Julien]

 De : Frédéric Rodrigo 

Pour ce qui est de l'import de sources ODbL (donc avec Share-Alike) qui 
peut être gênant si du monde voulait retirer le SA : moi je dit 
justement, importons des données en SA ;) !

Tout a fait mon point de vue aussi !


Julien
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Pieren]

2014-05-19 10:40 GMT+02:00 Christian Quest :

> Pour le délire anti-ODbL de talk@ c'est la nouvelle mode après les grandes
> manœuvres de Mapbox pour supprimer le share-alike (voire passer en domaine
> publique, ce qui impliquerai aussi de virer l'attribution). D'après
> certains, il ne faudrait plus importer de données avec une source
> "share-alike" au cas où on changerai de licence pour OSM.


D'abord, je dois dire ici que je pense aussi que le changement de
licence est très, très théorique. Mais si on a le choix entre importer
des données odbl et prendre les mêmes depuis une source plus libre
comme l'est le cadastre (qui ne demande que l'attribution), il faut
prendre celles de la version la plus libre. Simple mesure de
précaution.
Maintenant, contrairement à ce que certains réclament, je ne
demanderais pas à interdire les sources odbl...

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] alt_name et associatedStreet

[Pieren]

2014-05-19 10:22 GMT+02:00 Christian Quest :
> De toute façon, le plus simple c'est de tester !

Et de toute façon, comme il y a des applications qui ne reconnaissent
pas les associatedStreet (et pour longtemps encore, semble-t-il, vu la
position des allemands sur cette relation), le minimum est de
conserver le tag sur le highway.

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Pieren]

2014-05-19 10:40 GMT+02:00 Christian Quest :

> Le rendu BANO n'est pas destiné à ajouter des adresses, c'est totalement
> contre productif, sauf si on veut perdre son temps. Il est par contre très
> utile pour compléter les noms de rue manquants et ça c'est très productif.

J'en parle parce que quelqu'un a posé une question sur une adresse
interpolée et lorsqu'on regarde dans la base, il a mis :"source=BANO"
C'est clair que dès que vous mettez des données en libre service,
certains vont s'en servir sans comprendre les conséquences au niveau
de la licence !

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Correction de noms de voie pour jointure BANO [was: Trouver les noeuds non rapportés à un bâtiment avec JOSM]

[Christian Quest]

C'est parfait.

Tu as un troisième cas... quand il y a un libellé sans correspondance
FANTOIR !

Dans ce cas, je pense que ref:FR:FANTOIR=no pourrait être exploité par le
scripts.



Le 19 mai 2014 10:51, Jean-Marc Liotier  a écrit :

> On 19/05/2014 10:39, Jean-Marc Liotier wrote:
>
>> Ayant bleui quelques points rouges de la BANO dans mon quartier hier
>> soir, je confirme qu'il est loin d'être rare que le nom originaire du
>> cadastre soit erroné... Le terrain d'abord !
>>
>
> La procédure que j'ai adoptée est:
> - Si le name est incorrect et que sa correction correspond à la valeur
> donnée par le cadastre, alors je corrige le name
> - 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
>
> Ca vous paraît correct ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Christian Quest]

Je comprends bien. A nous d'être clair sur l'objectif de BANO et son
interaction avec OSM.

Pour l'instant, on s'est surtout occupé du côté technique dans une premier
but de preuve de concept (est-ce qu'on obtient un résultat correct), avec
un gros manque de documentation et de communication... éternel problème des
pisseurs de code ! ;)

J'ai un second billet de blog à terminer...



Le 19 mai 2014 10:51, Pieren  a écrit :

> 2014-05-19 10:40 GMT+02:00 Christian Quest :
>
> > Le rendu BANO n'est pas destiné à ajouter des adresses, c'est totalement
> > contre productif, sauf si on veut perdre son temps. Il est par contre
> très
> > utile pour compléter les noms de rue manquants et ça c'est très
> productif.
>
> J'en parle parce que quelqu'un a posé une question sur une adresse
> interpolée et lorsqu'on regarde dans la base, il a mis :"source=BANO"
> C'est clair que dès que vous mettez des données en libre service,
> certains vont s'en servir sans comprendre les conséquences au niveau
> de la licence !
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO... premiers pas...

[Christian Quest]

Le point après un nouveau week-end de collecte.

BANO vient de passer le cap des 12,5 millions d'addresses cumulées (toutes
sources confondues), ce qui correspond plus où moins à 50% de nos
estimations (2M OSM + 1M opendata + 22M cadastre).

Le rendu se met à jour...

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trouver les noeuds non rapportés à un bâtiment avec JOSM

[Pieren]

2014-05-17 0:36 GMT+02:00 Christian Quest :

> 1) pour tout ce qui est calcul d'itinéraires et positionnement de données
> opendata ne contenant qu'une adresse on va très très prochainement pouvoir
> géocoder en s'appuyant sur BANO

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

Pieren

[1] http://openaddresses.io/

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Correction de noms de voie pour jointure BANO [was: Trouver les noeuds non rapportés à un bâtiment avec JOSM]

[Jean-Marc Liotier]

On 19/05/2014 10:59, Christian Quest wrote:

C'est parfait.

Tu as un troisième cas... quand il y a un libellé sans correspondance 
FANTOIR !


Dans ce cas, je pense que ref:FR:FANTOIR=no pourrait être exploité par 
le scripts.


J'ai repris ces explications dans 
http://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_%28BANO%29#T.C3.A2ches_actuelles_pour_les_contributeurs 





Le 19 mai 2014 10:51, Jean-Marc Liotier > a écrit :


On 19/05/2014 10:39, Jean-Marc Liotier wrote:

Ayant bleui quelques points rouges de la BANO dans mon
quartier hier soir, je confirme qu'il est loin d'être rare que
le nom originaire du cadastre soit erroné... Le terrain d'abord !


La procédure que j'ai adoptée est:
- Si le name est incorrect et que sa correction correspond à la
valeur donnée par le cadastre, alors je corrige le name
- 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

Ca vous paraît correct ?



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trouver les noeuds non rapportés à un bâtiment avec JOSM

[Vincent Pottier]

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Yannick VOYEAUD]

Le 19/05/2014 09:16, Romain MEHUT a écrit :
> Le 18 mai 2014 19:05, Yannick VOYEAUD  > a écrit :
>  
> 
> Il n'y a qu'un seul et unique immeuble et pourtant 10 adresses
> différentes (1 à 10).
> 
> 
> A l'inverse, il existe des cas où plusieurs bâtiments ont la même adresse.

Bonjour Romain,

Dans ce cas les bâtiments ont un élément d'adresse distinctif (souvent
une lettre).
Dans ce cas je suggère de faire un polygone qui prend l'ensemble de
l'adresse et de faire les immeubles à l'intérieur avec chacun leur
identification spécifique. Cela me semble logique.


>  
> 
> Pour le faire correctement on doit donc bien tagguer chaque entrée
> (adresse) à son emplacement physique.
> 
> Je viens d'en faire la description sommaire. Toutefois les Rennais, sur
> place, voudront bien rectifier l'emplacement exact des entrées, et donc
> des numéros, ainsi que le positionnement de l'escalier proche du 9 car
> Bing n'est pas sympa sur ce coup car c'est dans l'ombre (qui a osé dire
> qu'il pleuvait toujours en Bretagne ;-) ).
> 
> 
> Tu as regardé avec l'orthophotographie de GéoBretagne
> http://wiki.openstreetmap.org/wiki/Service_WMS_ouvert_GeoBretagne ?

Merci de cette adresse qui est plus performante même en haut niveau de zoom.
J'en ai profité pour retoucher le contour de l'immeuble et maintenant je
suis sûr à 1000% que les points adresse sont parfaitement positionnés.

Amitiés

-- 
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Romain MEHUT]

Le 19 mai 2014 13:14, Yannick VOYEAUD  a écrit :


> Dans ce cas les bâtiments ont un élément d'adresse distinctif (souvent
> une lettre).
> Dans ce cas je suggère de faire un polygone qui prend l'ensemble de
> l'adresse et de faire les immeubles à l'intérieur avec chacun leur
> identification spécifique. Cela me semble logique.
>

C'est aussi comme ça que je procède.

Romain
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] OpenStreetMap vient d'atteindre la consécration ultime !

[Francescu GAROBY]

En effet, un vrai journal avec des vrais articles de QUALITAY vient de
décider d'utiliser OSM pour illustrer ces articles :
http://www.legorafi.fr/2014/05/19/decryptage-comprendre-le-festival-de-cannes-en-une-carte/

Moi, ça m'a bien fait sourire :-)

Francescu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenStreetMap vient d'atteindre la consécration ultime !

[Pieren]

2014-05-19 14:12 GMT+02:00 Francescu GAROBY :
> En effet, un vrai journal avec des vrais articles de QUALITAY vient de
> décider d'utiliser OSM pour illustrer ces articles :

Faux site d'info mais vrai carte (et en plus, ils respectent la license, eux)

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenStreetMap vient d'atteindre la consécration ultime !

[Francescu GAROBY]

Mon propos sur le vrai journal et ses "infos de qualitay" se voulait bien
évidemment ironique (mais je pars du principe que tout le monde connait Le
Gorafi, maintenant)

Francescu


Le 19 mai 2014 14:17, Pieren  a écrit :

> 2014-05-19 14:12 GMT+02:00 Francescu GAROBY :
> > En effet, un vrai journal avec des vrais articles de QUALITAY vient de
> > décider d'utiliser OSM pour illustrer ces articles :
>
> Faux site d'info mais vrai carte (et en plus, ils respectent la license,
> eux)
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cordialement,
Francescu GAROBY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Tyndare]

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


Le 18 mai 2014 17:21, Vincent de Château-Thierry  a écrit :
>
> Le 18/05/2014 16:55, Arnaud Vandecasteele a écrit :
>
>>
>> Je fais mes 1ers pas avec la nouvelle couche de données BANO.
>> Tout d'abord un grand merci pour le travail accompli, c'est vraiment une
>> grosse aide pour la saisie.
>>
>> Avant de commencer à ajouter massivement des adresses, je viens prendre
>> quelques conseils sur la bonne manière de faire cela.
>> Les premiers tests que j'ai fait avec l'interpolation d'adresse sont içi:
>> https://www.openstreetmap.org/way/282712144
>>
>> Quelques points qui me gênent:
>> 1/ Le nom de la rue doit-il être sur la ligne d'interpolation ou sur le
>> point ?
>> 2/ Pourquoi saisir manuellement le nom de la rue (addr:street), plutôt
>> que de faire une relation avec celle-ci ?
>>  Ca éviterait la double saisie et surtout en cas de changement de
>> nom de rue on garde une cohérence
>
>
> Sur les questions ci-dessus, je te suggère de changer complètement ton fusil
> d'épaule, et de ne pas te lancer dans de l'interpolation. BANO s'appuie sur
> ce service :
> http://cadastre.openstreetmap.fr/?type=adresses
> dont tout le propos est de fournir des fichiers .osm d'adresses _unitaires_
> à intégrer. On peut donc oublier l'interpolation : chaque adresse sera
> positionnée (potentiellement) à sa vraie situation, et non pas sur une
> abscisse curviligne.
>
> Un peu de lecture là-dessus en relation avec le service :
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_adresses
>
>
>> 3/ Doit on dessiner l'adresse sur le building ou devant celui-ci ?
>
> Vaste débat, pour l'instant chacun pratique selon ses préférences, mais on
> gagnerait à unifier.
>
> vincent
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[V de Chateau-Thierry]

> De : "Tyndare"
>
> 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. 

J'ai réagi à la question d'Arnaud car il pointait une zone où on est capable de 
proposer
des fichiers d'adresses unitaires à intégrer. Je trouve vraiment dommage dans 
ce cas là
de prendre le temps de modéliser une interpolation : c'est qualitativement 
moins riche et
à peine moins fastidieux.
Après, que les interpolations restent nécessaires, c'est possible. Mais je vois 
vraiment
ça comme une solution de repli, pas quelque chose à promouvoir en premier lieu.
Tu soulèves le problème de l'absence de contributions sur une zone, et c'est un 
des
moteurs pour l'initiative BANO actuelle : comme on n'a pas la masse critique de
contributions nécessaires pour proposer dans un délai raisonnable toutes les 
adresses par
extraction d'OSM, on construit une alternative qui se veut complémentaire d'OSM 
et 
vertueuse vis-à-vis du projet. Là où je veux en venir, c'est qu'à un endroit où
personne n'a contribué en 10 ans, au moins aucun 'local', je pense que le débat 
n'en est
pas à : interpolation ou adresses unitaires. On part (hélas) d'un peu plus 
loin. Et
ensuite, quitte à consacrer du temps de contribution sur les adresses, autant 
le faire
sur les adresses unitaires, au moins là où le cadastre est vectoriel. 
L'interpolation
est peut-être notre plan B à activer sur les communes en cadastre raster.

vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[JB]

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Identité et cycle de vie de l'adresse

[Jean-Marc Liotier]

Le rapport final du Groupe de Travail Adresses de 2002 mentionne le cas 
du Danemark: "l'analyse faite dans ce pays a montré que la solution 
pouvait être de changer le statut de l'adresse dans ces bases de 
données, qui est celui d'un attribut, pour en faire une entité 
individuelle". Faire de l'adresse une entité plutôt qu'un attribut est 
indispensable à gérer son cycle de vie... Mais alors qui gère le cycle 
de vie de l'objet adresse et génère cette clé primaire ? Les 
collectivités locales et autres organismes publiant des adresses ?


Les contributeurs Openstreetmap ne feront-ils que choisir pour chaque 
adresse la meilleure source parmi celles importées dans la BANO, en 
l'enrichissant d'attributs et d'une position éventuellement plus 
précise, en conservant l'identifiant d'origine comme clé étrangère ? 
C'est ce que me semble suggérer le rapport du Groupe de Travail Adresses 
de l'AFIGéo de 2011 - si je l'ai bien compris, mais où en est 
aujourd'hui cette réflexion ?


Des collègues ont évoqué l'hypothèse d'un code hiérarchique 
INSEE+FANTOIR+N° - mais je crois que c'est toujours dangereux d'utiliser 
une clé primaire signifiante, d'autant que la diversité des adresses que 
le projet BANO envisage de prendre en compte est beaucoup plus grande 
que ce modèle. HEXACLE a été mentionné mais de mon point de vue, 
l'utilisation d'un identifiant issu d'une source ouverte est impérative 
- ce qui l'exclut.


A part ça, le rapport du Groupe de Travail Adresses de l'AFIGéo de 
2011**dit "Un profil français du modèle de l'Adresse dans le cadre de la 
mise en oeuvre d'INSPIRE devra être préconisé" - ce chantier a-t-il 
avancé depuis par ailleurs ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trouver les noeuds non rapportés à un bâtiment avec JOSM

[Christian Quest]

Le 19 mai 2014 11:38, Pieren  a écrit :

> 2014-05-17 0:36 GMT+02:00 Christian Quest :
>
> > 1) pour tout ce qui est calcul d'itinéraires et positionnement de données
> > opendata ne contenant qu'une adresse on va très très prochainement
> pouvoir
> > géocoder en s'appuyant sur BANO
>
> 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.


Non, openaddresses.io ne s'affranchit pas des "problèmes" de licence.
openaddresses.io n'est qu'un catalogue, qui répertorie les sources
d'adresses. Ce catalogue est en CC0 (il me semble), mais les données des
différents dataset ont chacun leur licence propre.


> Ca
> nous fait donc déjà deux bases adresses "libres".
>

Pareil... openadresses.io ne contient aucune adresse, juste la liste des
fichiers adresses disponibles ic ou là (comme ceux de BANO).



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


Il n'est pas possible de mettre à jour BANO autrement que via OSM.
Le problème des mise à jour parallèles n'est donc pas un problème pour BANO.



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


Bien sûr qu'il faut les surmonter et rapidement... pour permettre
l'amélioration des données OSM et par ricochet de BANO.
L'idée est vraiment de faire d'une pierre deux coups.

L'intérêt est surtout d'avoir une base d'adresses utilisable immédiatement,
en complément d'OSM, pour aider à compléter OSM.
Ca évite qu'on se rue bêtement sur les adresses pour les importer à la
va-vite dans OSM (je l'ai fait dans quelques communes et en fait ma valeur
ajoutée a été très limitée) pour atteindre une masse critique nécessaire à
beaucoup d'usages sans apporter grand chose en terme de qualité, de
contrôle de terrain et autre.

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Christian Quest]

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 (c)(R)(tm)).



Le 19 mai 2014 18:06, JB  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@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Identité et cycle de vie de l'adresse

[Christian Quest]

A ma connaissance, il ne s'est pas passé grand chose depuis le rapport du
GT Adresse de l'Afigéo.

Des contacts sont à reprendre de ce côté car je pense que c'est là qu'on
aura le plus d'écoute et d'intérêt pour la BANO.

Pour l'instant l'ID utilisé dans BANO est justement composé de
INSEE+FANTOIR+N°

L'HEXACLE n'est pas libre (actuellement). S'il le devient il faudra
l'intégrer.



Le 19 mai 2014 18:32, Jean-Marc Liotier  a écrit :

>  Le rapport final du Groupe de Travail Adresses de 2002 mentionne le cas
> du Danemark: "l'analyse faite dans ce pays a montré que la solution pouvait
> être de changer le statut de l'adresse dans ces bases de données, qui est
> celui d'un attribut, pour en faire une entité individuelle". Faire de
> l'adresse une entité plutôt qu'un attribut est indispensable à gérer son
> cycle de vie... Mais alors qui gère le cycle de vie de l'objet adresse et
> génère cette clé primaire ? Les collectivités locales et autres organismes
> publiant des adresses ?
>
> Les contributeurs Openstreetmap ne feront-ils que choisir pour chaque
> adresse la meilleure source parmi celles importées dans la BANO, en
> l'enrichissant d'attributs et d'une position éventuellement plus précise,
> en conservant l'identifiant d'origine comme clé étrangère ? C'est ce que me
> semble suggérer le rapport du Groupe de Travail Adresses de l'AFIGéo de
> 2011 - si je l'ai bien compris, mais où en est aujourd'hui cette réflexion ?
>
> Des collègues ont évoqué l'hypothèse d'un code hiérarchique
> INSEE+FANTOIR+N° - mais je crois que c'est toujours dangereux d'utiliser
> une clé primaire signifiante, d'autant que la diversité des adresses que le
> projet BANO envisage de prendre en compte est beaucoup plus grande que ce
> modèle. HEXACLE a été mentionné mais de mon point de vue, l'utilisation
> d'un identifiant issu d'une source ouverte est impérative - ce qui l'exclut.
>
> A part ça, le rapport du Groupe de Travail Adresses de l'AFIGéo de 2011 dit
> "Un profil français du modèle de l'Adresse dans le cadre de la mise en
> oeuvre d'INSPIRE devra être préconisé" - ce chantier a-t-il avancé depuis
> par ailleurs ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Tyndare]

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

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Christian Quest]

Le 19 mai 2014 19:28, Tyndare  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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Jérôme Amagat]

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  a écrit :

>
> Le 19 mai 2014 19:28, Tyndare  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@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Tyndare]

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

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Format FANTOIR (was: Re: Correction de noms de voie pour jointure BANO)

[Ralf Treinen]

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Format FANTOIR (was: Re: Correction de noms de voie pour jointure BANO)

[Christian Quest]

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  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@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trouver les noeuds non rapportés à un bâtiment avec JOSM

[Marc Sibert]

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 > 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@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr




--
Marc Sibert
m...@sibert.fr 



--
Marc Sibert
mailto:m...@sibert.fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Lot Talk-fr, Vol 94, Parution 98

[dom bertho]

___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



--

Message: 2
Date: Mon, 19 May 2014 19:51:05 +0200
From: Christian Quest 
To: Discussions sur OSM en français  
Subject: Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Le 19 mai 2014 19:28, Tyndare  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 
To: Discussions sur OSM en français  
Subject: Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer
Message-ID:

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  a écrit :

>
> Le 19 mai 2014 19:28, Tyndare  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@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 
To: Discussions sur OSM en français  
Subject: Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer
Message-ID:

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  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 
To: Discussions sur OSM en français  
Subject: [OSM-talk-fr] Format FANTOIR (was: Re: Correction de noms de
voie pour jointure BANO)
Message-ID: <20140519190131.ga13...@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

Re: [OSM-talk-fr] Trouver les noeuds non rapportés à un bâtiment avec JOSM

[Philippe Verdy]

Le 19 mai 2014 10:33, Pieren  a écrit :

> Il n'y a qu'un seul name "official", c'est celui défini
> par la mairie

Ceci est faux, les mairies utilisent couramment des noms dérivés plus ou
moins adapté à leurs communication.

Le nom officiel est celui figurant dans l'arrêté préfectoral après
approbation par le conseil municipal et qui en fait une personne morale
munie d'une identité officielle en tant que collectivité. Ce nom figure
alors que les documents officiels de nature contractuelle (commes les
publications pour les appels d'offre de marchés publics, ou le nom qui sera
utilisé en justice et sur les PV officiels de conseils municipaux, ou
encore le nom du titulaire des compte dans les banques publiques ou
privées, les actes notariés d'acquisition ou vente pour le domaine public
communal; les actes de préemption sur les ventes privées...).

Cependant ce n'est pas non plus parce qu'une commune change de nom officiel
que tous les documents officiels passent du jour au lendemain au nouveau
nom, les anciens écrits restent valables dans la mesure où la dissolution
de l'ancienne personne morale voit ses droits et obligations transférés à
la nouvelle entité (ceci inclut les comptes bancaires, dettes, marchés
publics en cours de livraison ou de présélection...)

Ce qui fait qu'il peut parfaitement à un instant donné y avoir plusieurs
noms officiels (même s'il y en a un préféré pour tous les nouveaux actes)

Les autres étant encore détenus comme des marques, dans la limite des
encours et tant que la commune ne demande pas le dépôt officiel d'une
marque protégée sur son nom dans les domaines intéressant la commune; ce
que les communes n'oublient plus de faire aujourd'hui, mais qui peut sinon
les obliger à utiliser et faire protéger un autre nom en cas de conflit
avec une marque déposée par un autre titulaire : on a déjà cité l'exemple
des appellations d'origines, des couteaux Laguiole qui protègent une
douzaine des domaines possibles de protection contre la vingtaine de
domaines habituellement utilisés par les communes)

Ensuite la mairie peut communiquer ou faire de la publicité, de la
promotion touristique en utilisant d'autres noms tant qu'elle dipose aussi
des droits sur ces noms (y compris adaptés à des langues régionales ou
étrangères), et même afficher ces noms sur la voie publique. aucun problème
non plus sur la signalisation sur la voie publique, les parutions
publicitaires dans la presse (hors avis officiels), la revue d'info
municipale (on trouvera le nom officiel dans le petit encadré à l'intérieur
des informations éditeur)...

Mais une commune peut être empêchée de communiquer sur son propre nom dans
certaines autres territoires, même en France où peuvent exister des
homonymies dans la même zone de protection des marques déposées.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr