Salut Philippe, Merci pour ta réponse !
En l'occurence ma requête Overpass ici http://overpass-turbo.eu/s/97q recherche les relations taguées avec operator=SOTRACO et doit retourner ses membres (la ligne ">>;" permet justement une requête récursive sur les membres. On voit d'ailleurs sur la carte que toutes les lignes sont bien retournées sauf la ligne 10 alors que le modèle de données est exactement le même : *chaque arrêt est mappé avec : a) le lieu d'attente des voyageurs • placer un nœud hors de la voie, du bon côté de la route • attributs ◦ highway=bus_stop ◦ public_transport=platform ◦ operator=SOTRACO ◦ network=SOTRACO ◦ name = * ◦ shelter = yes si il y a un abris-bus ◦ bench = yes si il y a un banc ◦ source = survey;bing b) l'arrêt du bus • • placer un nœud à la même hauteur mais appartenant à la voie attributs ◦ public_transport = stop_position ◦ bus=yes ◦ operator=SOTRACO ◦ network=SOTRACO ◦ name = * ◦ source = survey;bing Le 04/05/2015, Philippe Verdy<verd...@wanadoo.fr> a écrit : > Ta requête Overpass ne descend pas les sous-relations pour en extraire les > chemins et noeuds, elle ne descend qu'un seul niveau de la ligne 10 et ne > trouve que des relations membres n'ayant elles-mêmes aucune géométrie, donc > rien n'est visible sur la carte. > > Il faudrait donc distinguer deux requêtes et les fusionner: > - une prenant les relations "route_master" des lignes SOTRACO pour en > extraire les relations "route" > - une autre pour les relations "route" des lignes SOTRACO non modélisées en > route_master (avec routes séparées selon les sens ou les différents > services) > > Et ensuite avec le résultat de la fusion, descendre les membres de type way > et noeud pour obtenir leur géométrie affichable. > > Overpass ne descend pas arbitrairement tous les niveaux de relations, il > fait ses requêtes une par une avec des préselections dans un resultset en > amont (ou bien un pseudo-resultset par défaut correspon dant à la totalité > de la base de données), des filtres de sous-sélection, et produit un > result-set qu'il peut fusionner avec un autre. > > Le 4 mai 2015 13:47, Augustin Doury <augustindo...@gmail.com> a écrit : > >> Et je précise que la L10 est bien visible sur le rendu Transport : >> http://osm.org/go/a6nowwCL?layers=T >> >> Le 4 mai 2015 11:35, Augustin Doury <augustindo...@gmail.com> a écrit : >> >>> Salut à tous, >>> >>> Sur un projet de mapping dans OSM des lignes de bus de la compagnie >>> SOTRACO à Ouaga au Burkina (projet OKFN BF/OSM BF). >>> >>> Nous nous coordonnons avec cette uMap : http://u.osmfr.org/m/37032/ >>> La dernière couche (invisible au chargement) pointe dynamiquement vers >>> la >>> base OSM via une requête Overpass générée avec http://overpass-turbo.eu/ >>> >>> L'incompréhension concerne la ligne 10, modélisées avec ces relations : >>> Aller : https://www.openstreetmap.org/relation/4850754 >>> Retour : https://www.openstreetmap.org/relation/4850740 >>> Master (Aller+Retour) : http://www.openstreetmap.org/relation/4850778 >>> Elles ne sont pas retournées par cette requête (relation et membres >>> vérifiant operator=SOTRACO) : http://overpass-turbo.eu/s/97q >>> Bien que les arrêts membres de la relation soient retournés par cette >>> requête (points vérifiant operator=SOTRACO) : >>> http://overpass-turbo.eu/s/97r >>> >>> Merci d'avance, >>> >>> Augustin >>> >> >> >> _______________________________________________ >> 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
