Le 24/03/2010 09:03, Lord Awikatchikaen a écrit : > Je peux comprendre l'intérêt des relations B > A et B > Abis. Mais > pourquoi faire deux relations pour l'aller et le retour sur un même > parcours? les tag "forward:stop" et"backward:stop" devrait suffire à > décrire les deux sens de circulation. Deux raisons : * technique : simplicité de maintenance, * stratégique : Loi de Metcalfe
Pour moi, les itinéraires les arrêts dans le centre ville de Besançon sont différents selon le sens (voir par exemple la ligne 1 sur http://3liz.fr/public/osmtransport/index.php?country=France&location=Besan%C3%A7on et http://78.46.81.38/api/sketch-line?network=Ginko&ref=1&correspondences=100&font-size=10 Il m'est plus facile de vérifier l'intégrité l'exaustivité, donc d'assurer la maintenance dans JOSM, avec des routes correspondant à un voyage. Dans les relations, j'ai l'item 'relation ("1. Orchamps > Châteaufarine)', je sélectionne (le cas échéant, je télécharge les éléments manquants ) et j'ai, surligné à l'écran, tout ce qui concerne cette relation, voies, arrêts. La vérification est plus facile ! Orchamps > Châteaufarine : OK. Je passe à Châteaufarine > Orchamps. OK. La ligne est bonne, propre. Il est vrai que dans la relation, j'ordonne aussi les segments. Plus facile ainsi de suivre et d'intégrer des boucles (le cas hier avec la ligne 27 qui dessert l'hôpital Mingoz, boucle pas encore représentée dans OSMTransport). Avec ce schéma, le segment parcouru deux fois est mis deux fois. Sans ce schéma, ça n'a pas de sens de le mettre deux fois. La description est hyper-réaliste, trop riche ? Certes je ne fais pas un outils pour navigation pour les chauffeurs de bus. Mais est-ce que je connais tous les usages qui seront tirés de la richesse des données ? Avec ce schéma hyper-réaliste, on (pas moi) pourra faire des statistiques sur les longueurs de lignes et autres idées que je n'ai même pas. Sans ce schéma, difficile. Si les données sont pauvres, les usages seront pauvres, voire absents, si les données sont riches (nombreuses et signifiantes) les usages se multiplieront et se diversifieront. Et les données viendront. C'est la loi de Metcalfe (cf http://fr.wikipedia.org/wiki/Loi_de_Metcalfe) Si Besançon est mappé avec cette richesse, les devs (3Liz ?) auront une (petite, Besançon n'est pas grand) base de test pour ces nouvelles applications, pour les outils de gestion de qualité... Je fais de la carto sur OSM pour combler un retard sur la liberté des données, mais aussi pour anticiper les applications qui pourront être faites avec des données libres. Quel intérêt voyait-on à entrer la hauteur du bâtit, il y a un an ? La feature image de la semaine (que j'avais proposé ;-) est en train de démontrer le bien fondé de ce type d'info. Ma question pour les transports, c'est : Comment représenter la complexité du réseau RER-Île de France avec ce modèle. Qui osera se lancer ? Je crois que la clef est dans ce modèle et dans l'usage des noms de mission : AJAC, EKLI, EKIL, EFLA, EFOR, VICK Du boulot ! Au fait, il y a aussi quelques outils sur le wiki pour gérer l'avancée de ce genre de cartographie : http://wiki.openstreetmap.org/wiki/Besan%C3%A7on/Ginko#1 Bon courage ! -- FrViPofm _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
