Je situe mal l'enjeu, pardon. La séparation du highway (à n ways) en plusieurs tracés distincts devrait être au début du trait continu blanc, voire à hauteur du panneau qui indique. A partir de là, un nav' devrait pouvoir faire son travail.
Pour moi, les deux premiers croquis de la page seraient à taguer différemment. Dans le cas de gauche, un node pour la sortie suffit et la 2 voies continue, là ou dans le croquis de droite, la 3-voies s'est rétrécie en une 2-voies (probablement déjà bien à gauche, en dehors du dessin), et qu'au même node (de rétrécissement) commence une nouvelle voie, d'abord parallèle, qui ensuite prend une autre direction. Qu'on mette dans la bdd les choses qui sont, physiquement, ok. Mais des infos de choix d'itinéraires dans la bdd, je vois mal. Si avec une carte correcte, et la vitesse que calcule le gps, un nav' serait dans l'impossibilité topologique (math) d'avertir à temps, et par une combinaison appropriée, il faudrait revoir la (science de la) topologie de fond en comble. C'est au nav', de calculer. Si le conducteur prend la voie de gauche tout de suite, ou s'il traverse le trait blanc continu, il s'est gouré, tant pis pour lui, ne lui reste qu'à poser son téléphone et de jeter un coup d'oeil sur son gps nav' qui visuellement indique la piste à suivre. Vocal et visuel font un ensemble. Du guidage purement vocal sans visuel ne marche pas. Déjà aux rond-points, quand ça dit "prenez la deuxième sortie à droite" : S'ils ont intercalé une residential pour un lotissement qui n'est pas encore sur la carte, ou s'il y a des amorces prévisionnelles qui partent dans des champs, on est mal partis, là où sur le visuel on voit, qu'en réalité ça simplement continue tout droit, et "ferme-la", la vocale. -- Qu'éventuellement, pour aider aux nav's, on mette des longueurs de "tronçons de transition entre voies" (tag à créer), ça irait encore, et quand plusieurs tronçons de transition partagent un même node, que le nav' commence à causer autrement, en phrases concatenées. -- Mais il me semble qu'un nav, en fonction de la vitesse et des distances devrait être capable de discriminer des situations de bifurcations rapprochées, sans qu'on mette des artifices dans la bdd. Ce n'est pas aux cartographes, de prévenir une éventuelle étourderie de l'utilisateur, soit-ce un humain, ou un logiciel nav'. Séparer. -- La question est là, il faudra y répondre, oui, mais je crains que l'approche par relations dans la bdd ne soit pas adéquate. On n'y est pour rien, nous, si parfois ils mettent les bifurcations tellement proches, qu'à 130 ça se chevauche. Pardon, si je n'aurais pas compris la question. Amicalement Gerhard --- Il me semble, que si on menait cette relation proposée de façon conséquente, à la fin on aurait dans la bdd une relation pour chaque itinéraire possible entre tous lieux, de Péta-aux-Chnoks à T'as-Mal-où-les Bains, et une autre pour le chemin inverse :-( Une méta-carte en sus. Comment entretenir et mettre à jour ça, de façon cohérente, si quelque chose change ? Nous ne sommes que quelques milliers de bénévoles :-( --- Le 4 févr. 09 à 13:15, Yann Coupin a écrit : > > > Le 4 févr. 09 à 13:08, sly (sylvain letuffe) a écrit : > >> >>> http://www.coupin.net/vrac/sorties.png >> >> Un petit dessin vaut mieux qu'un long discours ;-) j'y cogite >> >> Mais je me suis basé sur ton lien ici : >> http://slyserv.dyndns.org/osm/aerienne.jpg >> >> et c'est ce que j'ai tracé, mais bon, ok supposons ce nouveau cas. > > Sacré google, toujours prêt à faire une blague ! Ma carte était > centrée ici au départ : http://maps.google.fr/maps? > f=q&source=s_q&hl=fr&geocode=&q=&ie=UTF8&t=k&ll=48.940698,2.292205&spn > =0.00334,0.010171&z=17 > > Si en plus j'envoie pas les bonnes infos, on va pas y arriver... > > Yann > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
