[OSM-talk-fr] Re : Rapprochement Bano

2017-10-26 Par sujet Francois Gouget 
Le jeudi 26 octobre 2017 à 10:45 +0200, Christian Quest a écrit :
> Les applis qui ont besoin d'adresses peuvent utiliser celles d'OSM et
> compléter avec d'autres sources (BANO en est une).
[...]
> On va aussi pouvoir bien mieux exploiter les données du cadastre dans
> un avenir très proche, vu qu'on a accès depuis quelques semaines aux
> données EDIGEO brutes. Donc je patienterai un peu pour voir ce qu'on
> peut faire de mieux que ce qui a été fait jusque maintenant avec les
> extractions faites uniquement à partir de fichiers PDF sur
> cadastre.gouv.fr

Donc ce que je retiens :
* Priorité aux noms de rues.
  Tout à fait d'accord. Mais c'est pas évident de contribuer si on
n'est pas sur place. Quelles sont vos techniques ?
  A-t-on une idée du temps que vont prendre les 16 dernières voies
? Si elles restent c'est qu'il n'y a pas de contributeur dans ces
villes ?
  Enfin, si on arrive effectivement au bout de cet aspect, je pense que
ça a du sens de revisiter comment va s'organiser la suite.

* Attendre voir si on peut mieux faire avec le nouveau cadastre.
  Mieux = import massif ? Points "adresse manquante" dans Osmose ? (20
millions de points ça va être joli ;-)

* En l'absence d'import massif alors on continue avec une intégration
manuelle qui prendra 10 à 15 ans.
  Peut-on déveloper des stratégies pour maximiser le rendement des
efforts d'intégration ?
  - Par exemple si un contributeur ajoute un commerce / restaurant et
pointe vers son site web, il aura probablement vu son adresse quelque
part. Donc on pourrait recommander l'ajout de l'adresse dans les pages
Wiki de amenity, shop et office. Mais cela fera quelques rues
commerçantes avec plein d'adresses et pas grand chose ailleurs.
  - Ajouter les adresses aux intersections. Je pense qu'avoir ces
données dans OSM serait presque suffisant pour les usages courants.
Mais pour un contributeur ce n'est pas le cas le plus simple à traiter
: à chaque fois la question se pose de savoir sur quelle rue est le
numéro. Aussi, un contributeur gagne-t-il en temps à se concentrer sur
les intersections ?
  - Ajouter une adresse par rue bordant un paté de maison. Là on évite
le problème des intersections mais on répond un peu moins bien à la
question "je tourne à droite ou à gauche ?".
  - Se concentrer sur les rues couvertes par Mapillary. Ca permet de
gagner du temps et de couvrir une zone plus étendue en évitant d'avoir
à aller sur place. Mais la couverture Mapillary est très loin d'être
complète mais j'ai l'impression qu'assez peu de numéros sont lisibles
et donc si je compte le temps passé à chercher une image où un numéro
est lisible je ne suis pas sûr que le rendement soit si bon.

* Les outils peuvent s'appuyer sur la BANO.
  Si on table sur une intégration qui prend 10 ans ou plus alors
effectivement les outils ont plutôt intérêt à ajouter du support pour
la BANO afin d'être utilisables. Mais dans ce cas il faudrait les en
informer clairement.
  Ca veut aussi dire qu'ils devront intégrer du code spécifique pour la
France, soit au niveau de l'outil même, soit au niveau de la
préparation des fichiers OSM qu'ils utilisent en faisant leur propre
'import massif' de la BANO.

-- 
Francois Gouget 

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

Re: [OSM-talk-fr] Rapprochement Bano

2017-10-26 Par sujet Romain MEHUT 
Le 26 octobre 2017 à 11:16, marc marc  a écrit :

>
> Pour les numéros de bâtiments il y a 5 méthodes :
>

Partant de ce principe, c'est déjà mal parti pour avoir un consensus. Comme
Christian l'a à nouveau rappelé, adresse et bâtiment sont deux notions
différentes.

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

Re: [OSM-talk-fr] Rapprochement Bano

2017-10-26 Par sujet Romain MEHUT 
Le 26 octobre 2017 à 10:40, Nicolas Moyroud  a écrit :

>
> Je fais en général attention à bien marquer local_survey comme source de
> ceux que j'ai vérifié sur place.
>

