Le 21 août 2017 à 02:05, Jérôme Amagat <jerome.ama...@gmail.com> a écrit :
> Je rappelles que les relations network n'est sur le wiki qu'a l’état de > proposition, que cette proposition date de 2008, que rien n'a bougé sur > cette proposition depuis 2013 (et plus après 2009 ce n'est que pour ajouté > des exemples). Il y a des ajouts sur la page de discutions un peu plus > récent 2014 mais il sont négatif a l'ajout de ces relations. > Je ne vois pas pourquoi ils sont négatifs alors que chaque réseau a ses outils et méthodes pour travailler et se mettre à jour. Si on ne le fait pas, ces données seront de toute façon externalisées et le plus souvent sous forme non libre et très peu accessible. Sans ces relations il est quasiment impossible de faire un suivi de ce qui est dans la base, alros qu'on a en permanance besoin de se référer à ces réseaux, pour faire des plans, calculer des itinéraires et temps de parcours, déterminer les options tarifaires. Le simple tag "network=*" ne suffit pas et ce n'est pas en multipliant les tags que cela va s'arranger, alors que ces relations ont un coût quasi nul dans la base, et sont très facilement accessibles et même bien plus simple à mettre à jour pour s'assurer de leur complétude: Elles ne s'étendent pas à une quantité illimitée et non définie d'objets, on sait exhaustivement ce qui doit être dedans, et ce n'est pas pour des milliers d'objets ou beaucoup plus: à côté de ça les relations "route" sont beaucoup plus compliquées, lourdes, instables, et on ne peut pas prédire du tout le nombre nécessaire de leurs membres. Elles sont un outil de suivi aussi pratique (sinon plus) pour gérer l'avancement de leur construction ou de leur mise à jour, elles sont très sélectives, et permettent de diviser les tâches à faire. On en revient donc au même débat initial sur les "boundaries" qui ont eu le même problème (et qui elles aussi demandent des mises à jour): c'est toujours lors des mises à jour que cela se complique et que les outils externes sont les plus inefficaces, obligeant les contributeurs à jongler entre plein d'outils qui ne comprennent pas le même "langage" et ne s'accordent jamais sur les tags qu'ils reconnaissent et la façon dont ils gèrent leur sélectivité. Wikidata c'est bien mais ce n'est pas plus une solution: les objets Wikidata obéissent à une logique différente (dont celle de "notoriété" qui peut amener à joindre deux objets différents, ou des logiques de surclassification qui vont les diviser sans même souvent les relier entre eux), qui n'a rien à voir avec la couverture géospatiale exhaustive, ni même la cohérence globale: il va scinder des objets en sous-classes selon des critères supplémentaires non liés à l'information géospatiale, ajouter des informations historiques (et les sous-classer) et au final on ne pourra pas non plus gérer l'exhaustivité voulue par OSM (qui est de représenter correctement l'état **actuel** et effectif de la carte du monde, sans tenir compte du passé ou des projections futures qui en revcanche ont une importance élevée dans Wikidata et ses projets frères qui n'ont pas la même notion de ce qui est "important" en tant que base de "connaissance" universelle). Donc je pense sincèrement que ne pas vouloir les utiliser dans OSM (où leur mise en oeuvre est on ne peut plus simple et claire) c'est juste rendre service aux bases de données propriétaires (qui toutes le font dans leurs données): continuez comme ça, vous soutenez Google et le groupe des "Big Data", ne vous plaignez pas alors que des services publics soient tentés ensuite de ne plus utiliser OSM mais passent chez Google pour gérer leur données de façon cohérente et stable, ou refusent la stratégie Open Data et vont ne faire confiance qu'à l'IGN qui sera tenté de leur vendre son "expertise exclusive".
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
