[OSM-talk-fr] Proposition pour modifier l'article FR sur les adresses en france

[Philippe Verdy]

En gros, une décision germano-polonaise basée sur le manque de courage et
surtout pas la patience d'attendre que les outils soient à jour.

Pourtant ces outils fonctionnent bien maintenant en France, et il est
possible d'automatiser le transfert des données de points d'adresses vers
la bonne relation dans la quasi-totalité des cas (même s'il restera encore
des noeuds d'adresse isolés pas facile à regrouper dans une même relation
encore inexistante ou une ambiguité pour les adresses proches d'un
carrefour de voies avec un petit numéro.
tout ça peut se gérer dans un outil de suivi de qualité (comme Osmose, ou
autre) ou une tâche découpée par zone suivie (de type Maproulette).

Même en Allemagne ils utilisent de tels outils pour pas mal de choses, je
ne vois pas ce qui les décourage de le faire, sauf que pour l'instant ils
n'ont pas encore bien expliqué les choses et toujours pas vu que la
migration progressive est également possible pour les adresses (comme on le
fait en France).

S'il y a un réel facteur bloquant ce n'est pas celui-là mais sans doute une
confusion entre différents adressages (légal, cadastral, postal, indication
routière...) et qu'ils n'ont pas encore normalisé ça par des règles
suffisantes (donc leurs adresses sont encore ambiguës, ne sachant pas
encore bien discerner les choses ni convaincre tout le monde d'utiliser les
bon tags entre "addr:*" et "contact:*", une confusion qui existe encore
pour un certain nombre de contributeurs en France, mais qu'on explique
régulièrement ici).

Et pourtant c'est d'Allemagne que vient le schéma des adresses (addr:*),
dit schéma de Karlsruhe. Mais il est encore utilisé en Allemagne pour
différentes choses qui n'y sont pas liées (ou alors leur schéma est encore
insuffisant pour les cas qu'ils ont à traiter et distinguer)

En discuter ici, c'est bien, le documenter sur le wiki c'est mieux, mais
ensuite vient le problème des traductions du wiki (notamment dans les pays
multilingues). Et même pour documenter cela en français, attention au wiki
à bien indiquer ce qui s'applique à la France et pas la Belgique ou la
Suisse (qui sont multilingues et peuvent suivre alors des règles
contradictoires entre les langues, si elles ne mentionnent pas le pays
concerné, puisque la langue du wiki ne suffit pas).




Le mar. 16 févr. 2021 à 19:33, Yves P. <yves.pratter at gmail.com> a écrit :

> > Ce qui m'interroge, c'est la phrase suivante sur la page
> https://wiki.openstreetmap.org/wiki/Relation:associatedStreet !
> > "This method of mapping addresses is much less popular than addr:* and
> strictly unwanted in regions such as for example Germany and Poland."
> >
> > Sait-on pourquoi ce n'est pas  désiré en Allemagne ou Pologne ?
>
> Pour la Pologne aucune idée.
>
> Pour l'Allemagne, j'ai traduis les 24 messages de la première des 11 pages
> de la discussion qui a aboutit à l'abandon de la relation associatedStreet.
>
> Le constat à l'époque était que addr:street était mis sur toutes les
> adresses et que du coup la relation associatedStreet faisait doublon.
> De plus la majorité des relations ne semblait pas à jour.
> Du coup ils ont décidé de les supprimer.
>
> Mais en France, il y a peu de doublon à ma connaissance, et les relations
> sont plutôt bien maintenues.
> Ce qui est sûr c'est que nous avons BANO et de plus Vincent à développé un
> outil pour créer et maintenir les relations 😀
>
>
> > Je sais bien qu'on ne taggue pas pour le rendu, mais c'est quand même
> bien pratique les addr:* associé à un POI, par exemple dans un projet comme
> celui-ci, http://www.vracanantes.fr/, pour lequel s'affiche directement
> l'adresse récupérée depuis les attributs de la boutique affichée.
>
> C'est au projet d'extraire les données.
>
> Il peut faire une requête auprès du géocodeur pour obtenir l'adresse
> complète lors du click sur le POI, ou en amont.
>
> Par exemple pour Le Comptoir d'Aurélie <
> https://www.openstreetmap.org/node/346983082#map=19/48.10174/-3.99981>,
> la recherche avec ses coordonnées avec addock <
> https://demo.addok.xyz/reverse?lat=48.10174&lon=-3.99981&type=housenumber>,
> renvoi 3 Grande Place 29510 Briec qui est l'adresse exacte indiquée dans la
> page contact <https://aucomptoirdaurelie.fr/contact-au-comptoir-daurelie/>
> de son site web.
>
> Ce projet utilise aussi les tags contact:housenumber, contact:street…
> Voir par exemple La Cuillère en Coin <
> https://www.openstreetmap.org/node/364694509>
>
> De Marc
> >> Sait-on pourquoi ce n'est pas  désiré en Allemagne ou Pologne ?
> >
> > parce que la majorité des outils ne le gèrent pas ou pas bien.
> > exemple charge un de ces objets dans iD, il te dit qu'il y a pas
> > de nom de rue et tout en bas "membre d'une relation".
>
> JOSM, iD, Vespucci gère les relations :)
>
> Que iD incite à saisir add:street alors que l'objet fait partie d'une
> relation est un autre problème.
> De même qu'il incite à saisir une adresse pour chaque POI.
> Il y a un ticket ouvert sur ce sujet :
> https://github.com/openstreetmap/iD/issues/8332 <
> https://github.com/openstreetmap/iD/issues/8332>
>
> > c'est le non de cette discussion : ce qu'on pourrait décider
> > dans un sens ou dans un autre ne change rien au support
> > non ergonomique dans iD, donc beaucoup d'utilisateur
> > d'iD continueront comme maintenant
>
>
> Il n'y a pas de fatalité : un problème similaire existait avec
> StreetComplete.
> Il a fallu expliquer nos particularités en France concernant les adresses,
> mais les auteurs en ont tenu compte :)
>
> La proposition de Pierrick pour clarifier le wiki va dans le bon sens (les
> débutants s'y réfèrent)
>
> Les contributeurs expérimentés informent les débutants avec des
> commentaires de changeset…
>
> Les outils de contrôle qualité peuvent repèrer voir corriger ce type
> d'erreurs.
>
> __
> Yves
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>