Ne plus ajouter les rond-points donnerait dans l'éditeur de relations de JOSM l'impression que la route n'est pas continue. Dans le rendu pareil. Ce n'est donc pas une option.
Quant à la proposition: Il s'agit de relations routes qui utilisent une hiérarchie supplémentaire de relations routes, qui eux décrivent de parties d'itinéraires, qui peuvent être réutilisés par plusieurs variations d'itinéraire de bus. Je pense que j'aurai besoin d'un autre exemple. Peut-être que j'en fabriquerai un ce soir. J'ai ajouté une relation au sud-ouest de Mouscron hier qui est composé de 20 variations et point de vue itinéraire bus, il était dans terrain vierge. J'utiliserai celui-là comme guinea pig. Pour les route master, là je suis la proposition de transport en commun villifiée par ceux qui font le rendu, mais que les mappeurs semblent plus ou moins adopter. je dis plus ou moins, car moi aussi j'utilise plutôt une version 'light' pour la plupart des arrêts. C'est une modellisation de la réalité. Le niveau route master représente ce que les gens comprennent comme 'la ligne telle'. Est-ce une catégorie déguisé? D'un coté je suis content qu'elles soient présentes, car je les utilise pour ajouter des ref qui sont commun pour toutes les variations. Mais si quelqu'un veut combattre les moulins-à-vent, c'est un bon cible, je suppose. Jo 2014-07-24 18:12 GMT+02:00 Muselaar <musel...@ouvaton.org>: > Nouvelle réflexion qui s'ajoute aux précédentes : je ne comprends en fait > pas l'utilité des « routes master » : il me semble que c'est une sorte de > catégorie déguisée, précédemment vilipendée… > Si l'on veut chercher toutes les routes d'une même ligne, il est bien > facile de recouper l'opérateur avec le numéro de la ligne en question… ? > > Le 24/07/2014 17:48, Muselaar a écrit : > > > Sur la question du découpage des ronds-points, j'en suis venu à penser > différemment (bien que j'avoue, j'en ai découpé quelques uns pour plus de > clarté, mais tous les autres, non), il me semble à moi aussi maintenant que > c'est uniquement un problème de rendu : > > Une solution élégante, et qui allègerait les données, serait de s'abstenir > de taguer la route sur les ronds-points, et que la continuité soit reconnue > par le fait que 2 nodes différents d'un même rond-point appartiennent à la > même route. Je n'arrive pas à imaginer un cas où il pourrait y avoir > ambiguité. > La route serait alors d'office le parcours obligatoire d'un node à > l'autre, étant donné le sens de circulation. > Si l'on considère le rond-point comme un carrefour en un même et unique > objet, il n'y aurait effectivement en toute logique aucune raison de le > taguer, dans la mesure ou les nodes d'entrée et de sortie appartiennent au > même carrefour. Un rond-point est un cas particulier de chemin, il n'est > pas linéaire, mais circulaire, il revient sur lui-même, on ne peut pas lui > appliquer les raisonnements adaptés aux autres chemins. > Il y a bien sûr des cas particuliers dans lesquels un parcours peut > débuter ou se terminer sur un rond-point, mais à mon sens, ça ne peut en > aucun cas être le node d'entrée ou de sortie, mais seulement un node > intermédiaire, ce qui n'interfèrerait pas avec ma proposition. > Mais cette solution demanderait des adaptations logicielles. Qu'en disent > les techniciens ? > > > Pour ton exemple de routes « intermédiaires », je ne comprends pas > exactement ce que tu as fait, étant donné que le rendu n'est actuellement > pas apte à le prendre en compte… Tu as mis à la fois les chemins, les > stops, et les plateformes, c'est ça ? > > Je ne pense pas que ce soit une bonne idée d'intégrer les arrêts à ces > niveaux intermédiaires : d'une part, les arrêts peuvent être différents > d'une ligne à l'autre (rien qu'à Belfort qui est une petite ville, il y a > plusieurs exemples d'arrêts qui sont « sautés » par certaines lignes), > d'autre part, les arrêts, que ce soit les stop_positions ou les > plateformes, n'interfèrent quasiment pas avec le reste de la cartographie, > donc cela ne crée pas de perturbation pour l'édition des autres usages. > > De plus, concernant le nombre élevé, je ne crois pas qu'un même point > d'arrêt puisse être utilisé par 63 routes de bus, ça doit faire une sacrée > queue de bus, et ils n'auraient pas le temps de s'arrêter. Dans mes deux > exemples de 20 et 22 relations-routes, il n'y a aucun arrêt qui soit > partagé par toutes les relations présentes sur la rue. Sur tout le réseau > du Territoire de Belfort, ville comprise, je ne vois que 3 stop_positions > (parce que 2 sens confondus) qui totalisent 14 ou 15 routes, et plusieurs > autres 11 routes, en raison essentiellement des variations de parcours > selon le moment de la journée. Avec l'éditeur de relations de JOSM, ce > nombre de relations différentes sur un même objet local est très facile à > gérer. > > La question qui reste est de savoir si c'est techniquement réalisable. > Pour taguer, on peut toujours, mais si ensuite ce n'est pas exploitable, ça > ne présente pas d'intérêt. Cette solution demanderait donc des adaptations > logicielles. Qu'en disent les techniciens ? > > > Muselaar > > > Le 24/07/2014 16:45, Jo a écrit : > > Je suis complètement d'accord pour ce niveau intermédiaire entre les > chemins et les relations route qui symbolisent toutes les variations des > lignes de transport en commun. > > J'ai une rue où j'ai mappé toutes les lignes qui rentrent en ville et > j'arrive à 63 relations route pour 28 itinéraires. Il ya donc relativement > peu de variations sur les lignes, mais il y a certainement bcp de lignes > qui y passent, ce qui rend l'édition compliqué. > > J'ai déjà essayé de faire cet exercice pour un itinéraire: > > > https://www.openstreetmap.org/relation/2336781/history#map=14/50.8655/4.6878 > > https://www.openstreetmap.org/relation/2336780/history#map=14/50.8653/4.6883 > > il y a 2 ans déjà, mais à l'époque OSM n'était pas prêt pour une solution > tellement révolutionnaire. Même si pour les itinéraires de randonnée une > telle solution a bien été adoptée. > > Malheureusement, je ne vois pas comment cela résoudrait notre différence > d'opinion sur les rond-points. > > Jo > > > _______________________________________________ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > > > > _______________________________________________ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > 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
