Bonsoir, Vincent Pottier a écrit : > Le 25/04/2010 19:24, Marc Sibert a écrit : > >> Pieren a écrit : >> >> >>> (....) >>> Pour les itinéraires, je l'ai déjà mentionné par le passé, il y aurait >>> beaucoup plus simple à faire : la relation devrait collecter la liste >>> des nodes du point de départ, d'arrivée et ceux des intersection où il >>> y a changement de direction. Il n'y besoin de rien d'autre pour >>> définir un itinéraire. Bien sûr, cela devient un peu plus compliqué >>> pour les logiciels utilisateurs mais rien d'insurmontable. Et c'est >>> plus facile à éditer puisqu'on ne coupe plus les rues/routes. >>> >>> Pieren >>> >>> >> Bonjour, >> >> J'aime bien cette solution et comme je viens de découvrir que les >> membres de relations sont ordonnés[1], c'est techniquement réalisable. >> J'ai cependant deux réserves : >> >> > J'ajouterai qu'il ne suffit pas toujours de mentionner les intersections > A et B pour déterminer la route. SI deux arcs passent par A et B, un > point C intermédiaire est nécessaire pour la levée de doute. > +1 On arrive doucement à l'OpenLR de Tomtom (http://www.tomtom.com/page/openLR) : somme de + courts chemins avec passage par des points intermédiaires bien choisis pour éviter les ambiguïtés aux intersections. >> 1. Comment ça se saisit dans nos outils : en Potlatch, je ne sais pas >> contrôler l'ordre d'une relation autrement que par l'ordre de la >> saisie : ça veut dire qu'en cas d'oubli d'un nœud, je dois tout >> casser pour recommencer. Qu'en est-il de JOSM ? >> >> > Il fait ça très bien. > >> 2. La reconstitution de la route n'est pas triviale car il va falloir >> trouver tous les ways qui constituent le parcours entre deux >> points de référence et ordonner les ways trouvés. (Note à ce >> sujet, c'est un peu HS, mais je recherche une requête SQL pour >> ordonner une liste de ways sans retour arrière, sur le schéma OSM >> évidemment). >> >> > Le 25/04/2010 20:10, Pierre-Alain Dorange a écrit : > >> C'est pourquoi je proposais de mettre (optionnellement) le way. Ce way >> ne serait pas gérer directement par le moteur logiciel mais comme >> "aide" pour se débrouiller avec les nœuds...- >> > Dans JOSM, si je demande à charger la relation N, il chargera la > relation simple, c'est à dire la référence des points composant la > relation. > Dans JOSM, si tu passes par ce raccourci : Ctrl+Maj+O ou Fichier > Télécharger un objet, la requête faite est bien de type full. Pour ton exemple, en prenant soin de cocher "Télecharger les référants", j'ai 2 requêtes successives : GET http://api.openstreetmap.org/api/0.6/relation/101593/full GET http://api.openstreetmap.org/api/0.6/relation/101593/relations et au final tout ta ligne 1, une fois dans chaque sens, + la relation "network Ginko" incomplète. > http://api.openstreetmap.org/api/0.6/relation/N > Je charge alors ces points (n points). > http://api.openstreetmap.org/api/0.6/node/X (n fois) > Mais je n'ai pas encore chargé les ways passant par eux. Il faut alors > une troisième requête pour charger les ways. 3 passes. > http://api.openstreetmap.org/api/0.6/node/X/full (n fois) > Certes, tous les ways utilisant le node X seront chargés, pas seulement > ceux empruntés par la route : d'où une surcharge d'information. > Pour un calcul de la relation, ce n'est pas gênant d'avoir du matériel > en plus. Pour un travail sur JOSM, c'est chi...(censuré) > > Avec le schéma actuel, une requête suffit pour avoir tout et seulement > le matériel. > http://api.openstreetmap.org/api/0.6/relation/101593/full > > Bon l'api ne s'en sort pas encore très bien avec les relations de relation. > http://api.openstreetmap.org/api/0.6/relation/154039/full ne fournit pas > tout le matériel du réseau Ginko (bus des Besançon) > alors que > http://xapi.openstreetmap.org/api/0.6/relation[network=Ginko][bbox=5.8935,47.1981,6.1307,47.3125] > le fait. > -- > FrViPofm > > > vincent
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr