J'ai dit "ovales" juste pour simplifier, car évidemment ce sont en fait des formes créées par un polygone convexe englobant tous les arrêts inclus, élargis par un petit "buffer" créé autour avec des angles arrondis. Ca donne des formes qui dépendent de la listance entre les arrêts et de leur nombre (il peut arriver qu'on ait 4 arrêts sur les 4 rues d'un même carrefour, formant plus ou moins un grand carré, ça donnera une forme qui ne sera pas nécessairement "oblongue" non plus. On dit en général "ovale" pour désigner le tracé de tells formes désignant des ensembles dans des représentations schématiques simplifiées comme c'est le cas ici.
Etant donné l'absence de rendu actuel des platform et stop_position, et que seuls les bus_stop sont rendus, il faut je pense garder pour l'instant la redondance bus_stop + platform pour passer au schéma v2 (donc vérifier que les bus_stop sont bien tous des "platforms", sinon transformer ces noeuds uniquement en en stop_position et créer un "platform"+"bus_stop" à côté de la voie. Et mettre à jour les relations route pour qu'elles incluent les deux noeuds: rôle "stop" pour le noeud "stop_position", rôle "platform" pour le noeud (ou le chemin si on a tracé une zone/un quai, voire un abri) avec "bus_stop"+"platform". Au passage sur Rennes je fais l'essai sur la ligne C1. J'avais au départ supprimé les tags "bus_stop" du schéma v1, mais je vais les remettre en redondance sur les "platform". Sachant aussi que l'outil "sketchline" (fourni par l'Overpass Turbo) affichera alors les deux points comme deux arrêts distincts car il traite "bus_stop" et "stop_position" comme des arrêts distincts (d'autant plus qu'il ne seront pas à la même position puisque "bus_stop" se retrouvera sur la "plateform" à côté de la voie alors que "stop_postion" sera sur le chemin !) on pourrait aussi décider de faire l'inverse : * garder "bus_stop" (pour les rendus actuels) uniquement sur le noeud "stop_position", mais alors on verra l'icône au milieu de la chaussée et on ne verra plus les icones à l'emplacement des stations sur les trottoirs. On voit que la décision de garder "bus_stop" (sur l'un ou l'autre), est juste destinée à "taguer pour le rendu". Ce qui montre bien que "bus_stop" est mal fichu depuis le début et devra à terme être viré des données !!! Autre anomalie relevée dans le schéma v2: des membres pour les stations peuvent être ajoutés aux relations "route", mais aucun rôle n'a été défini. Ces stations sont typiquement des chemins (pour désigner des bâtiments de gares par exemple). On peut aussi les inclure comme noeuds simples (plus ou moins centrés sur la zone d'une "gare" ou d'une "stop_area"). Mais pour inclure un batiment, pas moyen de le faire avec autre chose qu'un seul chemin fermé. JOSM râle si on y met une relation (pour des batiments complexes ayant des enclaves par exemple), par ce que la documentation n'a pas prévu qu'un bâtiment doive être décrit de façon plus compliquée qu'un seul chemin fermé. Et la documentation du Wiki indique même (à tord !) "onRelation=no" et semble vouloir l'interdire (ce qui est carrément stupide ou irréfléchi!). Au lieu de mettre une telle restriction, il aurait mieux valu prévoir un rôle particulier "station" pour décrire des noeuds/chemins/relation destinés à décrire toute une station/gare (laquelle peut avoir même plusieurs bâtiments proches mais séparés (par exemple deux gares de chaque côté d'une ligne, reliées par un souterrain, une passerelle, voire encore un passage à niveau dans les plus petites gares plus rurales, mais associées aux mêmes arrêts). Et dans l'immédiat je suis pour qu'on retire la restriction "onrelation=no" pour les bâtiments d'une station/gare (la documentation de leurs autres tags sont aussi mal fichus, regardez un peu le détail!). Ca mériterait d'être discuté sur la page de discussion associée pour une vue plus internationale: ce schéma v2, bien qu'approuvé depuis des mois demande à avancer et à être corrigé de ses problèmes ! Le 13 décembre 2016 à 13:05, <osm.sanspourr...@spamgourmet.com> a écrit : > Le 12/12/2016 à 23:06, Philippe Verdy - verd...@wanadoo.fr a écrit : > > en revanche les "stop_area" sont reconnus par le rendu "Public Transport" > qui affiche des ovales autour des arrêts "stop_position" > > Avec le schéma V1 on a déjà ça avec les highway > <http://wiki.openstreetmap.org/wiki/FR:Key:highway?uselang=fr>=bus_stop > <http://wiki.openstreetmap.org/wiki/FR:Tag:highway=bus%20stop?uselang=fr> > comme ici : > > http://www.openstreetmap.org/node/717560945#map=18/48. > 39228/-4.48753&layers=T > > Mais on voit que changer un schéma sans prévoir des règles d'adaptation > des données et des moteurs (de rendu, de calcul d'itinéraire, etc...) n'est > pas très raisonnable. > > De plus ce concept de zone de correspondance est assez fumeux : quand on > va du point a au point b qui ne sont pas reliés par la même ligne, on va > accepter de marcher entre les deux stations les plus proches... sauf si ça > rallonge de beaucoup le trajet motorisé. > > Typiquement au niveau de calcul d'itinéraires on va facilement passer par > quelques nœuds de convergence des réseaux qui ne seront pas nécessairement > très proches. Pour rester sur Brest : typiquement les arrêts autour de la > place de la Liberté, République pour Rennes, etc... même si les arrêts > n'ont pas le même nom et sans qu'on veuille je crois mettre toutes les > stations du coin dans une même stop_area - le rendu serait peut-être des > zones oblongues (ce ne sont pas des ovales) reliés par des traits conne > c'est souvent schématisé sur des schémas de transports, faire un gros > polygone/ovale n'aurait pas de sens (5 fois 2 arrêts Liberté* et 1 fois 2 > Multiplexe > <http://www.openstreetmap.org#map=17/48.39065/-4.48610&layers=T>). Et > pourtant les gens changent à "Liberté" ou "République". > > Jean-Yvon > > _______________________________________________ > 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
