Le 5 octobre 2013 21:09, Pieren <pier...@gmail.com> a écrit : > Il ne faut pas attacher trop d'importance au rendu. Même si on sait > bien que ça reste le premier outil de "validation" pour les nouveaux > contributeurs (et aussi la première forme de récompense), il y a aussi > des tas de choses dans OSM qui ne sont pas affichées sur la carte > principale. Ou des choses qui sont affichées alors qu'elles sont mal > cartographiées. Donc, toujours examiner les données pour se faire un > avis critique. > > Je ne partage pas l'avis de la communauté sur ces histoires de rendu / données, mais c'est un autre débat. Au moins, je comprends ta position.
> > de surface, mais, apparemment, c'est compliqué les surfaces. > > Les surfaces, c'est pas compliqué. Mais il y a "surface" et "surface". > Celle qu'on indique avec "highway=unclassified" + "area=yes" a une > signification très claire : c'est une place ouverte où les véhicules > peuvent circuler dans toutes les directions. Ca n'était pas le cas de > cet exemple à Saint-Etienne. > Il y a aussi la possibilité d'indiquer la surface occupée par une > route normale (qui conserve son filaire central) avec un tag qui est > resté au stade de la proposition : "area:highway" ([1]). Il n'est pas > rendu par mapnik et n'est pas très populaire (10000 exemplaires par > 460 contributeurs quand même dans la base). > > S'il y a "surface" et "surface", la surface dont je te parle est visible de visu. Mais bon je renonce à chipoter, et j'admets que l'idée de concentrer les routes sur un point est pas mauvaise les choses étant ce qu'elles sont. La modélisation reste compatible avec le terrain, à part le problème des feux, voir plus loin. D'ailleurs il me semble qu'on pourrait encore simplifier ton modèle, tout en restant compatible terrain : si la rue des armuriers arrive directement au point central, ça marche encore bien, non ? Le carrefour serait modélisé par deux points : un point de rencontre rues pélissier / valbenoite / armuriers / mulatière, et un valbenoite / jean baptiste david / micro rue en sens unique vers armuriers. Le carrefour serait l'ensemble de ces deux points reliés par une rue, rue inexistante, mais... c'est un modèle. > > > D'ailleurs, les chemins piétons sont bons dans > > l'ensemble, mais DIeu seul sait s'ils sont "routables" ? > > Ca n'était pas le problème posé au début de ce fil de discussion. > Suivant les retours qu'on voit sur un autre fil, il est probable qu'il > ne soit pas "routable" pour la plupart des logiciels qui le font pour > les piétons avec les données OSM. Mais les zones piétonnes sont dans > leur immense majorité tagguées de cette manière, sans "footway" ajouté > pour les rendre "routable" par certains logiciels. C'est aux logiciels > de s'adapter aux données et non l'inverse. > Pour revenir aux trottoirs, on voit que ceux qui commencent à > cartographier ça ne vont jamais jusqu'au bout et s'arrêtent au bout de > quelques rues. Du coup, on a un résultat très moche sur la carte (toi > qui donne beaucoup d'importance au rendu pourrait y être sensible). > C'est pourquoi personnellement, je ne cartographie pas les trottoirs. > De plus, cela alourdit considérablement le filaire dans la zone et > rend difficile toutes les contributions futures. Au mieux, il existe > la possibilité d'ajouter un attribut au "highway" principal pour dire > si un trottoir se trouve à gauche, à droite ou des deux côtés. Je > préfererais nettement cette option si j'avais à choisir. > > Oui, mais le principe "ceux qui commence à cartographier ne vont jamais jusqu'au bout" est consécutif aux principes collaboratifs, et au principe "mappez ce qu'il y a en bas de chez vous", non ? Du coup il faut une transition cohérente entre ce qui est mappé et ce qui ne l'est pas. Mais pour les trottoirs, ce n'est pas facile. > > - du fait qu'il n'y a pas de surface, de nombreuses relations entre > objets > > sont incohérentes avec le terrain : la sorte de point central n'existe > pas, > > et ça décale toutes les distances entre le bord de la place et les objets > > qui l'entourent. > > Je ne comprend pas bien cette remarque (quelle relations entre > objets). Si tu veux faire figurer la surface de la partie routière, > qui est très large dans ce cas particulier, utilise un polygone taggué > "area:highway" déjà cité plus haut. La modélisation sera complète mais > tu ne verras pas cette surface sur la carte principale. Si tu veux à > tout prix voir cette surface, tu seras obligé d'utiliser le > "highway=unclassified" + "area=yes" qui entrera en contradiction avec > le filaire des voies (et c'est "tagguer pour le rendu" puisque tu > sous-entends avec ces tags que l'espace est ouvert dans toutes les > directions, ce qui n'est pas le cas). > Je ne sais pas trop pourquoi tu affirmes que l'espace n'est pas ouvert dans toutes les directions... Il y a un obstacle magnétique ? Je me demande ce que pense Christian Quest, le Maître "es rendu es datas", de ces histoires de area qui sont inutilisées et non rendues ?... C'est une méga connerie de la communauté, non ?... > Il n'y a donc pas à l'heure actuelle de solution idéale (bonne > modélisation et rendu de la surface). Celle que tu examiné ce matin > est un compromis. Tu peux y revenir et y ajouté ta surface, mais > taggué "area:highway" puis attendre que celui-ci soit pris en compte > par la carte principale. > > > - la position des feux sur le rendu ne permet pas de savoir sur quelle > route > > ils sont, et il en manque un, au sortir de la rue des armuriers, feu que > > l'on voit là : http://www.flickr.com/photos/mpoudisk/10067661055/ > > J'ai remis ce feu manquant. Pour le reste, le tag > "highway=traffic_signals" ne se mettait pas sur la position de chaque > feu individuel mais sur l'intersection au départ. Ce tag veut dire > "cette intersection est controllée par x feux". Malheureusement, comme > il affiche un feu tricolor sur la carte, beaucoup l'utilisent pour > chaque feu individuel. Mais du coup, des logiciels qui voudraient > utiliser cette information auront beaucoup de mal pour savoir si > l'objet représente un feu ou x feux (pour pouvoir par exemple > pénaliser un itinéraire dans un logiciel de routage). L'idéal serait > d'utiliser un tag distinct pour modéliser les feux individuels et > créer une relation pour regrouper l'ensemble des feux synchronisés > pour controller l'intersection. Les logiciels pourraient ensuite y > retrouver leurs petits (le rendu pourrait choisir d'afficher les feux > individuels ou à l'intersection suivant les niveaux de zooms; les > logiciels de routages pourraient correctement estimer le temps de > pénalisation par intersection; etc). > > L'ennuyeux de cette histoire est que ce n'est plus cohérent avec le terrain du tout. Sur le terrain, il y a un seul système de feux (un seul traffic-signals) pour tout le carrefour. Or selon le modèle utilisé, il y aurait 3 systèmes de feux. Cela n'existe pas ici. Il y a bien un seul feu (pas un système) au point signalés traffic-signals, mais pas comme traffic_signals. Et je ne vois pas comment il est possible de décrire ça, car la micro voie à sens unique est dans le carrefour, est n'est accessible en bagnole qu'une fois passé un feu ; c'est une voie dans un carrefour. Sur ce point, il me semble que ta proposition échoue à rendre le terrain. Mais ce n'est pas pour ça que je la rejetterais brutalement, hein, je vais attendre d'en avoir une meilleure... (et pour l'instant ce n'est pas le cas). Dans l'état actuel des choses, il me semble qu'on pourrait conserver cette modéilisation ? Cordialement.
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