Juste la valeur "local_survey" n'est pas documentée dans le wiki. Il s'agit
de "survey" tout simplement.

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

Re: [OSM-talk-fr] fin d'une route secondaire ou tertiaire vers un hameau

2017-10-26 Par sujet marc marc 
Le 12. 10. 17 à 22:43, Stéphane Péneau a écrit :
 > De mon point de vue, ce ne sont pas des _link.

comment les taguerais-tu ?
en sachant que même sans link, osmose rapporte une anomalie si une 
tertiaire s'arrête sans connexion vers une route de classe semblable
ou supérieur.

> Le 12/10/2017 à 22:49, David Crochet a écrit : >> un rond point doit être 
> catégorisé parla catégorie la plus 
importante des routes y accédant ou y partantexact selon moi, mais le 
problème se pose aussi sans rond point.
ceci dit, la correction du rond-point permettrait d'éviter la fin
de la route tertiaire vu que le rond-point se boucle sur lui-même.

Le 13. 10. 17 à 07:05, Stéphane Péneau a écrit :
 > si on considère qu'une
 > highway=trunk est une route pour automobile, ce qui entraine une
 > interdiction de circulation pour certains modes de transport, alors le
 > giratoire ne doit pas aussi être en trunk.

Je n'ai jamais vu de trunk qui finissent sur un rond point.
tout ceux que je connaisse finissent avant le rond point vu qu'un trunk 
ne peux pas avoir de carrefour et a une borne centrale que je n'ai 
jamais vu présente jusqu'au rond point

donc en simplifiant. d'un côté une route tertaire, de l'autre une route 
unclassified. comment relie-t-on la fin de l'un à l'autre ?
connexion direct et connexion avec un _link intermédiaire sont toutes 
les 2 erronée selon osmose
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] corrections Osmose et rues sans nom

2017-10-26 Par sujet marc marc 
Dans ces cas là, il faut ouvrir les tickets pour les apps
sinon le problème va se reproduire

J'ai ouvert un ticket osmose
https://github.com/osm-fr/osmose-backend/issues/239

et un pour StreetComplete
https://github.com/westnordost/StreetComplete/issues/663

Le 19. 10. 17 à 22:42, Jérôme Seigneuret a écrit :
> Bonjour, pour info c'est réglé. Par contre une alerte osmose sur des 
> termes incohérents comme ça peut être utile. J'en avait déjà parlé et il 
> me semble que c'est déjà pris en charge pour parti (conditionnel donc à 
> vérifier).
> 
> J'ai fait cette propos dans le changeset.
> 
> Jérôme
> 
> Le 19 octobre 2017 à 21:28,  > a écrit :
> 
> Bonjour,
> 
> modifications automatiques, aidées ou manuelles, on se pose souvent
> la question.
> 
> J'étais parti d'une recherche de Sans Nom (un ancien nom de
> Marseille, la Ville Sans Nom) et suis tombé sur nombre de Sans Nom.
> 
> S'il peut y avoir des rues ,villes etc.. nommées "Sans Nom" il
> s'agit souvent de la volonté du cartographe de dire que la rue par
> exemple n'a pas de nom, ce qui se décrit avec noname=yes et
> l'absence de tags name*.
> 
> Je suis tombé sur des corrections Osmose où des personnes ont
> "corrigé" des "sans nom" en "Sans Nom".
> 
> C'est un peu le risque des corrections automatiques : on peut en
> faire qui abiment plus qu'elles ne corrigent.
> 
> Car une rue "sans nom" est assez évidemment une rue noname=yes, pour
> une rue Sans Nom c'est déjà moins évident.
> 
> Regardez comment une simple question peut améliorer la carte :
> 
> https://www.openstreetmap.org/changeset/38086717#map=19/43.15773/-0.39276
> 
> 
> 
> À l'opposé comment StreetComplete peut dégrader la carte en ajoutant
> de l'information pertinente... mal :
> 
> https://www.openstreetmap.org/changeset/49440578#map=18/47.28462/2.57830
> 
> 
> À vos claviers !
> 
> Fred, peut-on proposer de corriger les sans nom non en Sans Nom mais
> en noname=yes ? Ou laisser le choix ?
> 
> Jean-Yvon
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> 
> 
> -- 
> Cordialement,
> Jérôme Seigneuret
> 
> 
> ___
> 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] Rapprochement Bano

