[OSM-talk-fr] Tagguer pour le rendu

[Vincent de Château-Thierry]

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