[OSM-talk-fr] Sur le modèle des adresses (était "Rendu BANO")

[Christophe Merlet]

Le 26/05/2014 11:27, Pieren a écrit :
> 2014-05-24 15:04 GMT+02:00 DH <dhelfer at free.fr>:
> 
>> Ainsi, par exemple, je n'avais pas assimilé l'intérêt des
>> relations AssociatedStreet, maintenant si.
> 
> Au risque de me répéter, il y aurait un grand danger à vouloir
> généraliser les relations associatedStreet dans OSM pour des raisons
> que j'ai déjà expliqué par ailleurs mais que je vais résumer ici:
> - c'est plus difficile à modifier. Ceux qui les ajoutent utilisent
> josm et c'est vrai que c'est facile d'emploi avec cet éditeur. Mais je
> les défie de modifier ces relations avec iD ou P2, ne serait-ce que de
> déplacer un numéro d'une rue à sa voisine. C'est très difficile et
> chia.. même pour les habitués. Et ne parlons pas des nouveaux
> contributeurs ou irréguliers.

Généraliser les associatedStreet ne rend pas obsolètes les autres
manières de tagguer les adresses.

OpenStreetMap fonctionne ne manière itérative. Le neocontributeur ira au
plus simple avec un simple noeud qui sera ensuite intégré a la relation
idoine par un contributeur plus expérimenté.


> - l'argument sur l'intégrité est correct dans l'immédiat mais ne tient
> pas au long cours. On le voit avec toutes les relations comme les
> limites administratives, toutes les relations de type "route" ou même
> les multipolygones (pensez landuse corine), elles sont plus difficiles
> à maintenir parce qu'elles sont souvent cassées par les néophites. Ou
> pire, si l'éditeur est préventif à l'égard de toute modification comme
> dans JOSM, elle bloquera la bonne volonté du débutant.

Chaque type de relation a son propre cycle de vie. Les relations
adresses ne dérogeront pas à la règle. Il n'y a aucune raison qu'elles
soient plus cassées que les autres, bien au contraire à mon avis dans la
mesure ou elles ont une emprise beaucoup plus petite.

> - nous serions le seul pays à utiliser à une telle échelle une
> relation par rue dans OSM. Si aucun autre pays n'a fait ce choix, il
> faudrait au moins se demander pourquoi (alors qu'ils sont nombreux à
> faire des imports du même type et à se poser les mêmes questions que
> nous). L'habitude du village gaullois qui a raison seul contre tous ?

Les autres pays ont ils un ref:FANTOIR ? Les autres pays cherchent t'ils
simplement à afficher un numéro de rue sur un fond de carte ou a
travailler efficacement avec leurs collectivités territoriales ?

> - l'argument d'éviter les redondances ne tient pas. C'est même le
> contraire. Faute de support dans les outils externes autres que
> nominatim, les noms de rues sont de toute façon répétés sur la rue et
> la relation, si ce n'est pire, sur la rue et chaque numéro. Sans
> parler de l'internationalisation, des alt_name ou autres liens
> externes, on verra au final tous les tags doublonner. Certains ici
> prônent même la redondance comme solution à leurs problèmes lorsqu'ils
> doivent rédiger des règles de rendu pour mapnik et qu'ils trouvent au
> final la gestion des relations bien lourdes au niveau logiciel.

Heu, sur les doublons je ne te suis pas, il y en a beaucoup moins avec
les relations qu'a répéter un addr:street pour chaque addr:housenumber
Cela permet d'éviter de multiplier les erreurs de toponymes et
d'augmenter la qualité des données.

On peut associer un code FANTOIR unique à une seule relation plutôt qu'a
chaque tronçon de la même voie.


> - sur la modélisation elle-même, tout ce qui peut s'identifier par une
> relation peut se faire sans elle. Des solutions existent déjà pour les
> name, ref ou ref:FR:FANTOIR, même pour des rues appartenant à deux
> communes.

Avec les relation on factorise les redondance d'informations. c'est
bénéfique pour la base.

> - l'argument du changement de nom de rue qui serait plus facile est,
> là encore, discutable. Comme on l'a vu, les noms sont déjà répétés et
> il y faudra de toute façon surveiller la cohérence entre noms et
> numéros avec des outils QA (ce que fait déjà l'outil de geofabrik, par
> exemple). Et de toute façon, les changements de noms sont assez rares
> et on sera d'avantage confronté à du vandalisme ou des interprétations
> orthographiques divergentes.
> - finalement, le principal avantage des relations se trouve du côté
> des utilisateurs des données. Pour eux, il est effectivement plus
> facile de travailler avec une relation par rue que de chercher à
> assembler des morceaux de rues pas toujours attachés entre eux avec
> des noeuds ou des polygones éparses. Mais dans OSM, il y a une règle
> de base : c'est le terrain qui prime, et 90% des contributeurs sont
> des contributeurs uniques ou de très faible niveau. Même si ça n'est
> pas eux qui produisent le plus de données en quantité, ce sont eux qui
> sont les plus proches du terrain et qui fournissent les meilleures
> données en qualité. S'il faut donc choisir entre faciliter la vie des
> consommateurs des données OSM (les développeurs) et celle des
> contributeurs néophites, il faudra toujours essayer de priviligier
> autant que possible les seconds, quitte à donner un peu plus de
> travail aux premiers.

Bizarre de ne pas vouloir faire évoluer les pratiques d'OSM vers un
niveau plus "industriels". Le but c'est de voir les données réutilisé le
plus massivement possible, pour cela il faut un certain formalisme, même
si cela augmente un peu le niveau de compétences requis pour contribuer.
Encore que dans le même temps, les outils de contribution vont masquer
cette difficulté dans des cliquodromes appropriés.



	Librement,
-- 
Christophe Merlet (RedFox)