2017-10-26 Par sujet gergero 

Bonjour,

(Excusez-moi, si cette question n’apparait pas au bonne endroit - c'est 
mon 1èr message sur cette liste.)


J'ai une question par rapport aux données suivantes :

> (Message de Christian Quest Mer 25 Oct 13:55:58 UTC 2017 :)

> "Pour les points en violet, ce sont des adresses issues des fichiers du
> cadastre désormais en opendata. C'est un peu expérimental, mais ça peut
> être utile."

Comment retrouver les données/fichiers à l'origine de ces adresses 
(points en violet) ?





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

Re: [OSM-talk-fr] Rapprochement Bano

2017-10-26 Par sujet Vincent de Château-Thierry 
Bonjour,

> De: "Philippe Verdy" 
> 
> En bref, BANO est un "aggrégateur" de données, dont les sources sont
> OSM, la BAN, et d'autres bases ouvertes en OpenData des
> collectivités locales ou de certaines entreprises. 

Non on ne peut pas dire que la BAN alimente BANO. Mais BANO, comme la BAN, va 
puiser dans le Cadastre. Le Cadastre (source DGFip) ainsi que le fichier 
FANTOIR sont des sources majeures pour BANO.

> BANO a donc sa vie propre, c'est le meilleur de tous les mondes
> actuels concernant la France (donc meilleur qu'OSM ou la BAN
> utilisés seuls).

Il y a 2 facettes dans BANO...
* Initialement l'idée était bien d'agréger plusieurs sources de données pour 
constituer le meilleur référentiel d'adresses sur la France, à disposition du 
plus grand nombre. L'idée reste, évidemment, mais depuis le paysage a changé : 
l'initiative BAN a enfin émergé, titillée par BANO après des années de sommeil. 
Pour autant, comme l'a rappelé Christian, le contenu issu de BANO est bien 
disponible, et rafraîchi chaque nuit. La BAN n'a pas encore atteint une 
envergure et un rythme de mise à jour qui videraient le contenu BANO de son 
intérêt.
* La seconde facette est finalement la plus importante je pense, vue du côté 
OSM : le coup de projecteur sur la thématique Adresses impulsé par BANO a 
permis l'émergence de quelques outils d'aide à la contribution OSM : par 
exemple le rendu cartographique et la page de comparaison Fantoir par commune. 
On pensait initialement focaliser notre énergie sur les adresses elles-mêmes 
(les numéros) et comme Christian l'a redit, c'est essentiellement sur les noms 
de voies que l'accent a été mis. C'est là que la balance entre temps passé et 
valeur ajoutée aura été la plus équilibrée, au final profitable pour OSM. 

On a parlé dans ce fil d'import d'adresses. Si la finalité est de disposer de 
toutes les adresses connues de BANO dans une application consommant par 
ailleurs le contenu OSM, un import brut n'a pas de sens. Autant utiliser OSM 
sans les adresses d'une part, et ajouter les adresses BANO d'autre part. La 
vraie valeur ajoutée n'est pas dans l'import, voué à l'échec en terme de 
maintenance compte tenu du volume (autour de 20 millions d'adresses) et du 
nombre de contributeurs capables d'y consacrer du temps. Parlons plutôt 
d'intégration, à savoir un processus manuel, long, requérant souvent un passage 
sur le terrain car les adresses sont tout sauf une matière simple : exceptions, 
cas tordus, contradictions... reparlons-en quand OSM disposera en France d'un 
contributeur par (communauté de) commune(s), là oui ;)

> (...) Si d'autres
> collectivités publiques se joignent à la BAN, on pourra les exclure
> en tant que source pour BANO puisque ce sera fait dans BAN (et donc
> économiser plein de signalements inutiles liés tous aux différences
> existant encore entre les sources). La BAN en revanche ne rapproche
> pas encore les éléments extraits du cadastre (mais BANO le fait).

Non, il ne s'agit pas de déshabiller BANO au fur et à mesure de la constitution 
de la BAN. Il faut considérer que BANO a sa vie propre, et reste une 
alternative à la BAN, comme dit plus haut.

vincent

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

Re: [OSM-talk-fr] Rapprochement Bano

2017-10-26 Par sujet Philippe Verdy 
Le 26 octobre 2017 à 11:56, Christian Quest  a
écrit :

> Vu la diversité de modélisation des adresses dans OSM (pas qu'en France),
> c'est là aussi que BANO est utile car ça remet tout ça sous une unique
> forme simple et un réutilisateur ayant besoin d'adresses devrait plutôt
> regarder de ce côté (pour la France) que de se prendre la tête avec la
> donnée OSM brute car il faut prendre en compte ces cas, mais aussi la
> hiérarchie administrative, les relations boundary=administrative, les codes
> postaux, etc...
>

En bref, BANO est un "aggrégateur" de données, dont les sources sont OSM,
la BAN, et d'autres bases ouvertes en OpenData des collectivités locales ou
de certaines entreprises. Il tente ensuite des rapprochements entre ces
sources, et dresse une carte statistique destiné à comparer les sources,
mais cette carte n'est pas un outil d'import en tant que tel, juste un état
des lieux du rapprochement et des progrès restant à faire dans chacune des
sources utilisées par BANO et des différences significatives trouvées.

Pour le reste c'est à chaque source de trouver en elle-même un chemin
d'accord permettant un rapprochement satisfaisant (le critère de
rapprochement peut évoluer encore avec des seuils de différence abaissés,
aussi bien pour la géolocalisation que la topoynymie). Le travail reste à
faire pour OSM afin de le mettre progressivement en accord avec les autres
sources de la BANO.

