Il faut surtout filtrer et garder les arrêts et non pas faire le traitement sur l'intégralité du linéaire
Voici la requête sans Nominatim: [out:json]; area[type=boundary][admin_level=4][name="Île-de-France"]-> .s; /* Relation pour le RER C remplacer la lettre du ref par celle de la ligne */ rel["network"="RER"]["ref"="C"](area.s); /* Récupération des arrêts */ node(r:"stop") -> .r; /* Récupération des piscines à 800m des gares */ (node(around.r:800)[sport=swimming]; way(around.r:800)[sport=swimming];); out center qt; Pour filter sur le type d'accès, il faut soit le faire après [sport= swimming] ["network"="RER"]["ref"="C"] ça marche pour le RER A à D mais pour le transilien c'est différent Bon courage Le 18 juillet 2015 15:19, Christian Quest <[email protected]> a écrit : > overpass doit faire un choix entre une recherche géographique et une > recherche par tags. > > Si on a des tags qui permettent de filtrer suffisamment il est préférable > dans bien des cas de ne pas ajouter de bbox ou area. > > line:SNCF étant suffisamment "filtrant", on peut à mon avis éviter bbox et > area. > > > On touche quand même aux limites de l'utilisation de l'overpass pour un > usage "live", overpass n'étant pas vraiment prévu pour ce genre d'usages. > > Solutions: > - monter une instance overpass locale, avec uniquement les données d'ile > de France... qui sera bien plus rapide qu'une instance monde > - mettre en place un cache ou regénérer à intervalle régulier un fichier > geojson à partir de l'overpass publique... > > > > > Le 17/07/2015 10:43, Vincent Génin a écrit : > > Merci beaucoup à tous pour vos réponses. > Je pensais vraiment qu'une area bien definie faciliterait la tâche à > Overpass et je n'ai même pas testé sans... > Je vais tenter avec un BBox grossière et sans et voir ce que ça donne. > > Pour le tilde, je ne vais pas pouvoir m'en passer si je veux faire un truc > propre, puisque qu'une gare peut desservir plusieurs lignes. > > Je vais ajouter et nettoyer un peu les appels pour les services et > équipements (supprimer les acces=private/no ou voir comment avoir qq chose > de plus propre pour les terrains de tennis par exemple). > > Merci en tout cas pour vos retours, et je vous tiens au courant de > l'avancée du projet. > Le 17 juil. 2015 02:25, "Thierry Bézecourt" <[email protected]> a écrit : > >> Oui, et on pourrait même supprimer carrément la bounding box car la >> condition sur la relation limite les résultats de manière équivalente >> (d'ailleurs la ligne C est, sauf erreur, entièrement en Île-de-France). >> >> De plus, il me semble que le tilde (présente dans le lien sur Overpass) >> ralentit la requête. >> >> La requête suivante (http://overpass-turbo.eu/s/atj) dure moins de 10 >> secondes et devrait être facile à adapter pour d'autres lignes de RER. >> Evidemment, il faut faire attention à ne pas mettre une condition trop >> large sur la relation... >> >> [out:json]; >> >> rel["line:SNCF"="C"]; >> node(around:800)[sport=swimming]; >> out body qt; >> >> rel["line:SNCF"="C"]; >> way(around:800)[sport=swimming]; >> out body center qt; >> >> >> Thierry >> >> Le 17/07/2015 08:19, Philippe Verdy a écrit : >> >>> La délimitation a l'Île-de-France au sens strict construit un polygone >>> très complexe. Ce serait peut-être plus rapide avec juste une bounding >>> box. Quitte a chercher des picines "autour" des gares et qu'il n'y a pas >>> tant que ca de gares, il suffit juste d'avoir une bounding bix englobant >>> les gares. Et après on n'est guère mieux qu'a 1 km près pour trouver les >>> piscines mais on n'a pas besoin de la précision fine des frontieres de >>> l'Île-de-France... Est-genant si tu as des résultats en Normandie ou >>> Picardie ? >>> >>> Le 16 juil. 2015 16:11, "Pierre-Yves Berrard" >>> <[email protected] <mailto:[email protected]>> a >>> écrit : >>> >>> Le 16 juillet 2015 15:09, Vincent Génin < <[email protected]> >>> [email protected] >>> >>> <mailto:[email protected]>> a écrit : >>> >>> Bonjour à tous, >>> >>> Désolé si la question est un peu spécifique, mais je n'ai pas >>> trouvé de liste pour Overpass. >>> >>> Pour une utilisation personnelle, je recherchais des piscines >>> autour des gares de la ligne C du RER. >>> J'ai fait quelques tests et utilise cette requête : >>> http://overpass-turbo.eu/s/asI >>> >>> {{geocodeArea:Île-de-France}}->.searchArea; >>> >>> rel["line:SNCF"="C"](area.searchArea); >>> node(around:800)[sport=swimming](area.searchArea); >>> out body qt; >>> >>> rel["line:SNCF"="C"](area.searchArea); >>> way(around:800)[sport=swimming](area.searchArea); >>> out center qt; >>> >>> >>> Cependant, elle prend pas mal de temps à s'exécuter (~60s). >>> >>> >>> Bonjour, >>> >>> Il y aurait peut-être à creuser sur la première ligne, en lui >>> passant directement le numéro de la relation Ile-de-France. >>> Je n'ai plus en tête la syntaxe exacte : quelque chose du style >>> 36000000 + le numéro de la relation. >>> Ça éviterait de passer par nominatim (?), mais je ne sais pas si ça >>> gagne beaucoup de temps. >>> >>> PY >>> >>> _______________________________________________ >>> Talk-fr mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >>> >>> >>> _______________________________________________ >>> Talk-fr mailing list >>> [email protected] >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >>> >> >> _______________________________________________ >> Talk-fr mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > _______________________________________________ > Talk-fr mailing > [email protected]https://lists.openstreetmap.org/listinfo/talk-fr > > > -- > Christian Quest - OpenStreetMap France > > > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
