[OSM-talk-fr] Rapprochement Bano

[Christian Quest]

Le 27 octobre 2017 à 04:56, Francois Gouget <fgouget at free.fr> a écrit :

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

Le rendu BANO permet de se faire une très bonne idée dans la majorité des
cas.


  A-t-on une idée du temps que vont prendre les 160000 dernières voies
> ? Si elles restent c'est qu'il n'y a pas de contributeur dans ces
> villes ?
>

Le rythme s'est pas mal ralentit ces derniers temps. Si on s'y remet
sérieusement comme au début de la dispo de BANO, ces 160.000 voies peuvent
quasi disparaitre d'ici un an. Bien sûr, il y aura un résidu qui résistera
sur les cas tordus et particuliers qui nécessitent d'aller sur le terrain.


  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 ;-)
>
>
Le mieux c'est un peu plus d'adresses et peut être un meilleur calage
géographique.

* En l'absence d'import massif alors on continue avec une intégration
> manuelle qui prendra 10 à 15 ans.
>

L'import massif n'est pas souhaitable de mon point de vue ou alors c'est
qu'on privilégie la quantité à la qualité, et je ne suis pas pour.

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

Ouille... tout comme un bâtiment n'a pas de lien 1/1 avec une adresse, un
commerce n'a pas de lien 1/1 non plus.
Il est préférable de mettre son adresse en contact:*=*, l'adresse est un
objet à part entière.

Ces adresses en contact:* sont de toute façon exploitables si on en a
besoin, mais au moins on sait que ce n'est pas l'adresse elle même qu'on a
renseigné.


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

J'avais commencé comme ça sur ma commune, avec des interpolations. A
l'époque le plan cadastral était en image et pas vectoriel.
J'ai ensuite remplacé ces interpolations par les points adresse (toujours à
partir du plan image).

Qu'on ajoute les points ou qu'on mette des interpolations, la question
reste la source: terrain ou pas, donc amélioration/contrôlé ou juste copie
d'une source (le cadastre dans la majorité des cas).

  - 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.
>
>
Il faudrait des photos latérales... or c'est souvent des photos frontales
qui sont prises et versées et oui, ça prend un temps fou.


* 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.
>
>
Non, ce n'est pas du code spécifique pour la France, c'est du code
spécifique pour les adresses en général.

Nominatim par exemple n'utilise pas que les données OSM, des données sont
aussi ajoutées directement pour les compléter (adresses de Tiger et autre
il me semble).

Ce sujet des adresses n'est pas particulier qu'à la France, c'est général.
Il y a très peu de pays qui ont une couverture en adresses suffisantes dans
OSM pour que ce soit la seule source, c'est l'exception et pas la règle,
alors qu'il y a de plus en plus de bases d'adresses disponibles en opendata.

https://openaddresses.io/ répertorie toutes ces sources pour que justement
les appli et services qui ont besoin d'adresses au delà de ce qui est dispo
dans OSM pousse les utiliser.

Une appli ou un service qui dépend des adresses ne peut pas faire l'impasse
d'utiliser ces sources.

C'est pas parce que ces sources sont disponibles qu'il faut les importer
avec précipitation, car on n'apporte aucune valeur ajoutée vu qu'on peut
déjà les utiliser si on en a besoin. Faisons les choses bien, même si ça
prendra beaucoup de temps.

Les copier/coller en aveugle de données, surtout dans ce domaine, c'est ce
qui fait que même les bases officielles n'ont vraiment pas la qualité qu'on
pourrait attendre. Ne faisons pas la même erreur.

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