BANO a donc sa vie propre, c'est le meilleur de tous les mondes  actuels
concernant la France (donc meilleur qu'OSM ou la BAN utilisés seuls).

La BAN est un autre projet séparé de rapprochement entre certains acteurs
de missions de service public. Lui aussi fait des rapprochements mais pas
avec OSM ni avec toutes les bases OpenData. Je ne pense pas que ce soit la
mission de BANO de refaire lui-même le rapprochement déjà fait et géré par
la BAN gouvernementale, donc BANO n'a pas besoin d'utiliser les sources
comme La Poste puisque cela fait déjà partie du rapprochement dans la BAN.
Si d'autres collectivités publiques se joignent à la BAN, on pourra les
exclure en tant que source pour BANO puisque ce sera fait dans BAN (et donc
économiser plein de signalements inutiles liés tous aux différences
existant encore entre les sources). La BAN en revanche ne rapproche pas
encore les éléments extraits du cadastre (mais BANO le fait).

Ceci dit, BANO produit aussi des données à destination des acteurs de la
BAN publique et notamment les données présentes dans OSM mais pas encore
(ou plus) dans la BAN ou ayant de grosses différences de position ou de
nom. Pour cela il s'appuie sur un outil de signalement, commune par
commune, pour le moment au niveau des voies et lieux-dits (mais pas encore
pour les adresses)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rapprochement Bano

2017-10-26 Par sujet Christian Quest 
Le 26 octobre 2017 à 11:16, marc marc  a écrit :

> Bonjour,
>
> Christian quand tu dis que Bano agrège différentes sources d'adresse
> opendata dont osm, comment a l'inverse les outils utilisent bano ?
>

ça, c'est à chaque outil qu'il faut poser la question...


> est-ce que nominatim ou un app utilise bano ?
>

A ma connaissance Nominatim n'utilise pas BANO.

D'autres apps l'utilisent peut être, on n'a pas de moyen simple de le
savoir, tout comme l'usage de données OSM par des applis d'une façon
générale.



> ou cela reste une superbe base composite mais utilisée uniquement
> pour l'édition manuelle d'som ?
>
>
Pas que vu le nombre important et régulier de téléchargements des données
sur bano.openstreetmap.fr
J'ai du mal à imaginer que ces fichiers soient régulièrement téléchargés
pour ne pas être utilisés.
On les retrouve même sur des plateformes régionales, exemple:
https://geobretagne.fr/geonetwork/apps/georchestra/?uuid=9ffb161b-d8d8-4ec4-bde5-a03104300df8

Je peux au moins te dire ce que moi j'en fais:
- j'ai une instance du géocodeur addok qui permet d'interroger BANO:
bano.addok.xyz
- je l'utilise chaque mois pour compléter le géocodage de la base SIRENE,
car BANO contient les infos sur les lieux-dits alors que la BAN est très
incomplète de ce côté.
- j'ai mis en place un "meta-géocodeur" le week-end dernier qui permet en
une requête d'interroger BANO, BAN et les POI d'OSM: all.addok.xyz


Le 26. 10. 17 à 10:40, Nicolas Moyroud a écrit :
> > Mais ce n'était pas sur la question des sources de données que portait
> > la remarque de mon message précédent, plutôt sur la façon de modéliser
> > les adresses dans OSM en France : ajout du numéro comme tag du bâtiment,
> > sur un noeud isolé, ou sur un noeud attaché au contour du bâtiment.
> > Une recommandation qui permette de clarifier et d'homogénéiser les
> > pratiques serait la bienvenue !
>
> Malheureusement, il n'y a aucune harmonisation a ce sujet.
> Même la page qui renseigne LES différentes méthodes utilisées
> n'est pas suivie partout. En résumé :
> Pour les numéros de bâtiments il y a 5 méthodes :
> - mettre le tag sur le bâtiment
> avantage : est géré par "tous" les outils
> désavantage : ne convient pas en cas de numéro multiple sur un bâtiment,
> ou d'un numéro pour plusieurs bâtiment (une école par exemple)
> - mettre le tag sur l'entrée du bâtiment
> avantage : permet de gérer les bâtiments multi-numéro
> désavantage : non supporté par les apps genre maps.me ce
> qui conduit à créer des doublons et pire à des incohérences.
> - mettre le tag sur un chemin fermé représentant +- la parcelle
> ou sur un multipolygone
> avantage : permet de gérer le cas d'un numéro multi-bâtiments
> désavantage : peu supporté niveau apps
> - mettre le tag sur un nœud hors du bâtiment, parfois situé à l'endroit
> de la boite aux lettre, à la connexion du chemin privé avec la voie
> publique, à l'endroit de la plaque avec le numéro ou l'endroit d’où
> elle est visible.
> avantage : j'en ai pas trouvé :) hormis la simplicité à la création
> (pas besoin de réfléchir dans lequel des cas précédent on se trouve)
> désavantage : oblige les outils à faire de la devinette pour trouver
> la bâtiment concerné. devinette qui a donc un taux d'erreur.
> Vu qu'il n'y a aucun lien entre le nœud isolé et le bâtiment,
> cela conduit comme dans le cas précédent a des doublons
>
> pour les rues, il y a 2 méthodes :
> - mettre addr:street sur l'objet qui possède addr:housenumber
> avantage : supporté par toutes les apps
> désavantage : donnée dupliquée
> - créer une associatedStreet qui lie les numéros d'une rue avec la rue
> avantage : maintenance que je trouve plus cohérente (le marque les
> numéros avec une changeset source=survey, je fais l'associatedStreet
> avec source=bano ou source=extrapolation)
> - désavantage : support limité dans les apps
>
> pour addr:city addr:postcode addr:country, 2 méthodes :
> - les gérer par des zones boundary (mais faudrait améliorer leur
> prise en compte par les apps)
> - les ajouter sur l'objet qui possède addr:housenumber (avantage :
> géré par tous les outils, désavantage : données dupliquées)
>
> Le détail est là
> http://wiki.openstreetmap.org/wiki/FR:Adresses
> https://wiki.openstreetmap.org/wiki/Key:addr
>
> Mais ceci dit, autant je suis d'accord qu'il serrait utile de commencer
> l'import des numéros de bâtiments pour les cas simple (par exemple
> lorsque bano renseigne un numéro unique sur un bâtiment) vu qu'en
> l'absence de cet import, on "consomme" du temps humain pour le faire,
> autant je suis aussi d'accord qu'il est plus utile de commencer par
> renseigner toutes les rues d'une commune avant de traiter les numéros.
>


