[OSM-talk-fr] Tagguer pour le rendu
Salut à tous ! Comme certains veulent recentrer le débat de Saint-Etienne à Paris, j'ai constaté (avec stupeur) que notre tour Eiffel est découpée en pas moins de 9 morceaux (selon les niveaux de zoom). Quand on regarde les détails, ils y a des ways indiquant que : - *highway*: pedestrian - *layer*: 0 - *note*: [lapinos03] tracé voie pédestre facilite le calcul d'itinéraire piéton tout en étant invisible sur le rendu de l'aire piétonne - *surface*: gravel Déjà, le rendu invisible, c'est vite dit. C'est le cas avec le Mapnik par défaut, mais pas vrai sur tile.openstreetmap.fr, ni sur la Transport map, ni Mapquest, ni Humanitarian. Et je me souviens qu'à une époque, les itinéraires sur les surfaces, c'est au logiciel de routage de gérer ça. On a perdu cette philosophie ? Greg ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagguer pour le rendu
Pour rebondir sur la question du tracé de chemin sur les surfaces (typiquement, sur les aires piétonnes), je pense que la première chose à faire serait sans doute de corriger Josm, qui râle quand un chemin se termine sur une surface. Corriger ce bug limiterait les tracés de ways en travers des surfaces, certains contributeurs s'en remettant sans doute à la sagesse de Josm... Francescu Le 4 octobre 2013 17:22, Greg ewala...@gmail.com a écrit : Salut à tous ! Comme certains veulent recentrer le débat de Saint-Etienne à Paris, j'ai constaté (avec stupeur) que notre tour Eiffel est découpée en pas moins de 9 morceaux (selon les niveaux de zoom). Quand on regarde les détails, ils y a des ways indiquant que : - *highway*: pedestrian - *layer*: 0 - *note*: [lapinos03] tracé voie pédestre facilite le calcul d'itinéraire piéton tout en étant invisible sur le rendu de l'aire piétonne - *surface*: gravel Déjà, le rendu invisible, c'est vite dit. C'est le cas avec le Mapnik par défaut, mais pas vrai sur tile.openstreetmap.fr, ni sur la Transport map, ni Mapquest, ni Humanitarian. Et je me souviens qu'à une époque, les itinéraires sur les surfaces, c'est au logiciel de routage de gérer ça. On a perdu cette philosophie ? Greg ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagguer pour le rendu
JOSM ne signale déjà plus quand un chemin piéton se termine sur une surface piétonne. Note que je n'ai JAMAIS eu l'idée de taguer pour le rendu, comme le laisse croire certains messages ici. Pieren n'est pas satisafit du fait qu'il y a un segment qu'il juge en trop sur le filaire d'une place (qui n'est pas une surface...) mais il est justifié pour le routage pour éviter une épingle à cheveux irréaliste à près de 180 degrés trop loin alors qu'on a toute la place pour tourner avant (et ce n'est indiqué nulle part dans les surfaces car il n'y a aucune surface pour les rues, seulement pour les zones piétonnes. Le 4 octobre 2013 17:36, Francescu GAROBY windu...@gmail.com a écrit : Pour rebondir sur la question du tracé de chemin sur les surfaces (typiquement, sur les aires piétonnes), je pense que la première chose à faire serait sans doute de corriger Josm, qui râle quand un chemin se termine sur une surface. Corriger ce bug limiterait les tracés de ways en travers des surfaces, certains contributeurs s'en remettant sans doute à la sagesse de Josm... Francescu Le 4 octobre 2013 17:22, Greg ewala...@gmail.com a écrit : Salut à tous ! Comme certains veulent recentrer le débat de Saint-Etienne à Paris, j'ai constaté (avec stupeur) que notre tour Eiffel est découpée en pas moins de 9 morceaux (selon les niveaux de zoom). Quand on regarde les détails, ils y a des ways indiquant que : - *highway*: pedestrian - *layer*: 0 - *note*: [lapinos03] tracé voie pédestre facilite le calcul d'itinéraire piéton tout en étant invisible sur le rendu de l'aire piétonne - *surface*: gravel Déjà, le rendu invisible, c'est vite dit. C'est le cas avec le Mapnik par défaut, mais pas vrai sur tile.openstreetmap.fr, ni sur la Transport map, ni Mapquest, ni Humanitarian. Et je me souviens qu'à une époque, les itinéraires sur les surfaces, c'est au logiciel de routage de gérer ça. On a perdu cette philosophie ? Greg ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ 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
Re: [OSM-talk-fr] Tagguer pour le rendu
Le 4 octobre 2013 17:36, Francescu GAROBY windu...@gmail.com a écrit : je pense que la première chose à faire serait sans doute de corriger Josm, qui râle quand un chemin se termine sur une surface. Corriger ce bug limiterait les tracés de ways en travers des surfaces, certains contributeurs s'en remettant sans doute à la sagesse de Josm... Pour ça le mieux est, pour chaque faux positif rencontré, d'attacher un petit fichier.osm à ce ticket: http://josm.openstreetmap.de/ticket/7662https://josm.openstreetmap.de/ticket/7662 et on traitera au cas par cas :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagguer pour le rendu
Bonsoir, Vous en connaissez beaucoup, des routeurs qui gèrent correctement les itinéraires sur des surfaces ? Je peux me tromper, mais je viens d'en réessayer une demi-douzaine. Ils viennent en deux variétés : -les agoraphobes, qui transforment les arêtes d'une surface piétonne en éléments du graphe et routent le piéton prudemment tout autour de la surface en rasant les murs -les autruche, qui font comme si la surface piétonne n'existait pas. Il se peut que j'ai râté le routeur qui permet de gérer cette navigation au cap, tout en évitant les kiosques à musique et les bacs-à-fleur-qui-sont-peut-être-des-jardins. S'il existe, je suis preneur. Sincèrement. L'autre solution est peut-être, lors de la production du graphe, de tracer des droites entre tous les noeuds en bord de place (en espérant que la place est raccordée au reste du monde), puis d'éliminer tous les tracés impossibles, surtout si la surface a une forme concave. Et de détourner tous les tracés qui percutent un objet qui aurait bêtement été laissé au milieu de la surface, comme un pilier de la tour Eiffel. Sinon il me semble qu'on continuera à avoir besoin de ways qui sont là principalement pour le bénéfice du routage. Il y a deux solutions : -que les outils de rendu (surtout ceux à vocation esthétisante) éliminent tout ce qui est voies au sein d'un area -que l'on reconnaisse (et que l'on utilise) un tag indiquant que le way est là pour des questions de graphe avant tout. virtual=yes ou render=no ? Si quelqu'un a une meilleure piste, je suis très preneur en tant que gros utilisateur de la nav' piéton. Fionn Le vendredi 4 octobre 2013, Greg a écrit : Salut à tous ! Comme certains veulent recentrer le débat de Saint-Etienne à Paris, j'ai constaté (avec stupeur) que notre tour Eiffel est découpée en pas moins de 9 morceaux (selon les niveaux de zoom). Quand on regarde les détails, ils y a des ways indiquant que : - *highway*: pedestrian - *layer*: 0 - *note*: [lapinos03] tracé voie pédestre facilite le calcul d'itinéraire piéton tout en étant invisible sur le rendu de l'aire piétonne - *surface*: gravel Déjà, le rendu invisible, c'est vite dit. C'est le cas avec le Mapnik par défaut, mais pas vrai sur tile.openstreetmap.fr, ni sur la Transport map, ni Mapquest, ni Humanitarian. Et je me souviens qu'à une époque, les itinéraires sur les surfaces, c'est au logiciel de routage de gérer ça. On a perdu cette philosophie ? Greg ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagguer pour le rendu
A Birmingham, j'ai eu une discussion sur ce sujet avec Andrew (opentripplanner). On est arrivé à imaginer un highway=virtual pour relier tout type de voie. Pas besoin d'info complémentaire, il servent à relier virtuellement leurs deux extrémités. Ce peut servir aussi à relier l'entrée et la sortie d'un parking souterrain. Le 4 octobre 2013 21:44, Fionn Halleman fionn.halle...@valeurs-mobiles.fra écrit : Bonsoir, Vous en connaissez beaucoup, des routeurs qui gèrent correctement les itinéraires sur des surfaces ? Je peux me tromper, mais je viens d'en réessayer une demi-douzaine. Ils viennent en deux variétés : -les agoraphobes, qui transforment les arêtes d'une surface piétonne en éléments du graphe et routent le piéton prudemment tout autour de la surface en rasant les murs -les autruche, qui font comme si la surface piétonne n'existait pas. Il se peut que j'ai râté le routeur qui permet de gérer cette navigation au cap, tout en évitant les kiosques à musique et les bacs-à-fleur-qui-sont-peut-être-des-jardins. S'il existe, je suis preneur. Sincèrement. L'autre solution est peut-être, lors de la production du graphe, de tracer des droites entre tous les noeuds en bord de place (en espérant que la place est raccordée au reste du monde), puis d'éliminer tous les tracés impossibles, surtout si la surface a une forme concave. Et de détourner tous les tracés qui percutent un objet qui aurait bêtement été laissé au milieu de la surface, comme un pilier de la tour Eiffel. Sinon il me semble qu'on continuera à avoir besoin de ways qui sont là principalement pour le bénéfice du routage. Il y a deux solutions : -que les outils de rendu (surtout ceux à vocation esthétisante) éliminent tout ce qui est voies au sein d'un area -que l'on reconnaisse (et que l'on utilise) un tag indiquant que le way est là pour des questions de graphe avant tout. virtual=yes ou render=no ? Si quelqu'un a une meilleure piste, je suis très preneur en tant que gros utilisateur de la nav' piéton. Fionn Le vendredi 4 octobre 2013, Greg a écrit : Salut à tous ! Comme certains veulent recentrer le débat de Saint-Etienne à Paris, j'ai constaté (avec stupeur) que notre tour Eiffel est découpée en pas moins de 9 morceaux (selon les niveaux de zoom). Quand on regarde les détails, ils y a des ways indiquant que : - *highway*: pedestrian - *layer*: 0 - *note*: [lapinos03] tracé voie pédestre facilite le calcul d'itinéraire piéton tout en étant invisible sur le rendu de l'aire piétonne - *surface*: gravel Déjà, le rendu invisible, c'est vite dit. C'est le cas avec le Mapnik par défaut, mais pas vrai sur tile.openstreetmap.fr, ni sur la Transport map, ni Mapquest, ni Humanitarian. Et je me souviens qu'à une époque, les itinéraires sur les surfaces, c'est au logiciel de routage de gérer ça. On a perdu cette philosophie ? Greg ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagguer pour le rendu
Le 4 octobre 2013 21:44, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : Si quelqu'un a une meilleure piste, je suis très preneur en tant que gros utilisateur de la nav' piéton. En mode beta sur Toulouse, il y a ModdWalkR: http://moodwalkr.makina-corpus.net/# Il faut essayer sur la place du capitole. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagguer pour le rendu
Opentripplanner est l'un des routeurs que j'ai testés et c'était un agoraphobe. D'après taginfo il y a pour l'heure 11 tags highway=virtual dans le monde. Si j'exclus les 3 récemment apparus dans ma ville (dans un parking souterrain, tiens, tiens...), ça ne fait pas encore bien lourd, mais il faut bien commencer le mouvement. Fionn Le vendredi 4 octobre 2013, Christian Quest a écrit : A Birmingham, j'ai eu une discussion sur ce sujet avec Andrew (opentripplanner). On est arrivé à imaginer un highway=virtual pour relier tout type de voie. Pas besoin d'info complémentaire, il servent à relier virtuellement leurs deux extrémités. Ce peut servir aussi à relier l'entrée et la sortie d'un parking souterrain. Le 4 octobre 2013 21:44, Fionn Halleman fionn.halle...@valeurs-mobiles.frjavascript:_e({}, 'cvml', 'fionn.halle...@valeurs-mobiles.fr'); a écrit : Bonsoir, Vous en connaissez beaucoup, des routeurs qui gèrent correctement les itinéraires sur des surfaces ? Je peux me tromper, mais je viens d'en réessayer une demi-douzaine. Ils viennent en deux variétés : -les agoraphobes, qui transforment les arêtes d'une surface piétonne en éléments du graphe et routent le piéton prudemment tout autour de la surface en rasant les murs -les autruche, qui font comme si la surface piétonne n'existait pas. Il se peut que j'ai râté le routeur qui permet de gérer cette navigation au cap, tout en évitant les kiosques à musique et les bacs-à-fleur-qui-sont-peut-être-des-jardins. S'il existe, je suis preneur. Sincèrement. L'autre solution est peut-être, lors de la production du graphe, de tracer des droites entre tous les noeuds en bord de place (en espérant que la place est raccordée au reste du monde), puis d'éliminer tous les tracés impossibles, surtout si la surface a une forme concave. Et de détourner tous les tracés qui percutent un objet qui aurait bêtement été laissé au milieu de la surface, comme un pilier de la tour Eiffel. Sinon il me semble qu'on continuera à avoir besoin de ways qui sont là principalement pour le bénéfice du routage. Il y a deux solutions : -que les outils de rendu (surtout ceux à vocation esthétisante) éliminent tout ce qui est voies au sein d'un area -que l'on reconnaisse (et que l'on utilise) un tag indiquant que le way est là pour des questions de graphe avant tout. virtual=yes ou render=no ? Si quelqu'un a une meilleure piste, je suis très preneur en tant que gros utilisateur de la nav' piéton. Fionn Le vendredi 4 octobre 2013, Greg a écrit : Salut à tous ! Comme certains veulent recentrer le débat de Saint-Etienne à Paris, j'ai constaté (avec stupeur) que notre tour Eiffel est découpée en pas moins de 9 morceaux (selon les niveaux de zoom). Quand on regarde les détails, ils y a des ways indiquant que : - *highway*: pedestrian - *layer*: 0 - *note*: [lapinos03] tracé voie pédestre facilite le calcul d'itinéraire piéton tout en étant invisible sur le rendu de l'aire piétonne - *surface*: gravel Déjà, le rendu invisible, c'est vite dit. C'est le cas avec le Mapnik par défaut, mais pas vrai sur tile.openstreetmap.fr, ni sur la Transport map, ni Mapquest, ni Humanitarian. Et je me souviens qu'à une époque, les itinéraires sur les surfaces, c'est au logiciel de routage de gérer ça. On a perdu cette philosophie ? Greg ___ Talk-fr mailing list Talk-fr@openstreetmap.org javascript:_e({}, 'cvml', 'Talk-fr@openstreetmap.org'); https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagguer pour le rendu
Et est-ce qu'il ne serait pas pensable de taguer l'usage sur une surface ? Je veux dire par exemple sur une pelouse les gens vont passer plutot à tel endroit parce qu'il y a des trucs intéressants à tel autre. Mais ce n'est pas visible sur le terrain, mais juste un aspect humain. C'est un peu la même chose que les cours d'eau : il me semble qu'on y tague la surface occupée par l'eau, et le chemin par où passe le courant le plus important. Ce dernier n'est pourtant pas visible sur le terrain. Ensuite, il me semble que un bon traitement des surfaces par les logiciels de routage n'est pas infaisable... c'est quoi la difficulté qu'ils auraient à éviter les obstacles indiqués ?... il me semble que certes il faut faire des compromis, mais qu'il faut engager le mapping correct des surfaces, car c'est un gros boulot de modélisation. Indiquons les donc, ces obstacles. Ce qui me gène dans le virtual est que il n'a plus aucun rapport avec la géographie, alors que, avec la notion d'usage, on peut conserver le rapport avec la géographie, ce qui est quand même utile ?... d'autant qu'une grande partie des valeurs de tags est déjà en rapport avec la notion d'usage. Cordialement. tout petitd'autant que dans certains cas (hum) on ne s'en sort que difficilement... j'en suis à 91 messages rien que pour une micro place exemplaire paumée/tout petit Le 4 octobre 2013 21:58, Christian Quest cqu...@openstreetmap.fr a écrit : A Birmingham, j'ai eu une discussion sur ce sujet avec Andrew (opentripplanner). On est arrivé à imaginer un highway=virtual pour relier tout type de voie. Pas besoin d'info complémentaire, il servent à relier virtuellement leurs deux extrémités. Ce peut servir aussi à relier l'entrée et la sortie d'un parking souterrain. Le 4 octobre 2013 21:44, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : Bonsoir, Vous en connaissez beaucoup, des routeurs qui gèrent correctement les itinéraires sur des surfaces ? Je peux me tromper, mais je viens d'en réessayer une demi-douzaine. Ils viennent en deux variétés : -les agoraphobes, qui transforment les arêtes d'une surface piétonne en éléments du graphe et routent le piéton prudemment tout autour de la surface en rasant les murs -les autruche, qui font comme si la surface piétonne n'existait pas. Il se peut que j'ai râté le routeur qui permet de gérer cette navigation au cap, tout en évitant les kiosques à musique et les bacs-à-fleur-qui-sont-peut-être-des-jardins. S'il existe, je suis preneur. Sincèrement. L'autre solution est peut-être, lors de la production du graphe, de tracer des droites entre tous les noeuds en bord de place (en espérant que la place est raccordée au reste du monde), puis d'éliminer tous les tracés impossibles, surtout si la surface a une forme concave. Et de détourner tous les tracés qui percutent un objet qui aurait bêtement été laissé au milieu de la surface, comme un pilier de la tour Eiffel. Sinon il me semble qu'on continuera à avoir besoin de ways qui sont là principalement pour le bénéfice du routage. Il y a deux solutions : -que les outils de rendu (surtout ceux à vocation esthétisante) éliminent tout ce qui est voies au sein d'un area -que l'on reconnaisse (et que l'on utilise) un tag indiquant que le way est là pour des questions de graphe avant tout. virtual=yes ou render=no ? Si quelqu'un a une meilleure piste, je suis très preneur en tant que gros utilisateur de la nav' piéton. Fionn Le vendredi 4 octobre 2013, Greg a écrit : Salut à tous ! Comme certains veulent recentrer le débat de Saint-Etienne à Paris, j'ai constaté (avec stupeur) que notre tour Eiffel est découpée en pas moins de 9 morceaux (selon les niveaux de zoom). Quand on regarde les détails, ils y a des ways indiquant que : - *highway*: pedestrian - *layer*: 0 - *note*: [lapinos03] tracé voie pédestre facilite le calcul d'itinéraire piéton tout en étant invisible sur le rendu de l'aire piétonne - *surface*: gravel Déjà, le rendu invisible, c'est vite dit. C'est le cas avec le Mapnik par défaut, mais pas vrai sur tile.openstreetmap.fr, ni sur la Transport map, ni Mapquest, ni Humanitarian. Et je me souviens qu'à une époque, les itinéraires sur les surfaces, c'est au logiciel de routage de gérer ça. On a perdu cette philosophie ? Greg ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Les dérives de rue : Dans la rue je dors http://drivrsdu.fr/dans-la-rue-je-dors/ http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list
Re: [OSM-talk-fr] Tagguer pour le rendu
2013/10/4 Ista Pouss ista...@gmail.com: c'est un gros boulot de modélisation. Indiquons les donc, ces obstacles. Avant de parler des obstacles, il faudrait qu'une surface simple soit correctement traitée. Les solutions logicielles existent. Une de ces solutions peut être de créer des chemins virtuels localement, en prétraitement des données. Pas besoin d'en mettre dans OSM. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagguer pour le rendu
Le 04/10/2013 22:20, Fionn Halleman a écrit : D'après taginfo il y a pour l'heure 11 tags highway=virtual dans le monde. Si j'exclus les 3 récemment apparus dans ma ville (dans un parking souterrain, tiens, tiens...), ça ne fait pas encore bien lourd, mais il faut bien commencer le mouvement. ...ou pas. Le vendredi 4 octobre 2013, Christian Quest a écrit : A Birmingham, j'ai eu une discussion sur ce sujet avec Andrew (opentripplanner). On est arrivé à imaginer un highway=virtual pour relier tout type de voie. Pas besoin d'info complémentaire, il servent à relier virtuellement leurs deux extrémités. Ce peut servir aussi à relier l'entrée et la sortie d'un parking souterrain. Les problématiques du parking, pour moi, sont tout autres : c'est le casse-tête du mapping indoor, des niveaux superposés (parking à étages), et de la difficulté de représenter le réseau interne du parking, induite par l'absence de recours au GPS ou aux photos. Le 4 octobre 2013 21:44, Fionn Halleman Vous en connaissez beaucoup, des routeurs qui gèrent correctement les itinéraires sur des surfaces ? Je peux me tromper, mais je viens d'en réessayer une demi-douzaine. Ils viennent en deux variétés : -les agoraphobes, qui transforment les arêtes d'une surface piétonne en éléments du graphe et routent le piéton prudemment tout autour de la surface en rasant les murs -les autruche, qui font comme si la surface piétonne n'existait pas. Il se peut que j'ai râté le routeur qui permet de gérer cette navigation au cap, tout en évitant les kiosques à musique et les bacs-à-fleur-qui-sont-peut-être-des-jardins. S'il existe, je suis preneur. Sincèrement. L'autre solution est peut-être, lors de la production du graphe, de tracer des droites entre tous les noeuds en bord de place (en espérant que la place est raccordée au reste du monde), puis d'éliminer tous les tracés impossibles, surtout si la surface a une forme concave. Et de détourner tous les tracés qui percutent un objet qui aurait bêtement été laissé au milieu de la surface, comme un pilier de la tour Eiffel. J'ai un peu de mal avec l'idée de polluer la base avec des tracés virtuels. Dans la liste des pistes que tu donnes, celle ci-dessus est de loin ma favorite : que ce soit la préparation du graphe de calcul qui assume la création de voies +/- fantômes pour son seul besoin, en partant du postulat que dans une place, toute la surface est accessible tant qu'on ne rencontre pas d'obstacle (bâtiment, plan d'eau, banc...). Dans la version la plus simple, un graphe qui connecte tous les points de sortie de la place 2 à 2 permettrait déjà de calculer un parcours sans rupture. Dans l'expression du guidage, ça deviendrait par exemple : traversez la place xxx sans plus de précision. On pourrait bien sûr affiner en donnant un cap, et/ou le nom de la rue à rejoindre. Pour calculer la distance parcourue dans la place, et/ou représenter une suggestion de trajet, alors oui il faudrait gérer les obstacles et la concavité, mais on atteint là déjà un premier niveau de raffinement. Sinon il me semble qu'on continuera à avoir besoin de ways qui sont là principalement pour le bénéfice du routage. Il y a deux solutions : -que les outils de rendu (surtout ceux à vocation esthétisante) éliminent tout ce qui est voies au sein d'un area -que l'on reconnaisse (et que l'on utilise) un tag indiquant que le way est là pour des questions de graphe avant tout. virtual=yes ou render=no ? Sur le principe, les voies virtuelles sont une béquille pour les logiciels de routage. Pas ça qui va les faire évoluer... donc je vote contre :-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagguer pour le rendu
Le 04/10/2013 21:44, Fionn Halleman a écrit : Sinon il me semble qu'on continuera à avoir besoin de ways qui sont là principalement pour le bénéfice du routage. j'aurai plutot dit au benefice de la description filaire du terrain il me semble qu'OSM n'oppose pas description filaire ou description surfacique mais fait les deux, sinon pourquoi on continue a mettre un way avec waterway=river au milieu d'un lac ? je suis pour avoir dans le cas des places comme dans le cas des cours d'eau, la description filaire ET la description surfacique presents en meme temps dans la base ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr