Dans ce cas, ne serait-il pas intéressant "d'aplatir" les données des relations lors de l'édition, et de refactoriser le tout lors de l'enregistrement dans la base de données ?
Je ne sais pas s'il faudrait mieux faire ça du côté des clients ou du serveur, mais la saisie reste simple car la complexité des relation est masquée par l'absence d'édition directe desdites relations. Je ne pense pas que ce système peut fonctionner pour tout (multipolygones), mais je ne vois pas de problèmes pour les lignes de bus ou pour les adresses. Greg 2014-05-26 12:57 GMT+02:00 Pieren <pier...@gmail.com>: > 2014-05-26 11:57 GMT+02:00 Christophe Merlet <red...@redfoxcenter.org>: > > > 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é. > > Ou l'inverse... > > > 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. > > La raison en serait leur nombre. Même plus petites, si elles sont > systématiques, elles seront plus souvent cassée... > > > 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 ? > > Le ref:FANTOIR ne peut, ne doit pas être la raison de créer des > relations associatedStreet. Les autres pays peuvent avoir leurs refs > ou même leurs wikidata. Concernant le travail avec les collectivités > locales, c'est bien entendu un sujet partagé. La discussion sur le > "share alike" de la license et les CT est directement inspirée d'une > collaboration avec des collectivités locales. Partout, on voit bien > que l'ajout des adresses par des contributeurs isolés prendrait de > nombreuses années voir décennies et que si l'import d'une base > publique est possible, il sera systématiquement préféré. > > > > 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. > > Sauf que comme des appli genre OsmAnd ne reconnaissent pas ces > relations, on voit fleurir ici et là des rues tagguées avec les deux > modèles. Sauf que même avec une relation, le toponyme reste sur le > highway parce que mapnik ne connait pas cette relation. Sauf que > certains ont une interprétation différente du tag name sur la relation > et mettent déjà un nom différent de la rue. Sauf que certains font > deux ou plus relations par rues. Sauf que rien n'empêche quelqu'un de > mettre la rue dans plusieurs relations... > > > On peut associer un code FANTOIR unique à une seule relation plutôt qu'a > > chaque tronçon de la même voie. > > Comme le tag 'ref' ou le tag 'name' qu'il est bien plus simple de > retrouver sur le way lui-même. On peut aussi décider de tout déplacer > dans des relations : une pour le nom, une pour le 'ref', une pour le > maxspeed, etc... > > > Avec les relation on factorise les redondance d'informations. c'est > > bénéfique pour la base. > > Alors il faut pousser la logique jusqu'au bout et tout mettre dans des > relations. > > > 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. > > C'est l'autre risque du projet, le "syndrome wikipedia" qui fait que > seuls des experts pourront modifier la carte. Et après ils viendront > pleurer qu'il n'y a pas assez de contributeurs locaux pour actualiser > les données. Quant à l'éditeur qui modifie les relations discrètement > et en toute facilité, on le cherche encore... > > Pieren > > _______________________________________________ > 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