Vu la diversité de modélisation des adresses dans OSM (pas qu'en France),
c'est là aussi que BANO est utile car ça remet tout ça sous une unique
forme simple et un réutilisateur ayant besoin d'adresses devrait plutôt
regarder de ce côté (pour la France) que de se prendre la tête avec

Re: [OSM-talk-fr] Rapprochement Bano

2017-10-26 Par sujet marc marc 
Bonjour,

Christian quand tu dis que Bano agrège différentes sources d'adresse 
opendata dont osm, comment a l'inverse les outils utilisent bano ?
est-ce que nominatim ou un app utilise bano ?
ou cela reste une superbe base composite mais utilisée uniquement
pour l'édition manuelle d'som ?

Le 26. 10. 17 à 10:40, Nicolas Moyroud a écrit :
> Mais ce n'était pas sur la question des sources de données que portait 
> la remarque de mon message précédent, plutôt sur la façon de modéliser 
> les adresses dans OSM en France : ajout du numéro comme tag du bâtiment, 
> sur un noeud isolé, ou sur un noeud attaché au contour du bâtiment.
> Une recommandation qui permette de clarifier et d'homogénéiser les 
> pratiques serait la bienvenue !

Malheureusement, il n'y a aucune harmonisation a ce sujet.
Même la page qui renseigne LES différentes méthodes utilisées
n'est pas suivie partout. En résumé :
Pour les numéros de bâtiments il y a 5 méthodes :
- mettre le tag sur le bâtiment
avantage : est géré par "tous" les outils
désavantage : ne convient pas en cas de numéro multiple sur un bâtiment, 
ou d'un numéro pour plusieurs bâtiment (une école par exemple)
- mettre le tag sur l'entrée du bâtiment
avantage : permet de gérer les bâtiments multi-numéro
désavantage : non supporté par les apps genre maps.me ce
qui conduit à créer des doublons et pire à des incohérences.
- mettre le tag sur un chemin fermé représentant +- la parcelle
ou sur un multipolygone
avantage : permet de gérer le cas d'un numéro multi-bâtiments
désavantage : peu supporté niveau apps
- mettre le tag sur un nœud hors du bâtiment, parfois situé à l'endroit 
de la boite aux lettre, à la connexion du chemin privé avec la voie 
publique, à l'endroit de la plaque avec le numéro ou l'endroit d’où
elle est visible.
avantage : j'en ai pas trouvé :) hormis la simplicité à la création
(pas besoin de réfléchir dans lequel des cas précédent on se trouve)
désavantage : oblige les outils à faire de la devinette pour trouver
la bâtiment concerné. devinette qui a donc un taux d'erreur.
Vu qu'il n'y a aucun lien entre le nœud isolé et le bâtiment,
cela conduit comme dans le cas précédent a des doublons

pour les rues, il y a 2 méthodes :
- mettre addr:street sur l'objet qui possède addr:housenumber
avantage : supporté par toutes les apps
désavantage : donnée dupliquée
- créer une associatedStreet qui lie les numéros d'une rue avec la rue
avantage : maintenance que je trouve plus cohérente (le marque les 
numéros avec une changeset source=survey, je fais l'associatedStreet 
avec source=bano ou source=extrapolation)
- désavantage : support limité dans les apps

pour addr:city addr:postcode addr:country, 2 méthodes :
- les gérer par des zones boundary (mais faudrait améliorer leur
prise en compte par les apps)
- les ajouter sur l'objet qui possède addr:housenumber (avantage :
géré par tous les outils, désavantage : données dupliquées)

Le détail est là
http://wiki.openstreetmap.org/wiki/FR:Adresses
https://wiki.openstreetmap.org/wiki/Key:addr

Mais ceci dit, autant je suis d'accord qu'il serrait utile de commencer 
l'import des numéros de bâtiments pour les cas simple (par exemple 
lorsque bano renseigne un numéro unique sur un bâtiment) vu qu'en 
l'absence de cet import, on "consomme" du temps humain pour le faire,
autant je suis aussi d'accord qu'il est plus utile de commencer par 
renseigner toutes les rues d'une commune avant de traiter les numéros.

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

Re: [OSM-talk-fr] Rapprochement Bano

2017-10-26 Par sujet Christian Quest 
Les applis qui ont besoin d'adresses peuvent utiliser celles d'OSM et
compléter avec d'autres sources (BANO en est une).
Je rappelle aussi que BANO contient aussi les adresses présentes dans OSM
(mise à jour chaque nuit), ce qui simplifie la vie de ceux qui ont besoin
d'adresses qui n'ont du coup pas à refaire cette agrégation de sources.
BANO leur mâche le travail en agrégeant les adresses OSM, celles en
opendata et celles extraites du cadastre et en remettant tout ça au propre.

Quand on a démarré BANO, on s'est posé ces questions, et les tests
d'intégration d'adresses que j'ai fait à l'époque ont montré qu'il nous
faudrait au moins 10/15 ans pour tout intégrer dans OSM avec un minimum de
contrôle humain. Il suffit de voir qu'on n'a pas terminé les bâtiments,
alors que c'est plus simple à intégrer et qu'on a démarré en 2009 (et je ne
parle pas de la mise à jour).

Donc on a surtout poussé dès le départ à "dégommer du rouge", c'est à dire
avant tout à compléter les noms de rues manquantes dans OSM, car en plus ça
demande de l'intelligence humaine sans bien sûr empêcher ceux qui veulent
intégrer des adresses de la faire.
Donc si dans votre coin ajouter les adresses vous branche, n'hésitez pas...
mais pensez à dégommer le rouge si possible avant !

Le pire que j'ai vu, c'est l'import d'adresses, sans amélioration ou
contrôle... et sans avoir complété les noms des rues sur les highway voire
même sans highway du tout ! C'est typiquement ce qu'on a voulu éviter (et
qu'on a bien évité sauf très rares cas).

On va aussi pouvoir bien mieux exploiter les données du cadastre dans un
avenir très proche, vu qu'on a accès depuis quelques semaines aux données
EDIGEO brutes. Donc je patienterai un peu pour voir ce qu'on peu faire de
mieux que ce qui a été fait jusque maintenant avec les extractions faites
uniquement à partir de fichiers PDF sur cadastre.gouv.fr

Bien sûr, chacun est libre de contribuer comme il a envie, ce sont ici
juste des recommandations pour que le temps que nous passons tous à
contribuer soit le plus utile.
Globalement pour le projet OSM, pouvoir annoncer qu'un type de donnée est
"complet" comme on a pu le faire en 2012 quand on a terminé le découpage
communal est très positif.
En fléchant le "dégommage de rouge" comme prioritaire sur l'intégration des
adresses elles-même, on devrait pouvoir annoncer dans quelques mois que les
noms de rues sont "complets", alors que si on s'était dispersé sur les
adresses , je pense qu'on aurait mis quelques années de plus pour les noms
de rues ;)


Le 26 octobre 2017 à 09:51, Nicolas Moyroud  a écrit :

> Bonjour,
>
>> Mais quel est le plan pour les numéros ?
>> Parce que même si ils sont dans la BANO, ça ne m'aide pas lorsque je
>> cherche une adresse and Osmand, Maps.me ou autres.
>>
> 100% d'accord avec ça. L'argument "oui mais c'est déjà dans BANO" n'est
> pas à mon avis pas valable sur une liste qui concerne le projet OSM. En
> raisonnant comme ça on peut presque arrêter de contribuer à OSM en France,
> il y a déjà plein de données géographiques disponibles en OpenData un peu
> partout...
>
>> Et vu le temps que prend l'intégration des rues, une intégration
>> manuelle des numéros va prendre des décennies vu qu'il doit y avoir au
>> moins 10 fois plus de numéros.
>>
>> Mais sera-t-il possible de faire un import automatique ? Est-ce prévu ?
>>
>> Comment ça va se passer avec les adresses déjà présentes dans OSM ?
>>
> Il serait plus que temps de se demander comment on procède et quelles
> recommandations on propose pour l'intégration des numéros d'adresses dans
> OSM, plutôt que de reporter sans arrêt le problème à plus tard. Parce que
> là vu les chiffres indiqués par Donat on a presque fini le rapprochement
> des rues, donc il va falloir s'occuper avec autre chose dans pas longtemps
> ! ;-)
>
> Nicolas
>
>
> ___
> 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] Rapprochement Bano

2017-10-26 Par sujet Nicolas Moyroud 


Par chez moi, je n'ajoute des numéros que si j'ai au préalable fait un 
repérage sur le terrain (photos, etc..) S'il me manque certains 
numéros, et que ceux que j'ai vérifiés correspondent bien avec 
Bano/Cadastre, alors je complète avec ces sources.
Merci pour ces précisons. En ce qui me concerne j'ai plus tendance à 
faire confiance directement aux données BANO/Cadastre en intégration 
directe, avec des vérifications terrain quand c'est possible. Je fais en 
général attention à bien marquer local_survey comme source de ceux que 
j'ai vérifié sur place.
Mais ce n'était pas sur la question des sources de données que portait 
la remarque de mon message précédent, plutôt sur la façon de modéliser 
les adresses dans OSM en France : ajout du numéro comme tag du bâtiment, 
sur un noeud isolé, ou sur un noeud attaché au contour du bâtiment.
Une recommandation qui permette de clarifier et d'homogénéiser les 
pratiques serait la bienvenue !


Nicolas

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

Re: [OSM-talk-fr] Rapprochement Bano

2017-10-26 Par sujet Stéphane Péneau 

Le 26/10/2017 à 09:51, Nicolas Moyroud a écrit :
Il serait plus que temps de se demander comment on procède et quelles 
recommandations on propose pour l'intégration des numéros d'adresses 
dans OSM
Par chez moi, je n'ajoute des numéros que si j'ai au préalable fait un 
repérage sur le terrain (photos, etc..) S'il me manque certains numéros, 
et que ceux que j'ai vérifiés correspondent bien avec Bano/Cadastre, 
alors je complète avec ces sources.


Stéphane

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

Re: [OSM-talk-fr] Rapprochement Bano

2017-10-26 Par sujet Nicolas Moyroud 

Bonjour,

Mais quel est le plan pour les numéros ?
Parce que même si ils sont dans la BANO, ça ne m'aide pas lorsque je
cherche une adresse and Osmand, Maps.me ou autres.
100% d'accord avec ça. L'argument "oui mais c'est déjà dans BANO" n'est 
pas à mon avis pas valable sur une liste qui concerne le projet OSM. En 
raisonnant comme ça on peut presque arrêter de contribuer à OSM en 
France, il y a déjà plein de données géographiques disponibles en 
OpenData un peu partout...

Et vu le temps que prend l'intégration des rues, une intégration
manuelle des numéros va prendre des décennies vu qu'il doit y avoir au
moins 10 fois plus de numéros.

Mais sera-t-il possible de faire un import automatique ? Est-ce prévu ?

Comment ça va se passer avec les adresses déjà présentes dans OSM ?
Il serait plus que temps de se demander comment on procède et quelles 
recommandations on propose pour l'intégration des numéros d'adresses 
dans OSM, plutôt que de reporter sans arrêt le problème à plus tard. 
Parce que là vu les chiffres indiqués par Donat on a presque fini le 
rapprochement des rues, donc il va falloir s'occuper avec autre chose 
dans pas longtemps ! ;-)


Nicolas

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

Re: [OSM-talk-fr] Rapprochement Bano

2017-10-26 Par sujet Francois Gouget 
On Wed, 25 Oct 2017, Christian Quest wrote:
[...]
> Pour les numéros, si on a envie de les intégrer on peut le faire, mais 
> ça prend beaucoup de temps et il semble bien plus utile dans un premier 
> temps d'avoir déjà toutes les rues nommées. Pour ceux qui de toute façon 
> ont besoin d'utiliser une base d'adresses, les données de BANO sont là ;)

Mais quel est le plan pour les numéros ?
Parce que même si ils sont dans la BANO, ça ne m'aide pas lorsque je 
cherche une adresse and Osmand, Maps.me ou autres.

Et vu le temps que prend l'intégration des rues, une intégration 
manuelle des numéros va prendre des décennies vu qu'il doit y avoir au 
moins 10 fois plus de numéros.

Mais sera-t-il possible de faire un import automatique ? Est-ce prévu ?

Comment ça va se passer avec les adresses déjà présentes dans OSM ? 

Est-ce que les adresses déjà présentes posent problème pour un import 
automatique des numéros ?

Pourrait-on commencer l'import automatique des numéros pour les villes 
où toutes les rues ont été rapprochées ?

Faudrait-il recommander à ceux qui travaillent sur l'intégration des 
rues d'ajouter une adresse à chaque intersection ? Cela permettrait aux 
utilisateurs d'OSM de savoir à peu près à quel endroit se trouve leur 
destination, ou au moins de résoudre ce problème typique lorsqu'on 
arrive à une intersection en voiture : pour trouver le 42, dois-je 
tourner à droite ou à gauche ?


-- 
Francois Gouget   http://fgouget.free.fr/
  Any sufficiently advanced Operating System is indistinguishable from Linux___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr